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

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
>