On 31/10/11 11:59 PM, "Stephen Kent" <[email protected]> wrote:
>> >> I understand why you want to, but don't come to the same conclusion as to >> the mechanism. >> >> Is that really the IETF's job? > > SIDR was tasked by the SEc ADs to develop an alg transition architecture. > The authors believe that uniform milestones are necessary as part of > a credible plan. > Architecture, yes. Structured approach, yes. To both of those I agree. Having the IETF define the dates when algorithms shift. I am not convinced. >> >> Call me a dirty rotten cynic but I just don't see this operational aspect of >> one or more running RPKI hierarchies as part of the IETF. Although you can >> prove me wrong, and I'll concede to an already enacted example where dates >> were set for some artifact. > > We have to have two, parallel hierarchies to avoid a flag day. This > is not a situation where every CA can decide, locally, when to > transition, because the the alg change affect ALL RPs. We are talking years. The overlap will be significant. And I disagree - in this case every CA has to consciously decide - there may well be a situation that a mid term operational impact requires an important CA in the middle of the chain to delay. That then renders all dates specified in any RFC next to meaningless. >> >> I'm still not with you on this - I understand that it makes life easy to say >> "the IETF said 12/12/2018 is D-Day, get with it" .. ... buuuutt I see that >> as a step beyond what the IETF should do. > > If not the IETF, then whom? The IETF (via SIDR) is the author of the > CP. This is an extension of the CP, in many respects. The IETF (via SIDR) doesn't implement the hierarchy, nor operate the CAs. Perhaps the parent(s) and 'non-leaf' CAs should work on this and issue a statement of transition in following RFCXXXX (this draft). I'm reasonably sure the non-leaf CAs are capable of making noise when required ;) As an example of flag day events, even though RFC5855 ( Nameservers for IPv4 and IPv6 Reverse Zones ) was published as an IETF document. It was left to the various operators (root-servers, reverse-servers et al) to work on the transition. Admittedly no change was required on the user's software. The principle isn't that much different. What I do like about the document is the pre-canned phases, of what happens when, and how. This is good.. and I think that satisfies the request from the SEC ADs, but specifying the "when" in IETF - I just don't buy. Cheers Terry _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
