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: rogaglia at cisco.com; Stephen Kent; Sean Turner; gen-art at ietf.org
> Cc: Black, David; sidr at ietf.org; 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black at emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------