Last Call Review of draft-ietf-sidr-algorithm-agility-09
review-ietf-sidr-algorithm-agility-09-genart-lc-black-2012-12-28-00

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