For your information, we are producing a SLURM file as part of our implementation. This is noted in the slides. Purely as an informational and with no intent to otherwise engage in your policy proposal process, It has been my intention to bring our implementation report to the RIPE meeting in Berlin and present it in the routing WG. Please let me know if this would be useful or interesting, or is not helpful. -George On Fri, Feb 21, 2020 at 2:54 PM Job Snijders <job@ntt.net> wrote:

Dear working group,

On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:

...

The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.

The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion.

You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis

I oppose the policy proposal. I think this is a Bad Idea [tm].

The cost/benefit analysis seems to show that substantial cost is involved to achieve what appears to be a very minor benefit at best, and a great potential for issues down the road. Our community could use that money for far more rewarding work.

It should also be noted that anyone wishing to reject unallocated and unassigned address space can easily do so by converting the data available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP prefix-filters. There are many ways to suppress the propagation of routing information related to not-yet-assigned space, using the RPKI seems far too big of a hammer.

The moment address space is assigned by the RIPE NCC to an end user or LIR, that entity will be able to create RPKI ROAs (if they wish to do so) to glean the very same benefits that AS 0 ROAs for unassigned space would provide up front. But that that point in time it'll be the end users choice to do so. Shifting that moment forward in time doesn't seem to have tangible benefits to me.

Nobody has been able to show me that what operational issues arise from the presence of a handful of unassigned prefixes in the BGP Default-Free Zone. The numer is so low, the prefixes involved don't really seem to pop up on threat radars. I asked the same question in APNIC's policy development community and no answer was provided.

Perhaps a different direction can be taken? One of the authors of 2019-08 experimented with generating a SLURM file based on the list of unassigned / unallocated address space, which can easily be incorporated into Origin Validation pipelines. I'm in support of modifying the proposal to not instantiate a new TAL, but rather have the RIPE NCC publish a SLURM [RFC 8416] file. This approach would yield the exact same results at a much lower cost.

Kind regards,

Job

Hi Job, Petrit, All, (please see inline) On Fri, 21 Feb 2020, Job Snijders wrote:

Dear working group,

On Thu, Feb 20, 2020 at 04:39:26PM +0200, Petrit Hasani wrote:

...

The goal of the proposal is to ask the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control.

The proposal has been updated following the last round of discussion. Version 2 of the proposal includes a specification for the RIPE NCC to create all AS0 ROAs under a specific Trust Anchor.

The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community?s discussion.

You can find the proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-08 https://www.ripe.net/participate/policies/proposals/2019-08#impact-analysis

I oppose the policy proposal. I think this is a Bad Idea [tm].

The cost/benefit analysis seems to show that substantial cost is involved to achieve what appears to be a very minor benefit at best, and a great potential for issues down the road.

Which issues exactly do you have in mind?

Our community could use that money for far more rewarding work.

Such as...?

It should also be noted that anyone wishing to reject unallocated and unassigned address space can easily do so by converting the data available at https://ftp.ripe.net/pub/stats/ripencc/ into BGP prefix-filters.

Yes, it's possible, but not as practical as having it embedded in RPKI -- some may think.

There are many ways to suppress the propagation of routing information related to not-yet-assigned space, using the RPKI seems far too big of a hammer.

It improves RPKI usage, imho, though.

The moment address space is assigned by the RIPE NCC to an end user or LIR, that entity will be able to create RPKI ROAs (if they wish to do so) to glean the very same benefits that AS 0 ROAs for unassigned space would provide up front. But that that point in time it'll be the end users choice to do so. Shifting that moment forward in time doesn't seem to have tangible benefits to me.

I do see a significant benefit in marking invalids as "INVALID" instead of "UNKNOWN".

Nobody has been able to show me that what operational issues arise from the presence of a handful of unassigned prefixes in the BGP Default-Free Zone.

...and over peerings/IXs.

