On Nov 15, 2011, at 10:53 AM, Stephen Kent wrote: > Eric, > > i think we are making progress. thanks for the feedback. > >> ... >> >> I really think we should address these issues in a single document. It >> seems like splitting this off into a separate/as yet unwritten document is >> likely to cause some problems. In particular, since that document does not >> yet exist, and it may not be written and adopted for some time, this draft >> will not be complete on its own. I'm worried that it is hard to judge this >> document's readiness w/o these timeline issues worked out or even broached >> (as they may demand changes to this process). Besides, isn't the corpus of >> drafts rather extensive already (w/o adding another)? :) > > My motivation for a separate timetable (vs. timeline) doc is that there seems > to be some agreement that this doc should be a product of the operator > community. The alg transition doc is an IETF architectural statement, the > product of this WG. I can't see combining the two. Did I misunderstand your > concern here?
Yes, there is a misunderstanding. This draft is documenting a formal process. The snipped text included the statement: "It is also RECOMMENDED that the timeline document describe procedures to track the progress of the transition and to amend the timeline, e.g., if problems arise in implementing later phases of the transition." I really think that the procedures associated with this process need to be documented here in the same place (i.e. one draft). > >> ... >> >> OK, I see. But, aren't there second-order effects of this that we have to >> worry about? For example, if I am an ISP whose CA performs the rollover >> properly, but my upstream's CA does not, then their CA's failure to keep up >> will cause my ISP to no longer be able to participate in BGPsec, right >> (because I'm no longer part of a contiguous BGPsec island)? I realize this >> is a bit different than my original example, but upon thinking about the >> motivation for my comment, my point was more general. It was that >> transitioning a CA to this state can have very undesirable effects. > > What you say that you performed the rollover but the CA above you didn't can > you be more specific, re the phase number? After Phase 4, when some CAs may be orphaned. To quote the draft: "a[n] RP that does not follow this process will lose the ability to validate signed products issued under the new algorithm suite." > >> kewl, thnx. One minor nit: can we rephrase one part for clarity. Instead >> of "If a problem arises that makes this infeasible for a substantial number >> of CAs," can we just specify a little bit about how this is determined. >> Maybe something like, "If <whoever the operational governing body we elect >> for timeline statements> deems a problem to have arisen that is significant >> enough to make this infeasible for a significant enough number of CAs..." > > Good suggestion. I had already changed the text to the following form. > > If it is determined that a substantial number of CAs are unable > > Since we don't have a good placeholder for the bracketed entity I think it's > easier to make the statement without say who makes the determination. Kewl, thnx. As a broad question, do we think there will be a point when we can name an operational body who will manage this process, and if so, will we put this in a draft? >> ... >> >> I think this is a very strange comment (and I note that you said it earlier >> in this email too). "Use of the RPKI... is optional." Is the goal of this >> system to protect the global routing infrastructure or not? > > The goal of this work does not imply that we can force all ISPs to adopt it. > We hope that the RPKI will be very widely deployed and used, but we > acknowledge that it may not me universal. So, both initially and perhaps > forever, the world will consist of resources that are protected by certs and > ROAs, and ones that are not. > >> Unless we are talking about making this an experimental expedition, and >> are prepared to create a globally applicable system later? > > that's not a sentence :-). Yeah it is, I can speak to this at the mic... ;) In the meantime: Are we talking about making this an experimental expedition? Follow on question, are we prepared to create a globally applicable system later? >> If the goal is to secure the global routing system (note I am not saying >> universal deployment in the foreseeable future, just global applicability), >> then this is an operational non-starter. > > I'm glad that we agree that universal deployment is not a likely near term > event. We also agree that the RPKI is globally applicable . No, I was questioning the global applicability. I am worried that the way BGPsec and RPKI are currently married is not globally applicable, in the current form. > Neitehr of these observations conflict with the fact that its use by an > network operator is optional. True, but my point is still that there is a rather striking misalignment between the design and operational invariants. I'm trying to see your points and how this might not be true, but claiming that we've agreed when it's plain that we have not is... not as productive as it could be... :) > >> I do not believe it is appropriate for us to try and re-legislate >> operational axioms in these drafts. What we could be doing is grossly >> misaligning this standards work with operational invariants. > > I no longer know what you are referring to. I have said that we cannot > mandate adherence to this process. We can offer it as a preferred approach > and hope that it is followed. We have incorporated a number of phases so that > there is an opportunity to verify the status of the transition, and to allow > the timeline to be pushed back if necessary. if what you are saying is that > we ought not specify any process that calls for CAs and RPs to try to execute > a transition in a coordinated fashion, over a long time interval, then we > have an impasse. The disagreement is based on perceptions, on both of our > parts, not facts. I think the distinct lack of another instance of this kind of operational requirement in modern Internet-scale systems should be cause for pause here. As I said back at the beginning of this thread: "Sorry, but I think freedom from global coordination is more than an inconvenient, or unpalatable, concept. It is something that (afaict) has been an inherent requirement in those Internet-scale systems that have survived to date. I don't think there is any precedent of an operational system of this scale that requires this level of global coordination of its configuration, is there? What Internet-scale system of a scale remotely as large as BGP has this kind of global coordination model? What is the evidence that such an approach will work here?" >> >> >> > To avoid more flame wars, I will duck your question about my views on >> > DNSSEC and accommodation of different algorithm suites :-). >> Shall I take that as a retraction of your comment? ;) > > no. Then I would really like to understand. As DNSSEC (though not perfect, in any way) is a system that has reached deployment trials and has a growing body of operational practices, what were the "less rigorous" criteria that were "not great?" Maybe we'll all agree, or maybe we'll all learn... Eric _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
