Re: [Gen-art] Genart telechat review of draft-ietf-anima-bootstrapping-keyinfra-28

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