The numer is so low, the prefixes involved don't really seem to pop up on threat radars.

Prefixes (especially those which were not legitimately allocated) can come and go, once they have served their purpose........

I asked the same question in APNIC's policy development community and no answer was provided.

Maybe not the best audience to ask about what's on threat radars?

Perhaps a different direction can be taken? One of the authors of 2019-08 experimented with generating a SLURM file based on the list of unassigned / unallocated address space, which can easily be incorporated into Origin Validation pipelines. I'm in support of modifying the proposal to not instantiate a new TAL, but rather have the RIPE NCC publish a SLURM [RFC 8416] file. This approach would yield the exact same results at a much lower cost.

That would mitigate the "will have to duplicate the entire current RPKI infrastructure..." phrase on the impact analysis, right? :-) I do support 2019-08 as it is, but i can easily support a version 3 with the above suggestion. Cheers, Carlos

Kind regards,

Job

JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:

I don't think is objective to say that the proposal as asking the NCC to "inject" invalids.

The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI.

Jordi, You're splitting hairs here. The end result is the same. Nick

On Feb 23, 2020, at 8:45 AM, Nick Hilliard <nick@foobar.org> wrote:

JORDI PALET MARTINEZ via routing-wg wrote on 23/02/2020 13:06:

...

I don't think is objective to say that the proposal as asking the NCC to "inject" invalids. The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI.

Jordi,

You're splitting hairs here. The end result is the same.

I’m cornered about something like this as we’ve been down this road before with bogon lists, etc and even though it’s well intentioned by smart people(tm), the distributed legacy and cleanup has often taken years to recover. - Jared

I don't think is objective to say that the proposal as asking the NCC to "inject" invalids.

The proposal is providing the information of the invalids (in this case unallocated/unassigned) by means of RPKI.

ok. i was kind of on the fence. but american press has made me oversensitive to fake language such as this; so it threw me over the edge. i do not support the proposal. randy

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@ripe.net en nombre de max@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.

In my email the other day, I provided the links to the recent presentation, here is it again: Video: https://www.youtube.com/watch?v=yACx-wJV6FA#t=25m Slides (prop-132 Implementation plan): https://2020.apricot.net/assets/files/APAE432/prop-132-implementation-plan.p... I recall George mention about low cost, but is only from top of my head. I suggest to look at the video and slides, and probably George can tell something else :-) if they already have more data. I'm guessing that the same infrastructure can handle it and if you increase the infrastructure it can be done in such way that has the advantage to make more resilient the existing one, so it is about the existing RPKI service also. Of course, some development, but I don't think it is that much. Regards, Jordi @jordipalet El 26/2/20 9:18, "routing-wg en nombre de Carlos Friaças via routing-wg" <routing-wg-bounces@ripe.net en nombre de routing-wg@ripe.net> escribió: 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@ripe.net en nombre de max@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. > > > > > ********************************************** 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.

Anton pointed out I may have both misunderstood and not answered your question. The testbed is a soft TA. In deployment, people will have to move to a new (as yet not created) TAL for AS0, as long as it runs independently of the mainline TAL. We intend running a distinct TA for AS0 until we get a clear signal our community wants it integrated. We have stated concerns about the automatic adoption of ASO products worldwide without visible agreement of this activity, a separate TAL turns the activity from opt-out to opt-in. We are duplicating the software signing infrastructure, but with lower costs overall given commonalities. We are still discussing if we can run the offline-TA HSM and the online production key HSM for both activities, or if we need a distinct infrastructure for AS0 and mainline. Duplication overall is not in APNIC's model, we rely on spares and alternate use of the HSM, but production signing systems are single instances. I believe they are capable of some virtualisation or segmentation but that skirts the underlying physical risk/dependency. Sorry for not being clearer before -George On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg <routing-wg@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@ripe.net en nombre de max@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.

