Re: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28
tom petch <daedulus@btconnect.com> Fri, 18 October 2019 16:38 UTC
Return-Path: <daedulus@btconnect.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33812000F; Fri, 18 Oct 2019 09:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.734
X-Spam-Level: *
X-Spam-Status: No, score=1.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FAKE_REPLY_C=1.486, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCXE9uNcHPTW; Fri, 18 Oct 2019 09:38:28 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70128.outbound.protection.outlook.com [40.107.7.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC23D120103; Fri, 18 Oct 2019 09:38:27 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jxsJxxLcSyrJT8uSIF9LBsKJdHoZACL5eOvtLZOY8nsg/MY8HCd6R4YdrV1fysZe6ePkz7a8LoUJs9fhdUmWq49012xzFfsgUUJk3o2x9qKdEgLuBxg9CHOF9pNHyHANrZU9OjfqtjpxkMcmd+z7pUN7vMxIhaD1cbxs7ZXp/C937NSOoowJ9Reu6LFTlrQkYHI+Km+kbID02SD4005ZHwOkon7t2lUkugP2PKayYMz1jZ0hKLOiazkMKj0BnARaJxyls6DwTpc3l2m3HCjx9K2OAT3FNW1zeE8rsfbe44gqE00PL7oK5eexh9Q3E8lVDVF1t1vznQbwvVD3/Tt6OA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/aAKMaHAUqEyUi++QRZB5bXqjluacy69hV8Y7vaVRi0=; b=JcjPdPScI4i7hwj3E1T5CdlOZmVRd23Ml7y2t9hNzZpiZ2gGF1snZa2wsKguS85mkS2U2KYWGX6TThXBO6yinaxD4cjubaJ4PNGfmghx+/KcZNNgISeDb7AncoE3Gw84ETkfvIeREhsucVzN35G0JaKp/Gj70Z/7sIFBS4HueVVPyO6ueMQUldt4tftfB9IzPU3lmEBlVfdjKjss+Kp/+gQwYPjTzFLpluBymUjZ7dPkBG6hh5rU+SJhWhbTFQevKRv1vAjzFDKpbX2id3qwVd86e3ui+mpvNSzz5ps1+lKPR+F1lj+Ld25e6lyMEez1auzMHFVvgsnBqnUQpL/vbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/aAKMaHAUqEyUi++QRZB5bXqjluacy69hV8Y7vaVRi0=; b=cv8Z7ai9+AjUwaJqKirNTUCLjqKTsk0gUJTkqbdMlVlamNuyQ0bAN6lY37OYmtuZ4wh1r+cNIlM6WttBXJlfLEH1Y0fagx6UsC7wxcj4xpIclPvZjd7YyqP98eri4Cgn2IzsOq8o/CVldwJDX5jAKBloUYVPMviPCUafPWiNZ6U=
Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB6340.eurprd07.prod.outlook.com (10.186.173.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.16; Fri, 18 Oct 2019 16:38:24 +0000
Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::fc43:ed41:fb5:b5e3%3]) with mapi id 15.20.2347.021; Fri, 18 Oct 2019 16:38:24 +0000
From: tom petch <daedulus@btconnect.com>
To: tom petch <daedulus@btconnect.com>, Alissa Cooper <alissa@cooperw.in>, Dan Romascanu <dromasca@gmail.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org" <draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "anima@ietf.org" <anima@ietf.org>
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28
Thread-Topic: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28
Thread-Index: AQHVhdJ1yd94RaKkVUSX4P9kACAk8w==
Date: Fri, 18 Oct 2019 16:38:24 +0000
Message-ID: <010f01d585d2$20570d60$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0352.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::28) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.211.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e1be132e-aa0d-4ed3-33b4-08d753e9980c
x-ms-traffictypediagnostic: AM0PR07MB6340:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <AM0PR07MB63400C63EB43D6168ED5FA24C66C0@AM0PR07MB6340.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:3276;
x-forefront-prvs: 01949FE337
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(396003)(366004)(376002)(136003)(13464003)(199004)(189003)(14444005)(54906003)(99286004)(476003)(81686011)(81816011)(26005)(52116002)(966005)(66446008)(229853002)(296002)(4001150100001)(316002)(44716002)(6486002)(6436002)(8936002)(44736005)(102836004)(66556008)(6116002)(66946007)(62236002)(256004)(3846002)(486006)(5660300002)(2906002)(14496001)(50226002)(53546011)(14454004)(6506007)(386003)(66476007)(64756008)(7736002)(71190400001)(81166006)(81156014)(66066001)(1556002)(71200400001)(66574012)(61296003)(8676002)(4326008)(6306002)(305945005)(25786009)(86362001)(4720700003)(110136005)(9686003)(478600001)(6246003)(6512007)(186003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB6340; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: s6gaI0GkC5pnlKWdkC5UA3aDUHdRSTWwSDRIfbB1rhoI/E0xrGo33DECfSKQQQHGeyvlpdBXPnT3HeTIEm0HDs5m41mM4o7M93xUa+Ft1cX9nJHRpSC7Bc0R2PLK6gAShhC5I3fSf9fmD0w+3TtURuNFgf3T/ksyYnZtiFONKUceZrCtHSZs+7LKfT3jr46dTcV9c7CcAv8EzMW1k2zuTzCbrriEZ3LW1TO/NyPngPLs6oijUL+8xfug1ykYTx0L8T6WhhpwGuQRajqBLGOmLHekIV58+UWj2kK0nOm8fMxk3mimPphtey5k3wgHVoufQKFDmSw6OSF+DA3Xlkx/kui8ZvYf/TGBnmavzZ7PTZVY74dwH3dQ9PyBJgeOwezcWEbxR/PK11NgAFO24ImXYABzD7uPyrDNldwgbN9l8B3NhVaU1ZdeVdmNwRksVzEii/S5/bhviEfJzQ5VpWP7fQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <E00A655B22F99C4CAA77DE4E35AF9B03@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e1be132e-aa0d-4ed3-33b4-08d753e9980c
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2019 16:38:24.3874 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GvpDdTYaUR735tLV7poVI0wna6xOWqmasKR9GSGFraTkF0ChG1gIXlEII7IqlPK0wcjr+/QfCwGK74PS6Cs2fw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6340
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/SMS9uYMZiJVQy46XjKAEZ330UzI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 16:38:30 -0000
A third set of comments The refine look ok to me (but I still recommend a formal review) leaf proximity-registrar-cert { description .. as specified by RFC 5280, .. as specified in ITU-T X.690. needs references; I suggest reference "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile ITU-T X.690: Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)."; plus [ITU.X690.2015] International Telecommunication Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/>. in the I-D Normative References Appendix A. IPv4 and non-ANI operations / The secification/ The specification/ Sorry for the bitty postings; more haste less speed. Tom Petch ----- Original Message ----- From: "tom p." <daedulus@btconnect.com> To: "Alissa Cooper" <alissa@cooperw.in>; "Dan Romascanu" <dromasca@gmail.com> Cc: <gen-art@ietf.org>; <draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org>; <ietf@ietf.org>; <anima@ietf.org> Sent: Friday, October 18, 2019 1:11 PM Subject: Re: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28 > Looking some more at this I-D, I have more concerns about the YANG > module. My review is informal - I recommend that the WG Chair request a > formal review because I may be missing something particularly in > connection with the 'refine' statements. > > The I-D has > namespace > "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; > prefix "vch"; > whereas RFC8366, which it augments, has > namespace "urn:ietf:params:xml:ns:yang:ietf-voucher"; > prefix vch; > Different module, same prefix; this contradicts a SHOULD NOT in RFC8407. > > Further, this I-D defines > import ietf-voucher { > prefix v; > i.e. does not use the prefix defined in RFC8366. This contradicts a > MUST in RFC8407. > > There is a discrepancy between the e-mail addresses of the authors of > the YANG module and of the I-D, for > Author: Kent Watsen > Author: Toerless Eckert > I note that the e-mail addresses for the YANG module are the same as > those for the YANG module in RFC8366; I do not know which are correct. > > contact > "WG Web: <http://tools.ietf.org/wg/anima/> > should be https: and usually points to datatracker.ietf.org not tools > > Tom Petch > > ----- Original Message ----- > From: "Alissa Cooper" <alissa@cooperw.in> > To: "tom petch" <daedulus@btconnect.com>; "Dan Romascanu" > <dromasca@gmail.com> > Cc: <gen-art@ietf.org>; > <draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org>; <ietf@ietf.org>; > <anima@ietf.org> > Sent: Wednesday, October 16, 2019 3:57 PM > > Dan, thanks for your review. Tom, thanks for your response. I entered a > DISCUSS ballot to make sure the issues with the YANG modules get fixed. > I also noted the need for a response to the full Gen-ART review. > > Alissa > > > > On Oct 15, 2019, at 5:40 AM, tom petch <daedulus@btconnect.com> wrote: > > > > Dan > > > > I had a quick look at the YANG and it does indeed need some work IMHO. > > I have posted a separate e-mail listing what I saw. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Dan Romascanu via Datatracker" <noreply@ietf.org> > > Sent: Sunday, October 13, 2019 9:39 AM > > > >> Reviewer: Dan Romascanu > >> Review result: Ready with Issues > >> > >> I am the assigned Gen-ART reviewer for this draft. The General Area > >> Review Team (Gen-ART) reviews all IETF documents being processed > >> by the IESG for the IETF Chair. Please wait for direction from your > >> document shepherd or AD before posting a new version of the draft. > >> > >> For more information, please see the FAQ at > >> > >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > >> > >> Document: draft-ietf-anima-bootstrapping-keyinfra-?? > >> Reviewer: Dan Romascanu > >> Review Date: 2019-10-13 > >> IETF LC End Date: None > >> IESG Telechat date: 2019-10-17 > >> > >> Summary: Ready with Issues > >> > >> This document specifies automated bootstrapping of an Autonomic > > Control Plane > >> by creating a Remote Secure Key Infrastructure (acronym BRSKI) using > >> manufacturer installed X.509 certificates, in combination with a > > manufacturer's > >> authorizing service, both online and offline. > >> > >> Christian Huitema and Jari Arkko have performed early reviews of > > previous > >> versions of the document for SecDir and Gen-ART. As far as I can > tell, > > most if > >> not all of their major concerns concerning applicability and security > > have been > >> addressed in the latest versions. A few more minor issues described > > below would > >> better be clarified before approval. > >> > >> I also observe that the document has consistent Operational > > implications but > >> there is no OPS-DIR review so far, as well as a YANG module and > > several other > >> references to YANG, but there is no YANG Doctors review. I hope that > > these will > >> be available prior to the IESG review. > >> > >> Major issues: > >> > >> Minor issues: > >> > >> 1. The Pledge definition in section 1.2: > >> > >>> Pledge: The prospective device, which has an identity installed at > >> the factory. > >> > >> while in the Introduction: > >> > >>> ... new (unconfigured) devices that are called pledges in this > >> document. > >> > >> These two definitions seem different. The definition in 1.2 does not > > include > >> the fact that the device is 'new (unconfigured'. Also, arguably > > 'identity > >> installed at the factory' may be considered a form of configuration. > >> > >> 2. The document lacks an Operational Considerations section, which I > > believe is > >> needed, taking into consideration the length and complexity of the > > document. > >> There are many operational issues spread across the document > > concerning the > >> type and resources of devices, speed of the bootstrapping process, > > migration > >> pass, impact on network operation. I suggest to consider adding such > a > > section > >> pointing to the place where these issues are discussed and adding the > > necessary > >> information if missing. Appendix A.1 in RFC 5706 can be used as a > > checklist of > >> the issues to be discussed in such a section. > >> > >> 3. Section 5.4: > >> > >>> Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is > >> REQUIRED. > >> > >> What is the reason for using 'encouraged'? Why not RECOMMENDED? > >> > >> Nits/editorial comments: > >> > >> 1. The Abstract includes: > >> > >> 'To do this a Remote Secure Key Infrastructure (BRSKI) is created' > >> > >> Later in the document BRSKI is idefined as a protocol. It would be > > good to > >> clarify if BRSKI = BRSKI protocol > >> > >> 2. In Section 1 - Introduction, 3rd paragraph: > >> > >> s/it's default modes/its default modes/ > >> s/it's strongest modes/its strongest modes/ > >> > >> 3. Please expand non-obvious acronyms at first occurrence: EST > > protocol, LLNs, > >> REST interface, LDAP, GRASP, CDDL, CSR > >> > >> 4. I would suggest alphabetic order listing of the terms in section > > 1.2 > >> > >> 5. Section 1.3.1 - a reference for LDevID would be useful > >> > >> 6. Section 7: > >> > >> s/Use of the suggested mechanism/Use of the suggested mechanisms/ > >> > >> > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art@ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art >
- Genart telechat review of draft-ietf-anima-bootst… Dan Romascanu via Datatracker
- Re: Genart telechat review of draft-ietf-anima-bo… tom petch
- Re: [Gen-art] Genart telechat review of draft-iet… Alissa Cooper
- Re: [Gen-art] Genart telechat review of draft-iet… tom petch
- Re: [Gen-art] Genart telechat review of draft-iet… tom petch
- Re: [Gen-art] Genart telechat review of draft-iet… Michael Richardson
- Re: [Anima] [Gen-art] Genart telechat review of d… Michael Richardson