Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11

["Roque Gagliano (rogaglia)" <[e-mail]>]

Thank YOU David for been such a great reviewer.

I will solve the Idnits in my working version waiting for other comments during IESG review.

Regards,
Roque



On Jan 17, 2013, at 6:38 AM, "Black, David" <[e-mail]> wrote:

> The -11 version of this draft resolves all of the concerns raised by the
> Gen-ART review of the -09 version.  I want to thank the authors for the
> timely and productive manner in which the review's concerns were addressed.
> 
> idnits 2.12.13 found a minor line length problem that can be left to the
> RFC Editor to correct.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Black, David
>> Sent: Friday, December 28, 2012 3:26 PM
>> To: [e-mail]; Stephen Kent; Sean Turner; [e-mail]
>> Cc: Black, David; [e-mail]; Stewart Bryant
>> Subject: Gen-ART review of draft-ietf-sidr-algorithm-agility-09
>> 
>> 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
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>