Thanks for this very valuable feedback Thiago! Much appreciated! Cheers, Melchior On Mon, Mar 2, 2020 at 11:11 AM Thiago da Cruz <tdacruz@ripe.net> wrote:

Hi all,

Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI.

I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach.

First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra)

Something like the diagram below.

For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs.

About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments.

But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc…

I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it.

Let me know you need more info about this subject.

Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC

+---------------------+ | | +-------+ | TA (offline) +------------+ HSM | | | +-------+ +---------------------+

+------------------------+

| |

+-----------> | RRDP publication |

| | |

| | (cloud) |

| | | +-------------------+ +-------------------+ | +------------------------+ | | | | Publication | | RPKI-Core 1 | (...) | RPKI-Core n | ----------------------> * +> | | | | | +--+-----+----+-----+ +--+------+-------+-+ | +----------------------------+ | | | | | | | | | | | +---------------+ | | | | | Rsync publication | | | | | | +----+ +-----------> | | +-----+ +-----------+ +---------+ | | | (internal infra - x nodes) | | | | | | | | | | | | +-------------------+ | | | | +-----------------------------------------+ | | +----------------------------+ | | | | | | +-+----+--+ + + +-+------++ | HSM 1 | (......................) | HSM m | +---------+ +---------+

On 27 Feb 2020, at 23:51, George Michaelson <ggm@algebras.org> wrote:

Anton pointed out I may have both misunderstood and not answered your question.

The testbed is a soft TA. In deployment, people will have to move to a new (as yet not created) TAL for AS0, as long as it runs independently of the mainline TAL.

We intend running a distinct TA for AS0 until we get a clear signal our community wants it integrated. We have stated concerns about the automatic adoption of ASO products worldwide without visible agreement of this activity, a separate TAL turns the activity from opt-out to opt-in.

We are duplicating the software signing infrastructure, but with lower costs overall given commonalities.

We are still discussing if we can run the offline-TA HSM and the online production key HSM for both activities, or if we need a distinct infrastructure for AS0 and mainline. Duplication overall is not in APNIC's model, we rely on spares and alternate use of the HSM, but production signing systems are single instances. I believe they are capable of some virtualisation or segmentation but that skirts the underlying physical risk/dependency.

Sorry for not being clearer before

-George

On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg <routing-wg@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@ripe.net en nombre de max@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.

Hi Thiago, The question here, I think, is to understand how much in euros is “a lot”? Regards, Jordi @jordipalet El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces@ripe.net en nombre de tdacruz@ripe.net> escribió: Hi all, Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach. First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra) Something like the diagram below. For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs. About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it. Let me know you need more info about this subject. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC +---------------------+ | | +-------+ | TA (offline) +------------+ HSM | | | +-------+ +---------------------+ +------------------------+ | | +-----------> | RRDP publication | | | | | | (cloud) | | | | +-------------------+ +-------------------+ | +------------------------+ | | | | Publication | | RPKI-Core 1 | (...) | RPKI-Core n | ----------------------> * +> | | | | | +--+-----+----+-----+ +--+------+-------+-+ | +----------------------------+ | | | | | | | | | | | +---------------+ | | | | | Rsync publication | | | | | | +----+ +-----------> | | +-----+ +-----------+ +---------+ | | | (internal infra - x nodes) | | | | | | | | | | | | +-------------------+ | | | | +-----------------------------------------+ | | +----------------------------+ | | | | | | +-+----+--+ + + +-+------++ | HSM 1 | (......................) | HSM m | +---------+ +---------+ On 27 Feb 2020, at 23:51, George Michaelson <ggm@algebras.org> wrote: Anton pointed out I may have both misunderstood and not answered your question. The testbed is a soft TA. In deployment, people will have to move to a new (as yet not created) TAL for AS0, as long as it runs independently of the mainline TAL. We intend running a distinct TA for AS0 until we get a clear signal our community wants it integrated. We have stated concerns about the automatic adoption of ASO products worldwide without visible agreement of this activity, a separate TAL turns the activity from opt-out to opt-in. We are duplicating the software signing infrastructure, but with lower costs overall given commonalities. We are still discussing if we can run the offline-TA HSM and the online production key HSM for both activities, or if we need a distinct infrastructure for AS0 and mainline. Duplication overall is not in APNIC's model, we rely on spares and alternate use of the HSM, but production signing systems are single instances. I believe they are capable of some virtualisation or segmentation but that skirts the underlying physical risk/dependency. Sorry for not being clearer before -George On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg <routing-wg@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@ripe.net en nombre de max@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. ********************************************** 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.

