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
