Certifying of PI End User Address Space
Dear colleagues, On 11 February, the RIPE NCC asked the RIPE NCC membership and the RIPE community for feedback on how to make Provider Independent (PI) End User address space eligible for resource certification (RPKI). Although we’ve received valuable input at several operator meetings and through various other communication channels, we want to emphasise the importance of your participation on this mailing list. We strongly encourage further feedback on this important issue, before the consultation period comes to a close. To summarise, the discussion so far involves three possible implementation options: 1) A PI End User becomes a RIPE NCC member 2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the ROA management system themselves, or delegates management to the sponsoring LIR 3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system The feedback provided so far clearly differentiates between two groups of PI End Users: those who use the sponsoring LIR solely to request the PI resources but manage everything else themselves, and those who rely on the sponsoring LIR for everything, ranging from BGP routing to RIPE Database updates. In order to cater to both groups, the feedback so far suggests we facilitate both options 2 and 3, while option 1 will continue to remain available at all times. These options have different expected impacts on the RIPE NCC’s operations. The RIPE NCC does not expect option 1 or 2 to have a major impact, as they align with our current business practices. Option 3 would require PI End Users to have a direct contact with the RIPE NCC. As this would be a new venture for the RIPE NCC, we expect it would be the most labour intensive of the three options and would have the greatest impact in terms of resources. Some feedback has pointed out the lack of RIPE Policy on this issue. At this time, the RIPE NCC is requesting feedback on whether or not resource certification should expand beyond a RIPE NCC member service. Discussions about potential RIPE Policy, should this happen, can take place via the appropriate channels. Again, we strongly encourage your feedback before the consultation period ends on 30 March 2013, after which time the RIPE NCC Executive Board will recommend which option(s) to implement. We look forward to hearing from you. Kind regards, Andrew de la Haye Chief Operations Officer RIPE NCC
Hi, On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote:
2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the ROA management system themselves, or delegates management to the sponsoring LIR
3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system
Supporting both 2) and 3) seem to make sense to me. To avoid creating a high workload, 3) would need to be done in a mostly automated fashion - similar to what is happening today: if the sponsoring LIR sets up a mntner object that permits the end user to create their own route:/route6: objects, the end user can create "old-style" route authorization without involving the NCC. Something like this, sort of "between 2) and 3)" - the sponsoring LIR creating an access code of some sorts, and the end user using that to talk to the NCC systems. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 14 Mar 2013, at 12:20, Gert Doering <gert@space.net> wrote:
On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote:
2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the ROA management system themselves, or delegates management to the sponsoring LIR
3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system
Supporting both 2) and 3) seem to make sense to me.
To avoid creating a high workload, 3) would need to be done in a mostly automated fashion - similar to what is happening today: if the sponsoring LIR sets up a mntner object that permits the end user to create their own route:/route6: objects, the end user can create "old-style" route authorization without involving the NCC. Something like this, sort of "between 2) and 3)" - the sponsoring LIR creating an access code of some sorts, and the end user using that to talk to the NCC systems.
Could it actually be that straightforward? It seems unlikely, though I hope otherwise. An obvious rat-hole in this scenario is figuring out what to do for PI End Users who can't/won't go through a sponsoring LIR. Presumably this amended option 3) would still mean the PI End User entering some sort of contractual relationship with the NCC => introducing extra procedures and infrastructure around billing, paperwork and so forth. A PI End User would or should pay something to get resource certificates, right? Perhaps we'll get a re-run of the debate over legacy resource holders becoming LIRs or going through a sponsoring LIR. My preference would be to avoid option 3) -- or variations of 3) -- for the reasons Andrew outlined. That said, it would be helpful to get more data on the extent of the issue and a rough idea of likely costs. How many PI End Users are there and what are the best case and worst case scenarios for the amount of work that would be involved in issuing them with resource certificates? If the costs to the NCC for option 3) will always be insignificant, then there's nothing to see here, move along. Just do it. OTOH if option 3) has the potential to grow into a monster that needs a small army to administer it, we should not go down that path.
On 14 Mar 2013, at 15:44, Jim Reid <jim@rfc1035.com> wrote:
On 14 Mar 2013, at 12:20, Gert Doering <gert@space.net> wrote:
On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote:
2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the ROA management system themselves, or delegates management to the sponsoring LIR
3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system
Supporting both 2) and 3) seem to make sense to me.
To avoid creating a high workload, 3) would need to be done in a mostly automated fashion - similar to what is happening today: if the sponsoring LIR sets up a mntner object that permits the end user to create their own route:/route6: objects, the end user can create "old-style" route authorization without involving the NCC. Something like this, sort of "between 2) and 3)" - the sponsoring LIR creating an access code of some sorts, and the end user using that to talk to the NCC systems.
Could it actually be that straightforward? It seems unlikely, though I hope otherwise.
Just to clarify option 3: a Resource Certificate is not for identification purposes, nor does it contain identity information; this is what the Registry is for. All that the RIPE NCC needs to ensure is that we issue a certificate to the party who has authoritative control over the address space. Establishing this could be done using the maintainer of the relevant INETNUM object, for example, which means it could be implemented in an automated fashion, as Gert suggests. It all depends if that is "good enough". Every additional check that is required, such as submitting paperwork, will add to the complexity, cost and labour involved, but could very well be worth the effort. All of this will be evaluated and taken into account when taking the decision on the actual implementation. Cheers, Alex
Andrew,
impact, as they align with our current business practices. Option 3 would require PI End Users to have a direct contact with the RIPE NCC. As this would be a new venture for the RIPE NCC, we expect it would be the most labour intensive of the three options and would have the greatest impact in terms of resources.
could you please clarify whether options (1) and (3) would differ in resource consumption and why? Option (3) makes no indication regarding cost recovery. Setting the legacy resource holder debate aside, is the expectation that option (3) would provide the service free of charge, billed on hours incurred or by a fixed fee? Given that the current charging model is flat, but does not have to remain flat in the future, is a subscription model feasible? (a subscriber is basically a paying customer receiving the same services as a member, whithout having the rights and duties of a member)). -Peter, as an individual
Hi, On Sat, Mar 16, 2013 at 05:03:24PM +0100, Peter Koch wrote:
Option (3) makes no indication regarding cost recovery. Setting the legacy resource holder debate aside, is the expectation that option (3) would provide the service free of charge, billed on hours incurred or by a fixed fee? Given that the current charging model is flat, but does not have to remain flat in the future, is a subscription model feasible? (a subscriber is basically a paying customer receiving the same services as a member, whithout having the rights and duties of a member)).
My gut feeling suggests that the "50 EUR per year and network" fee we currently have should cover the certification costs nicely, if we find a way to make it automated for "almost all" cases... Gert Doering -- PI holder, member, ... -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
Dear Peter, To answer your first question, option 3 would require more resources than option 1 because it would require the RIPE NCC to create new processes for handling non-members. In addition to setting up these new processes, the RPKI system and its surrounding applications will need to be extended and maintained to facilitate this new process and allow non-members access. In response to your second question, I’d like to thank you for raising this issue. We cannot say at this moment what cost model option 3 would be subject to because it will be up to the membership to decide this. If option 3 is selected, we will ask for feedback on whether or not the membership expects some sort of cost recovery model, and this issue will need to be reviewed in the next round of charging scheme discussions. Based on that feedback, the Executive Board will provide several different cost models, and the membership will have the opportunity to decide what they feel is best for them. Kind regards, Andrew de la Haye Chief Operations Officer On Mar 16, 2013, at 5:03 PM, Peter Koch <pk@DENIC.DE> wrote:
Andrew,
impact, as they align with our current business practices. Option 3 would require PI End Users to have a direct contact with the RIPE NCC. As this would be a new venture for the RIPE NCC, we expect it would be the most labour intensive of the three options and would have the greatest impact in terms of resources.
could you please clarify whether options (1) and (3) would differ in resource consumption and why? Option (3) makes no indication regarding cost recovery. Setting the legacy resource holder debate aside, is the expectation that option (3) would provide the service free of charge, billed on hours incurred or by a fixed fee? Given that the current charging model is flat, but does not have to remain flat in the future, is a subscription model feasible? (a subscriber is basically a paying customer receiving the same services as a member, whithout having the rights and duties of a member)).
-Peter, as an individual
Andrew On 18 Mar 2013, at 14:44, Andrew de la Haye <ripencc-management@ripe.net> wrote:
To answer your first question, option 3 would require more resources than option 1 because it would require the RIPE NCC to create new processes for handling non-members.
The NCC already sure has a large number of people in the dB who are non-members ? Some of whom will hold resources as well as being contacts ? Is the use case so drastically different ? Regards Fearghas
On 18 Mar 2013, at 14:50, Fearghas McKay <fearghas@gmail.com> wrote:
The NCC already sure has a large number of people in the dB who are non-members ?
Some of whom will hold resources as well as being contacts ?
Is the use case so drastically different ?
Yes. Maybe. Depends. The costs of maintaining existing DB entries for these non-members are probably negligible. I think. Money may well change hands whenever these non-members get additional services from the NCC such as resource certification. Unless of course the membership decides to absorb the costs of doing that "for free". Even if no charges are levied, NCC staff may need to spend a lot of time verifying who those PI holders are before issuing certification tokens for their resources. Although I have no idea about the extent of those incremental costs, they must surely be more than holding some tuples in the database. It would be helpful to get some upper and lower bounds on what the likely costs would be. I doubt they will be negligible or bankrupt the NCC. The question is where they might sit between these two extremes. We just don't know. I'd like to get this info as input to the discussions so we can hopefully arrive at a consensus on something that won't spring last-minute surprises.
On 14/03/2013 11:41, Andrew de la Haye wrote:
Some feedback has pointed out the lack of RIPE Policy on this issue. At this time, the RIPE NCC is requesting feedback on whether or not resource certification should expand beyond a RIPE NCC member service. Discussions about potential RIPE Policy, should this happen, can take place via the appropriate channels.
I've been trying to figure out a diplomatic way of re-approaching this issue, but inspiration has not happened, so the direct way will have to do. RIPE Chair and RIPE NCC Board: there is a problem which you are not dealing with: RIPE community policy and RIPE NCC policy have diverged on an issue which the RIPE Community and a majority of the current RIPE NCC board felt was important enough to require formal policy proposals with community support to back them up. When policy consensus was not achieved in the RIPE Community in the first of what was intended as an entire series of proposals, the RIPE NCC board chose to ignore the lack of consensus and put forward proposals to implement resource certification as an NCC service. I'm not judging the content of the 2008-08 proposal here; nor am I disputing the right of the RIPE NCC membership to vote on issues at general meetings and expect the NCC to implement those decisions; nor is this a criticism of the excellent work of the RIPE NCC staff whose resource certification implementation has been exemplary. My concern is solely that the bottom-up process which validates the RIPE NCC's legitimacy has been ignored in an area of policy where bottom-up process actually matters and where a majority of current RIPE NCC board members have explicitly acknowledged this by their presence on the original RIPE (not RIPE NCC) certification task force and their authorship of policy 2008-08. This is important because the RIPE NCC publicly champions the principle of bottom-up stakeholder support, and it does so in a very prominent way. If it happens that this principle is sidelined - as it has been in this situation - then the RIPE NCC opens itself up to criticism that the bottom-up approach is meaningless and can be circumvented when expedient to do so. Rather than attempting to resolve this situation, the RIPE NCC is pushing forward with plans which will ultimately compound the problem and make it more difficult to resolve in the long term. Again, I don't dispute the legal right of the RIPE NCC to do this if their membership votes for it, but I have serious concerns about the wisdom of doing it because it de-legitimises the RIPE NCC's claims of bottom-up policy support. I'd like to ask for feedback from the RIPE Chair about whether he feels that bottom-up policy is achieved when it is appropriate for the RIPE NCC to create its own policies in situations where the RIPE Community feels that the topic is sufficiently divisive that they cannot form consensus. And if it is appropriate for the RIPE NCC to do this, whether there is any point in continuing to have a RIPE Community and a policy development process. Nick
On 18/03/2013 23:31, Nick Hilliard wrote:
[...] whether he feels that bottom-up policy is achieved when it is appropriate for the RIPE NCC to create its own policies
ofc, this should have read: "whether he feels it is appropriate for the RIPE NCC to create its own policies..."
On 18/03/2013 23:31, Nick Hilliard wrote:
On 14/03/2013 11:41, Andrew de la Haye wrote:
Some feedback has pointed out the lack of RIPE Policy on this issue. At this time, the RIPE NCC is requesting feedback on whether or not resource certification should expand beyond a RIPE NCC member service. Discussions about potential RIPE Policy, should this happen, can take place via the appropriate channels. I've been trying to figure out a diplomatic way of re-approaching this issue, but inspiration has not happened, so the direct way will have to do.
I'd like to ask for feedback from the RIPE Chair about whether he feels that bottom-up policy is achieved when it is appropriate for the RIPE NCC to create its own policies in situations where the RIPE Community feels that the topic is sufficiently divisive that they cannot form consensus. And if it is appropriate for the RIPE NCC to do this, whether there is any point in continuing to have a RIPE Community and a policy development process. This response isn't strictly speaking an official one. However, as one of the authors of the policy proposal in question, and as Chairman of
I think that your email is perfectly diplomatic and I'm going to try to respond to it. the RIPE NCC board feel I have a certain amount of personal responsibility for the whole sorry business around certification. Perhaps I can explain my own reasoning, and perhaps the whole process will prove cathartic and I'll be able to start sleeping at nights again. Way back in 2006ish the RIPE community and RIPE NCC pulled together the Certification Authority Task Force (CATF) which had representation from the NCC and the community and which had the task of looking at Certification, its effects on the community and its effects on the NCC. The NCC did a lot of work, mainly on looking at business processes and the effects that certification would have on this, but also did some development work to see what the software might look like. The CATF reported regularly back to the community at RIPE meetings and via email and the community appeared to be generally in favour of the work (at least no or few objections were raised). Other RIRs, most notably APNIC, concentrated on the software development side and APNIC in particular produced a full blown implementation which they made available to their community. The RIPE NCC was continuing to work on business processes and eventually reached the stage where they felt that they had a sufficiently solid framework to start development of trial software. This was notified to the community at a regular report of the CATF, and certification activity was notified to the RIPE NCC membership through the Activity plan. Again, no objections were raised and informal approval from the community was given to continue with the work. Work started and trial software was developed and reported on to the community. The community (and membership) gave informal approval for operational software to be developed and funds were committed. At the same time, and as its final task the CATF wrote a policy proposal (2008-08) to formalise the support from the community. Up to this point, no objections had been received. 2008-08 started to make its way through the PDP and reactions were initially reasonably in favour. Objections mostly centered around the limited proposed life span of certificates and the fact that LIRs who failed to pay their membership fees might find themselves without valid certificates for their address space. Changes were made to the policy proposal to try and accommodate this but there was general agreement that certificates should be roughly tied to the commercial arrangements between the LIR and the RIPE NCC. Meanwhile work continued on the the development of the certification software as detailed in the activity plan. Eventually a form of the proposal was developed which seemed satisfactory to everyone and the policy moved through to the review phase. At this point, things started to go wrong. A small but vociferous group raised issues about the ability of certification and ROAs in particular to enable the RIPE NCC (and by extension, the Dutch government) to "switch off the internet". These concerns are perfectly valid but do depend on balance of probability arguments. In my opinion the PDP handles this sort of of argument very badly: it assumes that all discussion can be rationally argued and arguments of the form of "if condition A were to pertain then B will happen and B is undesirable, but the probability of A happening is a matter of opinion, and opinion varies wildly" don't enter into it. The fact that the arguments were only raised at the review stage didn't help either. Most of the proponents of the proposal had long lost interest in re-stating arguments that had been fought and won many months or even years previously and the discussion started to spiral into destruction. The CATF had long disbanded and as the only member with my name on the policy proposal I was left holding holding this particularly unpleasant orphaned child. I could see no approach but euthanasia and I reluctantly withdrew the policy. This was *my* decision, not the Board's and not the RIPE NCC's. However, this now left the RIPE NCC in a difficult position. They had spent some hundreds of thousands of euros on work which the community had assured them it wanted and which the community now was refusing to support. The membership were now being faced with the nightmare that worries me continuously: that the community asks the NCC to do something which has serious financial implications for the membership and for which there is no means, under the PDP, of refusal. Under the circumstances, the board took the only course sensibly available to them and asked the membership how they wanted to proceed: did they want to continue with certification work (having already spent a substantial amount of money) or did they want the work to stop? A further option of continuing but without the ability to generate ROAs (which is what gives the ability for the certification authority to affect routing) was also offered. You all know the outcome. The membership voted to continue the work and to continue to offer ROAs. The majorities were much slimmer than I would have liked to see, but they were majorities. And the RIPE NCC continued forward with certification work. This is my memory of the events as they happened. The chronology may be slightly off but the events are roughly in order. What have we learned from this? Well, there are a number of important lessons: 1. Don't accept informal expressions of "yes, let's try doing that" from the community, especially where substantial sums are involved. 2. Make sure that for really substantial changes in policy, community approval is obtained *first* (although there is the caveat that this may add unacceptable delays to the work to be done) 3. Try and make sure that the community is fully aware of the implications of what they are proposing 4. And finally don't equate lack of response with approval We have been bitten by 3) before now. Proposal 2007-01 caused an increase in operating costs of 17% when it was implemented and as a direct result, the NCC and board implemented a policy of delivering an impact analysis on all policy proposals. 1) and 2) haven't really come up since 2008-08 but be assured that the NCC and board have been bitten once and are now twice shy. So, after this long email, what do I say to your original question? Well, I passionately believe (and so does the Board and the NCC) in the bottom up process. I believe that it is vital to the growth and development of the internet and although it has its dark side, I don't think we've come up with anything better, so far. However, we have to be aware that it can sometimes move with glacial slowness and the RIPE NCC is running a commercial operation, with bills and staff to be paid. Sometimes a decision has to be made based on community "feeling". And as any working group chair will tell you, working out what that is is why they are paid the big bucks... In this case, having got a go ahead from the membership, however lukewarm, it didn't seem a large step to add certificates for PI as well as PA. Certification is one where the decision might have been made differently if that measure of feeling had been different, if people had looked up for their laptops in the working group and actually debated the issues *early on*. As it happened, the real debate only started to happen years after the money had been spent, and the membership (whose money it is) deserved a say in how to proceed. That's why I handled it like I did. And in similar circumstances I'd probably do it the same way again. Now, I'm going to have a nice cup of tea and get back to my day job. Nigel
On Tue, Mar 19, 2013 at 10:52:29AM +0000, Nigel Titley wrote:
At this point, things started to go wrong. A small but vociferous group raised issues about the ability of certification and ROAs in particular to enable the RIPE NCC (and by extension, the Dutch government) to "switch off the internet". These concerns are perfectly valid but do depend on balance of probability arguments. In my opinion the PDP handles this sort of of argument very badly: it assumes that all discussion can be rationally argued and arguments of the form of "if condition A were to pertain then B will happen and B is undesirable, but the probability of A happening is a matter of opinion, and opinion varies wildly" don't enter into it.
Yes. I guess that's the same about the safety of atomic energy. There were (and still are) many people claiming that the probability of Chernobyl and Fukushima happening is very low, but the problem is that IF it happens, the results are devastating, at least for those impacted. Looks like we first have to suffer before re-considering in this case as well.
The fact that the arguments were only raised at the review stage didn't help either. Most of the proponents of the proposal had long lost interest in re-stating arguments that had been fought and won many months or even years previously and the discussion started to spiral into destruction.
The arguments got rehashed in the wider "secure routing" context since many many years. The dangers have been discussed at length. People probably got tired of rehashing them again in the RIPE community, given that they are "common wisdom". And/or hoped that this effort will die off due to "no interest" or "no money". Unfortunately it didn't.
However, this now left the RIPE NCC in a difficult position. They had spent some hundreds of thousands of euros on work which the community had assured them it wanted and which the community now was refusing to support.
That's the thing with research and proof-of-concepts. There is no guarrantee that it will move to production phase. What's happening here is what is called "go-minded" in aviation. Just that you are on approach, doesn't mean you're going to actually land. In fact, it's being trained that every approach leads into execution of a missed approach procedure at decision altitude/height UNLESS every parameter really indicates that it's safe to land. Very bad accidents have happend (and still continue to happen) because folks at the yoke/stick are "go-minded" and try to rescue an approach (or in this case, continue a project without broad backing of those affected). IMHO, the pilot monitoring (RIPE community) has called out "go around!" late (at decision altitude), but soon enough. Substantial concerns have not been properly addressed and dangers mitigated. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
That's the thing with research and proof-of-concepts. There is no guarrantee that it will move to production phase. What's happening here is what is called "go-minded" in aviation. Just that you are on approach, doesn't mean you're going to actually land. In fact, it's being trained that every approach leads into execution of a missed approach procedure at decision altitude/height UNLESS every parameter really indicates that it's safe to land. Very bad accidents have happend (and still continue to happen) because folks at the yoke/stick are "go-minded" and try to rescue an approach (or in this case, continue a project without broad backing of those affected). IMHO, the pilot monitoring (RIPE community) has called out "go around!" late (at decision altitude), but soon enough. To continue the analogy though, the aircrew in this case thought that
On 20/03/2013 10:21, Daniel Roesen wrote: the dangers were worth risking but still felt it worth while asking the airplane owners (some of who were on board) whether they wanted to take the risk of landing. The passengers and the folks on the ground were too busy shouting at each other for any sensible decision to be made. Nigel
On Wed, Mar 20, 2013 at 11:09:16AM +0000, Nigel Titley wrote:
On 20/03/2013 10:21, Daniel Roesen wrote:
That's the thing with research and proof-of-concepts. There is no guarrantee that it will move to production phase. What's happening here is what is called "go-minded" in aviation. Just that you are on approach, doesn't mean you're going to actually land. In fact, it's being trained that every approach leads into execution of a missed approach procedure at decision altitude/height UNLESS every parameter really indicates that it's safe to land. Very bad accidents have happend (and still continue to happen) because folks at the yoke/stick are "go-minded" and try to rescue an approach (or in this case, continue a project without broad backing of those affected). IMHO, the pilot monitoring (RIPE community) has called out "go around!" late (at decision altitude), but soon enough.
To continue the analogy though, the aircrew in this case thought that the dangers were worth risking but still felt it worth while asking the airplane owners (some of who were on board) whether they wanted to take the risk of landing. The passengers and the folks on the ground were too busy shouting at each other for any sensible decision to be made.
Not really. The aircrew comprises of the pilot flying (NCC) and pilot monitoring (RIPE community). If either one calls out "go around!", a missed approach is executed. Too bad in this case the veto (no consensus in vafor _is_ a factual veto in PDP) was ignored by the pilot flying. Instead of following good CRM procedures and listening to the pilot monitoring, he called the aircraft owners. What happens in that kind of scenarios then can be read up here: http://avherald.com/h?article=429ec5fa Regarding the RIPE community only as "passengers" would be troublesome to me. The RIPE community is part of the aircrew, in fact the "pilot monitoring". The aircraft owner thought the risk was worth taking, and the pilot flying adopted that opinion being bound by it, while the pilot monitoring vetoed but was ignored. In aviation, that's called a complete breakdown of CRM (crew resource management) and utterly bad airmanship. :) http://en.wikipedia.org/wiki/Crew_resource_management#United_Airlines_Flight... and following sections. I guess we differ in our interpretation of the role of the RIPE community in that analogy. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On 20/03/2013 11:48, Daniel Roesen wrote:
On Wed, Mar 20, 2013 at 11:09:16AM +0000, Nigel Titley wrote: Not really. The aircrew comprises of the pilot flying (NCC) and pilot monitoring (RIPE community). If either one calls out "go around!", a missed approach is executed. Too bad in this case the veto (no consensus in vafor _is_ a factual veto in PDP) was ignored by the pilot flying. Instead of following good CRM procedures and listening to the pilot monitoring, he called the aircraft owners. What happens in that kind of scenarios then can be read up here: http://avherald.com/h?article=429ec5fa
Regarding the RIPE community only as "passengers" would be troublesome to me. The RIPE community is part of the aircrew, in fact the "pilot monitoring". The aircraft owner thought the risk was worth taking, and the pilot flying adopted that opinion being bound by it, while the pilot monitoring vetoed but was ignored. In aviation, that's called a complete breakdown of CRM (crew resource management) and utterly bad airmanship. :)
http://en.wikipedia.org/wiki/Crew_resource_management#United_Airlines_Flight... and following sections.
I guess we differ in our interpretation of the role of the RIPE community in that analogy.
I suspect you may be right. And I also suspect that this analogy has been stretched a little too far. Your point is taken though. All the best Nigel
Nigel, Thanks for replying. I had hoped - and still hope - for a reply from the RIPE chair (not the RIPE NCC chair) because I believe this to be a matter of some importance to the RIPE Community. I don't want to get into an analysis of why and how 2008-08 failed, but I do think it's worth noting that the razor-thin majority vote in the Sep 2011 RIPE NCC General Meeting suggests that there was and is substantially more community dissent about this than you admit in your reply. This was clear prior to the GM vote, given the scale of the fire storm which erupted over 2008-08, mid 2011.
continuously: that the community asks the NCC to do something which has serious financial implications for the membership and for which there is no means, under the PDP, of refusal.
Research into resource certification was requested by the community via the task force, not via the PDP. The PDP later returned a result: that the issue was highly divisive. It wasn't a helpful result from the point of view of moving resource certification forward, and the NCC board chose to ignore it.
Under the circumstances, the board took the only course sensibly available to them and asked the membership how they wanted to proceed:
This wasn't the only course of action sensibly available, imo - but it was a course of action that had a significant risk of policy divergence which has now occurred.
So, after this long email, what do I say to your original question? Well, I passionately believe (and so does the Board and the NCC) in the bottom up process [...] In this case, having got a go ahead from the membership, however lukewarm, it didn't seem a large step to add certificates for PI as well as PA.
At least there was an attempt to engage with the community regarding PA blocks, even if it produced a frustrating result. For PI blocks, there has been no attempt to engage with the community. I don't understand how a complete lack of engagement with the RIPE Community on this issue is compatible with the bottom up process. By pressing ahead with these plans, the RIPE NCC board is sending a clear signal that it is prepared to ignore the bottom-up process when expedient to do so. I believe that this is deeply harmful to the RIPE community and ultimately to the RIPE NCC. Nick
Nigel,
Thanks for replying. I had hoped - and still hope - for a reply from the RIPE chair (not the RIPE NCC chair) because I believe this to be a matter of some importance to the RIPE Community. I am sure that Rob will be replying in due course. I have urged him to do so.
I don't want to get into an analysis of why and how 2008-08 failed, but I do think it's worth noting that the razor-thin majority vote in the Sep 2011 RIPE NCC General Meeting suggests that there was and is substantially more community dissent about this than you admit in your reply. This was clear prior to the GM vote, given the scale of the fire storm which erupted over 2008-08, mid 2011. I did actually point out that the majority vote was far less than I would have hoped.
Research into resource certification was requested by the community via the task force, not via the PDP. The PDP later returned a result: that the issue was highly divisive. It wasn't a helpful result from the point of view of moving resource certification forward, and the NCC board chose to ignore it. No real opposition to to resource certification appeared until the end of the review stage of the PDP, in fact the PDP was nearly complete. At
Nick, On 20/03/2013 17:10, Nick Hilliard wrote: this point I had discussions with one of the opponents of the proposal, who admitted that he hadn't been following the PDP and didn't know how it worked anyway, but that he was opposed to certification. I pointed out to him that it was possible to raise objections, as late in the process as it was. I did this because I believe in the open process. The result was a firestorm indeed... many people suddenly woke up and started reiterating arguments that had been settled months or years earlier. I watched the process with horror, not because I had a particularly vested interest in the issue of certification (to be frank by this stage I would have liked to see it buried in a deep hole in the ground) but because I saw the community tearing itself apart.
This wasn't the only course of action sensibly available, imo - but it was a course of action that had a significant risk of policy divergence which has now occurred.
That is where we have to agree to differ. The board has a primary responsibility to the NCC membership, to ensure that the NCC continues as a financially viable organisation. As I pointed out in my previous email the decision to withdraw the proposal was mine and not the RIPE NCCs or the Board's.
At least there was an attempt to engage with the community regarding PA blocks, even if it produced a frustrating result.
For PI blocks, there has been no attempt to engage with the community. I don't understand how a complete lack of engagement with the RIPE Community on this issue is compatible with the bottom up process.
Subsequent discussion on the list (some as recently as last week) indicated that now we had certification, extending it to PI seemed a minor step.
By pressing ahead with these plans, the RIPE NCC board is sending a clear signal that it is prepared to ignore the bottom-up process when expedient to do so. I believe that this is deeply harmful to the RIPE community and ultimately to the RIPE NCC.
Just as a matter of interest, could I refer you to the proposal text that Axel sent out? "Following approximately six weeks of discussion (ending on 30 March 2013), the Executive Board will consider feedback from the list and propose options on moving forward on this matter which will be properly communicated." And looking through the email thread I've spotted one objection (yours), several expressions of approval and one who said that RPKI was outside policy. Just to reiterate. The NCC and Board *does* listen to the Members (and also the community). I think we've demonstrated that time and time again. I've tried to show how this one particular case was a very difficult one and how I tried to cut the Gordian knot with which we (the community, the members and the RIPE NCC) had tied ourselves up and I'm sorry you disagree with the way that was done. I can't really say much more and I look forward to discussing this with you in Dublin over a Guinness. Nigel
Hi Nigel, On Wed, Mar 20, 2013 at 05:56:57PM +0000, Nigel Titley wrote:
And looking through the email thread I've spotted one objection (yours), several expressions of approval and one who said that RPKI was outside policy.
That was me, IIRC. I've changed my mind, though, and would like to withdraw that assertion, see also below...
Just to reiterate. The NCC and Board *does* listen to the Members (and also the community). I think we've demonstrated that time and
I think the debate has now become more fundamental, viz whether the NCC should be constrained/supported by policy in all it does. I tend to agree that it should... cheers, Sascha Luck
On 20/03/2013 17:56, Nigel Titley wrote:
Just as a matter of interest, could I refer you to the proposal text that Axel sent out?
"Following approximately six weeks of discussion (ending on 30 March 2013), the Executive Board will consider feedback from the list and propose options on moving forward on this matter which will be properly communicated."
I read Axel's email carefully before sending my reply of February 11. He presented a proposal to choose between three different options for implementing RPKI for PI blocks. This is not bottom-up community stuff. It is presenting a foregone policy decision to the community and soliciting input on its implementation. My reply was firmly outside the context of the input that the RIPE NCC was soliciting. The RIPE community and the RIPE PDP were sidelined 18 months ago by the NCC because it seemed like the least inconvenient option. If the NCC proceeds with plans to roll out RPKI/PI in the absence of RIPE community policy, we will then have a firmly established precedent for the RIPE NCC to ignore the RIPE community on issues which should rightly be handled as RIPE policy. I believe this to be extremely harmful and that it sets a terrible example. We have a mechanism for dealing with RIPE policy. It may not be perfect, but it has full community support and we accept that it is generally a good basis for handling policy issues. If the process has problems such that difficult issues like resource certification lead to stalemate, then either the PDP needs to be re-examined or else the issues are truly too contentious to be implemented. Sidelining the PDP because it might produce the wrong result is not the way to deal with this situation. If the PDP needs to be fixed, then let us fix it. Nick
Hi, [Internet Citizen hat on] On Thu, 2013-03-21 at 00:42 +0000, Nick Hilliard wrote:
We have a mechanism for dealing with RIPE policy. It may not be perfect, but it has full community support and we accept that it is generally a good basis for handling policy issues. If the process has problems such that difficult issues like resource certification lead to stalemate, then either the PDP needs to be re-examined or else the issues are truly too contentious to be implemented.
Sidelining the PDP because it might produce the wrong result is not the way to deal with this situation. If the PDP needs to be fixed, then let us fix it.
(~Specific to RPKI) I agree with nick and can openly admit to being part of the small(*) but vocal opposition to 2008-08. I apologize for learning about the topic late, but as soon as I did (2010) and grasped the gravity of the implications it *will* bring (to me, it's a fact), I did my internet citizenry duty ~best I could. [ *A major problem is the topic is extremely complex and multi-dimensional, and most people who you talk to about it, and even make them understand, don't know where to turn to discuss it. RIPE Policy seems a difficult, perhaps bureaucratic beast at first, to most. A friend on IRC asked: "where do we discuss open internet questions?" Is RIPE this forum? RIPE certainly goes around in ~IGF conferences claiming to be representing us somehow, today...] This brings us to the general problem here: In which way is the RIPE NCC (Inc.) basing its monopoly integer registration operation on the internet at large, rather than its paying members? There's some argument that a service may or may not be subject for policy, such as measurement services, atlas, etc. Or that the RIPE DB is not. To me it's absolutely obvious and clear that matters with implications for not just internet addressing and resource registration & coordination, which RIPE NCC has been given a monopoly from the community to operate (because it's an easy way to do it), but also routing, are a matter of community sourced policy. This absolutely and definitely includes the RIPE DB, in the sense of it being where the distribution of addresses is documented. If there's no documentation, distribution may or may not work, but coordination absolutely does not. This task, not just from paying members, but from everybody, is not a one-way relationship. If it ever becomes a one-way relationship, the RIPE NCC will lose the legitimacy of its operation (business) and I don't think there's anyone here who want that pandoras box to open? And thus this is a discussion of principle. The go-around was ignored. Damage to the relationship has occurred. How does the RIPE NCC and RIPE Community which to resolve this? Do we want to resolve it, and how? Or is it time to part ways (and thereby by extension openly inviting competition to registry operations...) I have some ideas for the specific "single registry point of failure" issue which was overarching the debates surrounding 2008-08. This is perhaps a bit "meta", but it is extremely fundamental to what we are doing, higher-order politics aside. Best regards, Martin
Hi,
[Internet Citizen hat on]
(~Specific to RPKI) I agree with nick and can openly admit to being part of the small(*) but vocal opposition to 2008-08. I apologize for learning about the topic late, but as soon as I did (2010) and grasped the gravity of the implications it *will* bring (to me, it's a fact), I did my internet citizenry duty ~best I could. But I'm sure you can understand the frustration and despair of those who *had* been arguing the topic for 2 years prior to this, had come to a reasonable policy agreement, and then suddenly found all of the old arguments suddenly resurrected again. It would have been really useful if you (and others) had made your arguments two years previously. (Those who were at the Rome meeting will remember me losing my temper (a very rare occurrence) on the platform over this). This brings us to the general problem here: In which way is the RIPE NCC (Inc.) basing its monopoly integer registration operation on the internet at large, rather than its paying members? Now this is a question that deserves further debate, and it strikes at
On 21/03/2013 11:15, Martin Millnert wrote: the heart of the PDP. The authors of the PDP made it as far as possible completely standalone from the RIPE NCC (compare to the process in other regions). Now this has it's advantages (it answers your question above, in that it is entirely disjoint from the members and so can claim to represent the internet at large rather than the members). However (and at this point I put my NCC Board hat on) it has serious commercial implications in that the community has power without responsibility. As Jim Reid so cogently remarked a couple of weeks ago, the community could propose a policy that instructed Axel to hand out €100 notes on the Dam square until the NCC went bust and if we followed the PDP to the letter there is nothing the Board could do about it despite the fact that this would personally bankrupt them too. All other regions have some sort of veto, or endorsement by the board, for all policies. The ARIN region even allows the board to make policy, without reference to either the community or the Advisory board. And they have exercised this right. So I would argue that in general, the RIPE NCC has a better right than any other RIR to claim to represent the Internet at large. And in general the PDP works well (but see below).
If it ever becomes a one-way relationship, the RIPE NCC will lose the legitimacy of its operation (business) and I don't think there's anyone here who want that pandoras box to open?
Agreed
And thus this is a discussion of principle. The go-around was ignored. Damage to the relationship has occurred. How does the RIPE NCC and RIPE Community which to resolve this? Do we want to resolve it, and how? Or is it time to part ways (and thereby by extension openly inviting competition to registry operations...) I have some ideas for the specific "single registry point of failure" issue which was overarching the debates surrounding 2008-08.
It would be very useful for you to communicate those ideas with the NCC team currently working on the problem.
This is perhaps a bit "meta", but it is extremely fundamental to what we are doing, higher-order politics aside.
It is absolutely fundamental and I think we need to get the answers to a number of questions: 1. To what extent can policy be allowed to dictate the day to day running of the NCC 2. Does the membership (the owners) of the RIPE NCC have a right (under very specific circumstances) to dictate which policy they implement, and if the answer is yes, then how is this communicated and how are the circumstances decided. 3. Does the PDP, with its "authority but no responsibility" built-ins pose a threat to the NCC and hence the internet in the region. If so then how can we fix it. 4. Is our process of deciding policy by consensus still appropriate to the PDP? (Note that this is a different question to the issue of bottom up governance, to which we are all committed) 5. And what *exactly* do we mean by consensus? By the way, I'm writing this as a concerned citizen of the internet, to which I've given more than twenty years of my life. I genuinely want to sort this out (if it needs sorting out). Nothing I say above has anything to do with the NCC or the Board and any remarks I make are my responsibility alone. I welcome genuine debate All the best Nigel
5. And what *exactly* do we mean by consensus?
the ietf is making an effort in this space, see http://tools.ietf.org/html/draft-resnick-on-consensus-02 randy
On 21/03/2013 12:13, Randy Bush wrote:
5. And what *exactly* do we mean by consensus? the ietf is making an effort in this space, see
Nice and useful document. Should be required reading for all WG-chairs. Nigel
http://tools.ietf.org/html/draft-resnick-on-consensus-02 Nice and useful document. Should be required reading for all WG-chairs.
and participants randy
On 21 Mar 2013, at 12:28, Randy Bush <randy@psg.com> wrote:
http://tools.ietf.org/html/draft-resnick-on-consensus-02 Nice and useful document. Should be required reading for all WG-chairs.
and participants
+1 Pete's document is excellent. FWIW other organisations use a much more succinct definition of consensus: lack of sustained reasonable objection.
On Mar 21, 2013, at 1:13 PM, Randy Bush <randy@psg.com> wrote:
5. And what *exactly* do we mean by consensus?
the ietf is making an effort in this space, see
Yes! I like that document, but my personal observation is that rough consensus works best if there is a clear technical goal and a shared set of values. i.e. it is easier for topics for which there is agreement from the people in the room that that technical goal needs a solution against a specific set of requirements. In the IETF they/we try to manage that with having good charters and requirements documents and even there it is sometimes very difficult. The more you move to layer 9 the more difficult it gets to work towards consensus, mostly because the values start diverging. If one is at a point that the core values are diverged the consensus seeking turns into negotiation, and that is a whole different beast altogether (Dubai Dec 2013 comes to mind) I think that the RIPE community is still enough of a community to have shared core values to enable consensus seeking. That circles back to Nigel's questions, specifically his 'authority but no responsibility' remark. If it is the case that our policy development does not take into account responsibility towards the institutions that we need to maintain, then I think some of us don't share the same values.
I welcome genuine debate
This thread will hit some fundamentals. To keep the entropy under control I promise myself to follow the 'not more than one mail per day rule' ;-) --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands
participants (13)
-
Alex Band -
Andrew de la Haye -
Daniel Roesen -
Fearghas McKay -
Gert Doering -
Jim Reid -
Martin Millnert -
Nick Hilliard -
Nigel Titley -
Olaf Kolkman -
Peter Koch -
Randy Bush -
Sascha Luck