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

[tom petch <[e-mail]>]

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" <[e-mail]>
To: "tom petch" <[e-mail]>; "Dan Romascanu"
<[e-mail]>
Cc: <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>
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 <[e-mail]> 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" <[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/
>>
>>
>
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art