Subject: Re: [Gen-art] Gen-ART review of draft-ietf-sidr-algorithm-agility-09

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 7 Jan 2013 17:02:07 +0000

David,

I just published version 10 of the document with all the agreed changes. Thanks again for your review.

Roque

On Dec 31, 2012, at 8:57 PM, "Black, David" <[email-masked]> wrote:

> Steve,
> 
> This all looks good; thanks for the quick response.
> 
>>> [*] 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.
> 
> Magnificent - that'll be a significant improvement.
> 
>>> 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.
> 
> That sounds reasonable.
> 
>>> 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.
> 
> That's ok with me, but I thought it was worth asking.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Stephen Kent [mailto:[email-masked]]
>> Sent: Monday, December 31, 2012 2:35 PM
>> To: Black, David
>> Cc: [email-masked]; Sean Turner; [email-masked]; [email-masked]; Stewart
>> Bryant
>> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09
>> 
>> 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.
>> 
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 7 Jan 2013 12:16:38 -0500

Roque,

That new version looks good.  Could you also take a look at this editorial
suggestion that Steve deferred to you?:

OLD

Thanks,
--David

> From: Roque Gagliano (rogaglia) [mailto:[email-masked]]
> Sent: Monday, January 07, 2013 12:02 PM
> To: Black, David
> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; [email-masked];
> [email-masked]; Stewart Bryant (stbryant)

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Mon, 7 Jan 2013 17:52:00 +0000

Hi David,

> suggestion that Steve deferred to you?:

Ok, sorry about that.

> that relationship should be defined and/or explained before it is used.

The idea in the different figures is that the vertical alignment differentiates the different publication points.

What about adding the following text? 

"The vertical alignment in the figure distinguishes between the different publication points and the characters '|->' are used for visualization purpose."

> "certificate" is the important change):

All done and thanks.

Roque

---

From: "Black, David" <[email-masked]>
Date: Mon, 7 Jan 2013 13:53:56 -0500

Hi Roque,

> "The vertical alignment in the figure distinguishes between the different
> publication points and the characters '|->' are used for visualization
> purpose."

I think there's more going on than just publication point change.

Here's the entire figure, plus the one existing sentence about
the '|->' notation:

   CA X-Certificate-Algorithm-Suite-A (Cert-XA)
           |
           |-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
                   |-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
                           |-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
                           |-> CA-Z-Signed-Objects-Algorithm-Suite-A
                   |-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
                   |-> CA-Y-Signed-Objects-Algorithm-Suite-A
           |-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
           |-> CA-X-Signed-Objects-Algorithm-Suite-A

   Note: Cert-XA represent the certificate for CA X, that is signed
   using the algorithm suite A.

I believe that the private key corresponding to Cert-XA is used to sign
Cert-YA, e.g., so that Cert-XA is involved in the path validation of
Cert-YA.  It looks like that's part of the relationship represented by
'|->' and (if so) I would like to see a statement to that effect in
addition to your proposed text about different publication points.

Thanks,
--David

> Sent: Monday, January 07, 2013 12:52 PM
> To: Black, David
> Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; [email-masked];
> The idea in the different figures is that the vertical alignment
> differentiates the different publication points.
> 
> "The vertical alignment in the figure distinguishes between the different
> publication points and the characters '|->' are used for visualization
> purpose."
> 
> 
> of
> >> the
> doc
> >> is

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 8 Jan 2013 11:02:16 +0000

Hi David,

I got your point.

What about this text for that paragraph?

"The following figure illustrates the format used to describe signed objects in the repository. It reflects the algorithm suites in use, and shows the relationship between three CAs (X, Y, and Z) that form a certificate chain. The vertical alignment in the figure distinguishes between objects signed by the same CA using the same private key. The vertical alignment also represents the composition of the different publication points as a component of the RPKI repository. The characters "|->" are used for visualization purpose. As an example taken from the figure, the objects CA-Y-Certificate-Algorithm-Suite-A,  CA-X-CRL-Algorithm-Suite-A and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key corresponding to CA-X-Certificate-Algorithm-Suite-A and published at that CA correspondent publication point."

Roque

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 15 Jan 2013 11:53:16 +0000

dear WG/Gen-Art, 

David and I discussed the new text that will improve this description to complete the GenArt review. 

Text to be added to section 4:
"The following figure shows an example of the structure of signed objects in the repository, indicating the algorithm suites in use, and showing the relationships between three CAs (X, Y, and Z) that form a certification chain. Vertical alignment in the figure indicates objects signed by the same CA using the same private key. The differences in horizontal indentation also represent use of different publication points for objects signed by different CAs. The characters "|->" are used for visualization purposes for both the signing relationship and the publication point change. For example, the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-Suite-A and CA-X-Signed-Objects-Algorithm-Suite-A are all signed using the private key corresponding to CA-X-Certificate-Algorithm- Suite-A and published at CA X's corresponding publication point."

You will get a new version notification in your inbox.

Roque

On Jan 8, 2013, at 12:02 PM, Roque Gagliano (rogaglia) <[email-masked]> wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "Black, David" <[email-masked]>
Date: Thu, 17 Jan 2013 00:38:20 -0500

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

> From: Black, David
> Sent: Friday, December 28, 2012 3:26 PM
> To: [email-masked]; Stephen Kent; Sean Turner; [email-masked]
> Cc: Black, David; [email-masked]; 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.
> 
> and C) from prior sections.  This also affects Sections 6 and 7.
> should enable removal of the Suite C concept from this draft.  I
>   == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 17 Jan 2013 08:49:12 +0000

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