This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Previous message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
George Michaelson
ggm at algebras.org
Wed Feb 26 23:33:26 CET 2020
At this time, no. we have not. We have joined RIPE in the exploration of RPKI resiliency but so far it has been a joint legal review of the CPS (still underway) and discussions about the RIPE model. I have been trying to promote resiliency in public visibility of RPKI products, which is long-hand for "deploy RRDP to a CDN" which in fact other RIR do. This cooperation was actively promoted by the RIPE and APNIC EC as I understand it, and so far has been very beneficial if also lightweight. Duplicate HSM is a very high cost burden. I am not saying its wrong or inappropriate, I am only saying that it needs to be understood for its risk/return benefits. It goes almost completely to risk/consequence side, we don't have enough signing events high in the root that the volume needs duplication. We do have backup keystore for the TA, and we do have spare parts policy and alternate HSM we can consider cold-backup. Full duplication hasn't been architected. I agree that for what we are discussing, and what RIPE are exploring, it has a very strong case. As do various M of N procedures, and (with some reluctance because of past statements) TCR type public visibility of some functional acts on the HSM. -G On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg <routing-wg at ripe.net> wrote: > > > Hi, > > Any clue if APNIC has duplicated the infrastructure (and cost) as it is > foreseen in the NCC's impact analysis...? > > Carlos > > > > On Wed, 26 Feb 2020, JORDI PALET MARTINEZ via routing-wg wrote: > > > Hi Max, > > > > I think is too early to take a decision, and in fact I don't think we are yet in case A. > > > > Consensus is about justified objections. I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent. > > > > The only justification that I can see is from Job about possible cost. However, I don't see figures about how much it cost to develop this AS0 + how much it cost the operators to use it (if they want) vs developing the SLURM + making sure it is secure as RPKI + how much ti cost the operators to use it. > > > > And by the way, the AS0 is compatible with the SLURM, so opeartors can choose. > > > > Regards, > > Jordi > > @jordipalet > > > > > > > > El 25/2/20 20:30, "routing-wg en nombre de Massimiliano Stucchi" <routing-wg-bounces at ripe.net en nombre de max at stucchi.ch> escribió: > > > > > > Hi everyone, > > > > On 20/02/2020 15:39, Petrit Hasani wrote: > > > > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. > > > > > > At the end of the Review Phase, the Working Group (WG) Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. > > > > Today, me and the other proposers of this policy change had a meeting to > > discuss the feedback we have been receiving on the list. > > > > We understand that many people find this proposal controversial, and > > many have expressed themselves against it in the past days. > > > > We would like to encourage discussion and provide us with a bit of > > guidance on how the community would like to proceed. At present we have > > identified three ways of progressing: > > > > A) We can try to go ahead with this proposal, although it will be hard > > to get consensus; > > > > B) We can drop the proposal, and leave everything as is; > > > > C) We can change the proposal to a different ask for RIPE NCC. The idea > > could be to ask RIPE NCC to provide a SLURM file (similar to what APNIC > > does), so that single users can decide if they want to feed it to their > > validators. > > > > From what we gathered in the discussions, I think B) could be the most > > sought-after decision, but we would like to propose C) as the way > > forward. It would give the possibility to those who want to implement > > this solution to do it in a lightweight fashion. It would for sure be > > much much cheaper to implement. > > > > In any case, as Job already pointed out, I prepared a simple tool to > > generate a SLURM file using either the Team Cymru bogons list, or > > considering any unassigned space from the NRO delegated stats file. > > RIPE NCC has kindly provided help and patches to improve it. If you > > want to give it a go, you can find it here: > > > > https://github.com/stucchimax/rpki-as0-bogons > > > > Thank you for any suggestion or any discussion around this. > > > > Ciao! > > -- > > Massimiliano Stucchi > > MS16801-RIPE > > Twitter/Telegram: @stucchimax > > > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > > > > > >
- Previous message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
- Next message (by thread): [routing-wg] 2019-08 Review Phase (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]