Some comments. Section 4.3. Phase 0
I'm still struggling to see the necessity to put in the operational dates for a Alg shift in [I-D.ietf-sidr-rpki-algs]. I concur that the future Alg suite and to be EOL's suite should be identified once suitable candidates have been selected in rpki-algs. But the dates in which the ALGs come into effect[1], and are twiglighted/EOL'd seems like a operational CA/RP concern, in a hierarchical manner, and would probably end up in the CA's CPS. As such I question the viability, and validity, of fixing dates in the IETF. [1] I would think that as soon at the document is updated and published they are able to be used. Phase 3 This section confuses me, the draft says that the RF MUST be able to do both algorithms, but its recommended to only use Suite B. The first sentence seems superfluous to me. Why not just: " Phase 3 starts at the RP Ready Algorithm B Date. During this phase, all signed product sets are available using both algorithm suites. It is RECOMMENDED that RPs utilize only Suite B for validation throughout this phase, in preparation for Phase 4. RPs MAY use Suite A if operationally necessary" ? (ie similar wording as used in the Phase 4 Suite A/C observation.) If that first sentence part " RPs MUST be able to .." is a necessity, it makes me start thinking about a matrix decision process of using Suite A (and|or) Suite B - which isn't described here. or perhaps not even mention the RP's responsibility to Suite A in Phase 3?? ... Phase 4. The ordering of the sentences could be shuffled I think. The important statement is that the "CAs MUST neither issue nor publish signed products using Algorithm Suite C" ... therefore any erroneous issuance of suite C products MUST be considered invalid. Section 5. I think some discussion of the dates, and for communicating twilight and EOL dates between the parent and the child should be here. I don't quite hold the belief that it's a unidirectional downward assertion from parent to child. In may well be in PKI - there there is a raft of operational interaction that surrounds that. Section 6. Can you spell out what you technically mean by "keep any relationship between " in para 1? Section 7. Can you expand the recommendation in keeping the parallel certificate hierarchies in sync by also identifying the Alg A/Alg C mix? (phase 4) Twilight doesn't necessarily mean "dead wood is o.k".. since products MAY still be constructed. .. If these concerns can be addressed, then I think the document is ready to move on. Cheers Terry On 21/10/11 12:50 AM, "Sandra Murphy" <sandra.mur...@sparta.com> wrote: > The authors have requested a WG LC for draft "Algorithm Agility Procedure > for RPKI." > > The document and the draft version history are available at > http://tools.ietf.org/html/draft-ietf-sidr-algorithm-agility-03 > > The last call will end Thu, 3 Nov 2011 (AOE). > > As usual, please address all comments to the WG mailing list, and > please be clear in your comments to this last call if you are > supporting the document's submission to the IESG or if you are > opposed. If you are opposed, please indicate why. > > --Sandy, speaking as wg chair with appropriate ceremonial garb donned > (and covered with ashes for having neglected this) > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr