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@xxxxxxxxxxxxx> 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@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/ >> >> > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
