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@xxxxxxxx> 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/ > >
