Skip to main content

Last Call Review of draft-ietf-sidr-algorithm-agility-11

Request Review of draft-ietf-sidr-algorithm-agility
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-02-05
Requested 2013-01-24
Authors Roque Gagliano , Stephen Kent , Sean Turner
I-D last updated 2013-02-04
Completed reviews Genart Last Call review of -09 by David L. Black (diff)
Genart Telechat review of -11 by David L. Black (diff)
Genart Last Call review of -11 by David L. Black (diff)
Secdir Last Call review of -08 by Brian Weis (diff)
Assignment Reviewer David L. Black
State Completed
Review review-ietf-sidr-algorithm-agility-11-genart-lc-black-2013-02-04
Reviewed revision 11 (document currently at 12)
Result Ready
Completed 2013-02-04

One (final, I hope) comment in response to the second last call on this draft.

I think publication as a BCP is definitely appropriate, as this draft is
entirely about a transition process.




 Roque Gagliano (rogaglia) [rogaglia at]


 Thursday, January 17, 2013 3:49 AM


 Black, David


 Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; gen-art at;
 sidr at; Stewart Bryant (stbryant)


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

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.



On Jan 17, 2013, at 6:38 AM, "Black, David" < at> 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: rogaglia at; Stephen Kent; Sean Turner; gen-art at

>> Cc: Black, David; sidr at; 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

>> <>.


>> 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


>> 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


>> 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

>> at        Mobile: +1 (978) 394-7754

>> ----------------------------------------------------