Hi Thiago, Yeah, I understand that … So, my question is re-directed to the policy officer for providing an approximation of what is the cost. Regards, Jordi @jordipalet El 2/3/20 20:07, "Thiago da Cruz" <tdacruz@ripe.net> escribió: Hi Jordi, I’m not the budget guy, so I’m going to distance myself from the euros. When I say “it would cost us a lot to implement it” I mean in effort when compared with other options. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg <routing-wg@ripe.net> wrote: Hi Thiago, The question here, I think, is to understand how much in euros is “a lot”? Regards, Jordi @jordipalet El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces@ripe.net en nombre de tdacruz@ripe.net> escribió: Hi all, Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. So I think it’s important for us to tell a few things about our approach. First what we have today in production: - TA software (offline box) - HSM for the TA (plus backups and spare parts) - A few application servers running our RPKI software - I’ll call it RPKI-Core - Redundant HSMs used by RPKI-Core - RRDP publication service (cloud) - Some rsync nodes (internal infra) Something like the diagram below. For testing environment we have practically the same infra. And for public test (localcert) we use ‘soft' keys and no HSMs. About the new AS0 TA, yes, we could simplify our infra. One option would be to use ‘soft’ keys all around or use a HSM for TA only. We could also use third-party software for TA, Core and publication service. It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. But I don’t think we should treat it as a "second class citizen". If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… I’m not here to advocate against nor in favour of AS0 TA. But when discussing our implementation, this was our rationale to duplicate the infrastructure. And that’s why it would cost us a lot to implement it. Let me know you need more info about this subject. Kind regards, Thiago da Cruz Sr. software engineer - RPKI Team RIPE NCC +---------------------+ | | +-------+ | TA (offline) +------------+ HSM | | | +-------+ +---------------------+ +------------------------+ | | +-----------> | RRDP publication | | | | | | (cloud) | | | | +-------------------+ +-------------------+ | +------------------------+ | | | | Publication | | RPKI-Core 1 | (...) | RPKI-Core n | ----------------------> * +> | | | | | +--+-----+----+-----+ +--+------+-------+-+ | +----------------------------+ | | | | | | | | | | | +---------------+ | | | | | Rsync publication | | | | | | +----+ +-----------> | | +-----+ +-----------+ +---------+ | | | (internal infra - x nodes) | | | | | | | | | | | | +-------------------+ | | | | +-----------------------------------------+ | | +----------------------------+ | | | | | | +-+----+--+ + + +-+------++ | HSM 1 | (......................) | HSM m | +---------+ +---------+ On 27 Feb 2020, at 23:51, George Michaelson <ggm@algebras.org> wrote: Anton pointed out I may have both misunderstood and not answered your question. The testbed is a soft TA. In deployment, people will have to move to a new (as yet not created) TAL for AS0, as long as it runs independently of the mainline TAL. We intend running a distinct TA for AS0 until we get a clear signal our community wants it integrated. We have stated concerns about the automatic adoption of ASO products worldwide without visible agreement of this activity, a separate TAL turns the activity from opt-out to opt-in. We are duplicating the software signing infrastructure, but with lower costs overall given commonalities. We are still discussing if we can run the offline-TA HSM and the online production key HSM for both activities, or if we need a distinct infrastructure for AS0 and mainline. Duplication overall is not in APNIC's model, we rely on spares and alternate use of the HSM, but production signing systems are single instances. I believe they are capable of some virtualisation or segmentation but that skirts the underlying physical risk/dependency. Sorry for not being clearer before -George On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg <routing-wg@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@ripe.net en nombre de max@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. ********************************************** 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. ********************************************** 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.

