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