Steve, This all looks good; thanks for the quick response.
> > [*] Section 4.7 changes the meaning of the algorithm suite names (A, B > > and C) from prior sections. > I have deleted all references to Alg Suite C throughout the doc, and > revised the text accordingly. Magnificent - that'll be a significant improvement. > > 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: > I agree that "will be" needs to be changed to "MUST be" in a few places, > starting on page 5 (Section 2) where the need to update the CP and to publish > an > alg transition timetable are first mentioned. An examination of the rest of > the > doc shows that this change need be applied only when the alg transition doc is > mentioned. That sounds reasonable. > > 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. > > We defined what "Suite B" is in the terminology section, so I > think no further clarification is required here. That's ok with me, but I thought it was worth asking. Thanks, --David > -----Original Message----- > From: Stephen Kent [mailto:[email protected]] > Sent: Monday, December 31, 2012 2:35 PM > To: Black, David > Cc: [email protected]; Sean Turner; [email protected]; [email protected]; Stewart > Bryant > Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09 > > David, > > > 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. > > I have deleted all references to Alg Suite C throughout the doc, and > revised the text accordingly. > > > 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. > fixed. > > 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. > fixed > > I > > strongly recommend removing the Suite C concept, as the C-A-B > > chronological order of suite introduction dates seems counter-intuitive. > Done. > > > > 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: > I agree that "will be" needs to be changed to "MUST be" in a few places, > starting on page 5 (Section 2) where the need to update the CP and to > publish an > alg transition timetable are first mentioned. An examination of the rest > of the > doc shows that this change need be applied only when the alg transition > doc is > mentioned. > > When "MUST be" is not appropriate, present tense (i.e., "is") is > > preferable. > fixed. > > > > 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. > fixed. > > 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. > fixed. > > 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. > We defined what "Suite B" is in the terminology section, so I > think no further clarification is required here. > > 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. > we need to be able to refer to steady state, separate from the > first milestone in the transition process, but I agree that referring to > it as the first phase of the transition process is confusing. I have > changed the text accordingly. > > 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. > I'll defer to Roque here, as the repository representation is his design. > > 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. > I have added a forward pointer to Section 9 here. > > 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. > ASN = Autonomous System Number. I expended the acronym as it appears > only here. I added a ROA definition to Section 3. > > 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. > I'll let Roque address this issue. > > > > == 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. > fixed. > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
