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

[tom petch <[e-mail]>]

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" <[e-mail]>
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/
>
>