Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11
"Black, David" <david.black@emc.com> Thu, 17 January 2013 05:38 UTC
Return-Path: <david.black@emc.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41C111E80A3; Wed, 16 Jan 2013 21:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImaQdUdld8VJ; Wed, 16 Jan 2013 21:38:41 -0800 (PST)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9411E809B; Wed, 16 Jan 2013 21:38:40 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0H5cXUl027237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Jan 2013 00:38:34 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 17 Jan 2013 00:38:23 -0500
Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r0H5cMj2016679; Thu, 17 Jan 2013 00:38:22 -0500
Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Thu, 17 Jan 2013 00:38:22 -0500
From: "Black, David" <david.black@emc.com>
To: "rogaglia@cisco.com" <rogaglia@cisco.com>, Stephen Kent <kent@bbn.com>, Sean Turner <turners@ieca.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Date: Thu, 17 Jan 2013 00:38:20 -0500
Thread-Topic: Gen-ART review of draft-ietf-sidr-algorithm-agility-11
Thread-Index: Ac3lOYUa+SMuJHJqQnWqMAKs4+qaRgPOumQw
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71287E873CF@MX15A.corp.emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71287CBF04D@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: "Black, David" <david.black@emc.com>, "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Gen-ART review of draft-ietf-sidr-algorithm-agility-11
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jan 2013 05:38:42 -0000
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@cisco.com; Stephen Kent; Sean Turner; gen-art@ietf.org > Cc: Black, David; sidr@ietf.org; 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. > > 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@emc.com Mobile: +1 (978) 394-7754 > ----------------------------------------------------
- [sidr] Gen-ART review of draft-ietf-sidr-algorith… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Stephen Kent
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Roque Gagliano (rogaglia)
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Roque Gagliano (rogaglia)
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Roque Gagliano (rogaglia)
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Roque Gagliano (rogaglia)
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Black, David
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Roque Gagliano (rogaglia)
- Re: [sidr] Gen-ART review of draft-ietf-sidr-algo… Black, David