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@xxxxxxxxxxxxx>
To: "Alissa Cooper" <alissa@xxxxxxxxxx>; "Dan Romascanu"
<dromasca@xxxxxxxxx>
Cc: <gen-art@xxxxxxxx>;
<draft-ietf-anima-bootstrapping-keyinfra.all@xxxxxxxx>; <ietf@xxxxxxxx>;
<anima@xxxxxxxx>
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@xxxxxxxxxx>
> To: "tom petch" <daedulus@xxxxxxxxxxxxx>; "Dan Romascanu"
> <dromasca@xxxxxxxxx>
> Cc: <gen-art@xxxxxxxx>;
> <draft-ietf-anima-bootstrapping-keyinfra.all@xxxxxxxx>;
<ietf@xxxxxxxx>;
> <anima@xxxxxxxx>
> 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@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
>
