On Nov 7, 2011, at 6:38 PM, Stephen Kent wrote: > Eric, > > I didn't miss your point; I just do not agree with it. I was noting that > Terry suggested that a milestone doc ought to reflect input from the CAs and > RPs, and that the NRO and IANA are reasonable candidates for such input > coordination. > > You have said, repeatedly, that you feel that a global schedule for alg > transition is a terrible idea. You have explained why you believe so. I have > grave doubts about the high level scenario that you have described. Your > comments seem to ignore the fact that the transition plan incorporates phases > precisely to enable CAs and RPs to verify that they have working code to deal > with the new alg suite before the old one is turned off. You postulate a > major problem that precludes a transition to a new alg Suite (presumably for > Phase 4), but that phase occurs only after CAs have been generating products > and RPs have been consuming them for some time. > > This is not a productive discussion.
Howdy Steve, Thanks for your response. Upon re-reading the exchange, I can see how my statements might have come across as categorically against this approach. This was not my intention, so I'm sorry if that was the impression I gave you. If the list (and you) would indulge me, I'd like to try a (hopefully) more constructive tack: I outlined a few questions that arose in my reading of the draft, and then made a handful of suggestions. Just to be sure my thinking was clear (well, everything is relative: as clear as I ever get), I re-read the draft. In doing so, I tried to refactor my concerns in some more clarifying questions that jumped out at me: 1 - In the draft, there is discussion of the global agreement to move to algorithm B. Who ensures the global agreement of B, and who chooses and ensures agreement of the various dates? 2 - (Double checking that I have read this right), if the motivation for an algorithm roll is discovery of a weakness in the current algo, no CA can roll until this top-down process reaches them, right (months or years)? I see this is broached in Section 11, but it doesn't seem to be answered there? It sounds like the authors don't intend to address this any further than acknowledging the suboptimality of this approach? 3 - Section 11 also prompted another question I had throughout: what happens if a CA doesn't meet these deadlines? It seems like that CA is simply orphaned and cannot participate in routing anymore (until they catch back up)? >From these three questions, I came to the following clarification suggestions: 1 - I see the phases in this draft as defining a formal process. However, I don't see any error-legs (i.e. what happens if there needs to be an abort, rollback, whatever you want to call it). I think it is important to outline how this process can react if there are any unforeseen failures at each phase. I'm not sure that we need to be terribly specific, but perhaps we can agree that _something_ could go wrong and cause the need for an abort? I think this is quite common in process-specifications, unless we think nothing will ever go wrong in this process? :) 2 - Related to the above, I would imagine (but maybe this is just me?) that in the event of a failure at one phase or another, there may need to be a rollback procedure specified. 3 - I think a lot of complexity in the overall draft (and my above comments) could be addressed by allowing CAs to choose their own algorithms and their own schedules. Could this be considered? I recall we discussed how this might negatively affect the performance of the current design's complexity. It's possible that we will just simply come to loggerheads here, but (design issues aside) do people think CA operators should have the ability to protect themselves as soon as they can move to a new algo? 4 - Finally, there is a note that all algorithms must be specified in I-D.ietf-sidr-rpki-algs. While I am not challenging that, I would like to point out that having an analogous requirement in DNSSEC made life a little challenging to add new algos (specifically GOST) without a lot of people trying to assess the algo's worthiness w/i the IETF. I thought, though I could be mistaken, that several people lamented having that requirement. So, perhaps it would make sense to soften it here? Thanks, Eric _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
