I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-sidr-algorithm-agility-09 Reviewer: David L. Black Review Date: December 28, 2012 IETF LC End Date: December 14, 2012 Summary: This draft is on the right track but has open issues, described in the review. I apologize for the tardy arrival of this review after the end of IETF Last Call for this draft - the last few months have been a rather busy time for me. This draft specifies the algorithm transition process for RPKI, which entails coordinated issuance of new certificates and other signed products across the collection of RPKI CAs in a fashion that ensures that at least one set of signed products is usable at all times. The draft is generally well-written and clear, but has an unfortunate nomenclature change problem that is the primary open issue[*]. Major issues: [*] Section 4.7 changes the meaning of the algorithm suite names (A, B and C) from prior sections. This also affects Sections 6 and 7. I have classified this as a major issue as I believe it introduces severe lack of clarity (and potential ambiguity) into the following two paragraphs in Section 7: During Phase 1, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite B, if that certificate exists. During Phase 4, a CA that revokes a certificate under Suite A SHOULD revoke the corresponding certificate under Suite C, if that certificate exists. During Phase 1, a CA may revoke certificates under Suite B without revoking them under Suite A, since the Suite B products are for test purposes. During Phase 4 a CA may revoke certificates issued under Suite C without revoking them under Suite A, since Suite C products are being deprecated. Despite the use of three letters (A, B and C), there are only two algorithm suites involved, and different instances of Suite A refer to different algorithm suites. In each paragraph, the first instance of "Suite A" refers to the same algorithm suite as "Suite C", and the second instance of "Suite A" refers to the same algorithm suite as "Suite B". It would be much better and clearer to not change the meaning of the algorithm suite names until the EOL date. In addition, this change should enable removal of the Suite C concept from this draft. I strongly recommend removing the Suite C concept, as the C-A-B chronological order of suite introduction dates seems counter-intuitive. Minor issues: Starting in Section 4.3.1, there are a number of uses of "will be" (future tense) in the milestone and phase descriptions. All of these uses of "will be" should be reviewed to determine whether "MUST be" is appropriate, e.g., as appears to be the case for this sentence in 4.3.1: Additionally, the new algorithm transition timeline document will be published with the following information: When "MUST be" is not appropriate, present tense (i.e., "is") is preferable. Nits/editorial: Abstract: The following two sentences don't quite line up: The process is expected to be completed in a time scale of months or years. Consequently, no emergency transition is specified. Also, section 4.2 indicates that a multi-year transition timeframe is expected, which suggests that "months" is not appropriate in the abstract. Suggested rephrasing: The time available to complete the transition process is expected to be several years. Consequently, no emergency transition process is specified. Section 2. Introduction: The first sentence in the last paragraph mentions a forthcoming BCP on transition timetable. The rest of that paragraph implies that the BCP is for a single transition, as opposed to being a BCP for transitions in general. It would be helpful to clarify that at the start of the paragraph, e.g., by adding "For each algorithm transition," to the start of the paragraph. Section 3 Definitions: Is there any concern about possible confusion of the use of "Suite B" in this draft with NSA Suite B? The draft is clear on what Suite B means for RPKI, but I suspect that RPKI Suite B and NSA Suite B are unlikely to match, if ever. Describing Phase 0 as both the steady state of the RPKI and the first phase of transition is confusing (e.g., in 4.3). It would be clearer if Phase 0 began with publication of the updated RPKI algorithm document (Milestone 1) and that the activities that are unchanged from steady state were described as not changing in phase 0. Starting near the end of section 4.3, the three characters |-> are used in figures to represent an RPKI hierarchy relationship; that relationship should be defined and/or explained before it is used. For clarity, I'd suggest swapping the order of the two paragraphs above that figure in 4.3 and making the following change at the end of the paragraph that is moved down (addition of the word "certificate" is the important change): OLD and shows the relationship between three CAs (X, Y, and Z) that form a chain. NEW and shows the relationships among the three CAs (X, Y, and Z) that participate in a certificate chain. Subsequent uses of |-> seemed clear to me. Section 4.5 Phase 2 says that Suite B product SHOULD be stored at independent publication points, but does not make it clear that this recommendation applies beyond phase 2. I suggest adding text to make that clear - a reference to Section 9 (which is clear about this) may be useful as part of that text. In Section 6, please expand the ROA acronym on first use and consider whether it should be defined in Section 3. I'm also assuming that the ASN acronym is intended to refer to ASN.1 content; if not, that acronym also needs attention. idnits 2.12.13 found a couple of minor nits: ** There is 1 instance of too long lines in the document, the longest one being 23 characters in excess of 72. == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA  01748 +1 (508) 293-7953             FAX: +1 (508) 293-7786 david.black at emc.com        Mobile: +1 (978) 394-7754 ----------------------------------------------------