David, I just published version 10 of the document with all the agreed changes. Thanks again for your review.
Roque On Dec 31, 2012, at 8:57 PM, "Black, David" <[email protected]> wrote: > 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