Hi Petrit, I understand that, but I think it may be easy to get an idea, not exact cost. The reason why this is needed is because one of the arguments against this proposal is about the cost. This can't be judged as a valid objection for reaching consensus if we don't have that cost (approximate). Regards, Jordi @jordipalet El 3/3/20 13:16, "routing-wg en nombre de Petrit Hasani" <routing-wg-bounces@ripe.net en nombre de phasani@ripe.net> escribió: Dear Jordi, I would like to clarify that the financial cost approximation of a proposal is not part of the Impact Analysis and the Policy Development Process, so we have not made a calculation. As too many factors have to be taken into account that we can't estimate realistically at this stage of the PDP. Our software department provided an estimation of the worked involved for the implementation of the proposal which is explained in the impact analysis. Kind regards, — Petrit Hasani Policy Officer RIPE NCC > On 2 Mar 2020, at 20:22, JORDI PALET MARTINEZ via routing-wg <routing-wg@ripe.net> wrote: > > Hi Thiago, > > Yeah, I understand that … So, my question is re-directed to the policy officer for providing an approximation of what is the cost. > > Regards, > Jordi > > @jordipalet > > > > > > El 2/3/20 20:07, "Thiago da Cruz" <tdacruz@ripe.net> escribió: > > Hi Jordi, > > I’m not the budget guy, so I’m going to distance myself from the euros. > When I say “it would cost us a lot to implement it” I mean in effort when compared with other options. > > Kind regards, > Thiago da Cruz > Sr. software engineer - RPKI Team > RIPE NCC > > > >> On 2 Mar 2020, at 18:25, JORDI PALET MARTINEZ via routing-wg <routing-wg@ripe.net> wrote: >> >> Hi Thiago, >> >> The question here, I think, is to understand how much in euros is “a lot”? >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> >> >> >> El 2/3/20 11:11, "routing-wg en nombre de Thiago da Cruz" <routing-wg-bounces@ripe.net en nombre de tdacruz@ripe.net> escribió: >> >> Hi all, >> >> Many of you might not know me, but I’m part of RIPE’s software engineering team that takes care of RPKI. >> >> I’ve been following this discussion closely and I've noticed some lack of clarity about our decision to duplicate our RPKI infrastructure. >> So I think it’s important for us to tell a few things about our approach. >> >> First what we have today in production: >> - TA software (offline box) >> - HSM for the TA (plus backups and spare parts) >> - A few application servers running our RPKI software - I’ll call it RPKI-Core >> - Redundant HSMs used by RPKI-Core >> - RRDP publication service (cloud) >> - Some rsync nodes (internal infra) >> >> Something like the diagram below. >> >> For testing environment we have practically the same infra. >> And for public test (localcert) we use ‘soft' keys and no HSMs. >> >> >> About the new AS0 TA, yes, we could simplify our infra. >> One option would be to use ‘soft’ keys all around or use a HSM for TA only. >> We could also use third-party software for TA, Core and publication service. >> It crossed my mind, for a fraction of a second, to skip AS0 TA instances for our internal and/or public test environments. >> >> But I don’t think we should treat it as a "second class citizen". >> If we provide another TA, it’s worthy of receiving as much TLC as our production TA; meaning that it would also require the same (or similar) process around it as our production TA does. That includes keeping track of HSM card holders, defining a proper admin and operator quorum, scheduling periodical resigning sessions, etc… >> >> I’m not here to advocate against nor in favour of AS0 TA. >> But when discussing our implementation, this was our rationale to duplicate the infrastructure. >> And that’s why it would cost us a lot to implement it. >> >> Let me know you need more info about this subject. >> >> Kind regards, >> Thiago da Cruz >> Sr. software engineer - RPKI Team >> RIPE NCC >> >> >> +---------------------+ >> | | +-------+ >> | TA (offline) +------------+ HSM | >> | | +-------+ >> +---------------------+ >> >> >> >> >> +------------------------+ >> | | >> +-----------> | RRDP publication | >> | | | >> | | (cloud) | >> | | | >> +-------------------+ +-------------------+ | +------------------------+ >> | | | | Publication | >> | RPKI-Core 1 | (...) | RPKI-Core n | ----------------------> * +> >> | | | | | >> +--+-----+----+-----+ +--+------+-------+-+ | +----------------------------+ >> | | | | | | | | | >> | | +---------------+ | | | | | Rsync publication | >> | | | | | +----+ +-----------> | | >> +-----+ +-----------+ +---------+ | | | (internal infra - x nodes) | >> | | | | | | | | >> | | | +-------------------+ | | | >> | +-----------------------------------------+ | | +----------------------------+ >> | | | | | | >> +-+----+--+ + + +-+------++ >> | HSM 1 | (......................) | HSM m | >> +---------+ +---------+ >> >> >> >> >> >> >> >> >>> On 27 Feb 2020, at 23:51, George Michaelson <ggm@algebras.org> wrote: >>> >>> Anton pointed out I may have both misunderstood and not answered your question. >>> >>> The testbed is a soft TA. In deployment, people will have to move to a >>> new (as yet not created) TAL for AS0, as long as it runs independently >>> of the mainline TAL. >>> >>> We intend running a distinct TA for AS0 until we get a clear signal >>> our community wants it integrated. We have stated concerns about the >>> automatic adoption of ASO products worldwide without visible agreement >>> of this activity, a separate TAL turns the activity from opt-out to >>> opt-in. >>> >>> We are duplicating the software signing infrastructure, but with lower >>> costs overall given commonalities. >>> >>> We are still discussing if we can run the offline-TA HSM and the >>> online production key HSM for both activities, or if we need a >>> distinct infrastructure for AS0 and mainline. Duplication overall is >>> not in APNIC's model, we rely on spares and alternate use of the HSM, >>> but production signing systems are single instances. I believe they >>> are capable of some virtualisation or segmentation but that skirts the >>> underlying physical risk/dependency. >>> >>> Sorry for not being clearer before >>> >>> -George >>> >>> On Wed, Feb 26, 2020 at 6:18 PM Carlos Friaças via routing-wg >>> <routing-wg@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@ripe.net en nombre de max@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. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >> >> >> >> ********************************************** >> 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. > > > ********************************************** > 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. ********************************************** 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.

Hi Gert, Unfortunately, our PDP doesn't have any definition of consensus (I was miss-recalling a reference to the relevant RFC about "rough consensus") and after re-reading again several times our PDP (RIPE-710). However, in the discussion phase, it is explicitly called for "rough consensus", same in the following phases. What it is clear in any case, is that all the objections must be justified. According to that, I still think that having 10 or 100 (just an example) "no", only count if each one clearly justified (and not refuted by authors or the community), and is still consensus even if you have only a couple of "yes". Regards, Jordi @jordipalet El 26/2/20 18:13, "routing-wg en nombre de Gert Doering" <routing-wg-bounces@ripe.net en nombre de gert@space.net> escribió: Hi, On Wed, Feb 26, 2020 at 08:47:31AM +0100, JORDI PALET MARTINEZ via routing-wg wrote: > I can see also people in favor and I understand, as we usually do in any proposal discussion, that non-objection is consent. This assertion is not correct per RIPE PDP rules, except in last call. Gert Doering -- who happens to judge consensus every now and then. -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 ********************************************** 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.