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
> -----Original Message-----
> From: Roque Gagliano (rogaglia) [mailto:[email protected]]
> Sent: Monday, January 07, 2013 12:52 PM
> To: Black, David
> Cc: Roque Gagliano (rogaglia); Stephen Kent; Sean Turner; [email protected];
> [email protected]; Stewart Bryant (stbryant)
> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09
>
> Hi David,
>
> On Jan 7, 2013, at 6:16 PM, "Black, David" <[email protected]> wrote:
>
> > Roque,
> >
> > That new version looks good. Could you also take a look at this editorial
> > suggestion that Steve deferred to you?:
> >
>
> Ok, sorry about that.
>
> > 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.
>
> 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."
>
>
> > 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):
>
> All done and thanks.
>
> Roque
>
> > 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.
> >
> > Thanks,
> > --David
> >
> >> -----Original Message-----
> >> From: Roque Gagliano (rogaglia) [mailto:[email protected]]
> >> Sent: Monday, January 07, 2013 12:02 PM
> >> To: Black, David
> >> Cc: Stephen Kent; Roque Gagliano (rogaglia); Sean Turner; [email protected];
> >> [email protected]; Stewart Bryant (stbryant)
> >> Subject: Re: Gen-ART review of draft-ietf-sidr-algorithm-agility-09
> >>
> >> 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 protected]> 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 protected]]
> >>>> Sent: Monday, December 31, 2012 2:35 PM
> >>>> To: Black, David
> >>>> Cc: [email protected]; Sean Turner; [email protected]; [email protected];
> >> 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.
> >>>>
> >>>
> >>
> >
>
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
