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

From: tom petch <[email-masked]>
Date: Tue, 29 Oct 2019 09:44:09 +0000

seeing if I can switch from ietf to Last Call
inline

Tom Petch

----- Original Message -----
From: "Michael Richardson" <[email-masked]>
Sent: Monday, October 28, 2019 10:06 PM

> tom petch <[email-masked]> wrote:
>     > 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.
>
> okay, so I shoudl change it to "vcr" for VouCher Request then?
> I think that this will have affects on the constrained-voucher
document, but
> that is easily fixed.

I would go for 'vchr' since voucher is 'vch' in RFC8366 and 'r' can then
mean request. but then the voucher extension is 'vcj'.  So, just a
personal preference for 'vchr'; else ok for this e-mail

Tom Petch

>     > 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.
>
> okay, got it, fixed it.
>
>     > 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:
>
> Fixed.
>
>     > 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.
>
> People moved to different companies since publication :-)
>
>     >   contact "WG Web: <http://tools.ietf.org/wg/anima/> should be
https:
>     > and usually points to datatracker.ietf.org not tools
>
> Fixed.
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-

---

From: tom petch <[email-masked]>
Date: Tue, 29 Oct 2019 11:49:39 +0000

Michael

I just saw -29 after my last message and it still needs work.

Appendix C confuses me.  The reference to it from IANA Considerations
suggests that it is Normative but there is nothing in it to say that it
is and my take is that by default it is Informational.

It contains a YANG module which
- lacks references on import statements
- lacks authors
- lacks copyright
- is not listed in IANA Considerations
- has http: not https:
- has a reference clause with a different title to that of the I-D
- mixes URI and URL
all in 35 lines :-)

The YANG module in s.3.4
- references RFC8040 which is not in the I-D References
- references
  Voucher Profile for Bootstrapping Protocols
whereas this I-D has a title of
  Bootstrapping Remote Secure Key Infrastructures (BRSKI)
- has
  // Grouping defined for future usage
whereas the grouping is used in the previous YANG statement which leaves
me puzzled
- lacks YANG reference statements for
          leaf proximity-registrar-cert {
i.e. RFC5280, X.690, RFC8446
- has [RFC8446] which looks like an XML/HTML anchor where a YANG module
must be plain text

- IANA Considerations does not register either module, 3.4 or Appendix
C, as per RFC6020 s.14

- Security Consideratrions does not include the required YANG
considerations which in turn generates further Normative References

- Appendix A
/The secification/The specification/

Tom Petch

----- Original Message -----
From: "tom petch" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Cc: <[email-masked]>;
<[email-masked]>; "Alissa Cooper" <[email-masked]>; "Last Call"
<[email-masked]>; "Dan Romascanu" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, October 29, 2019 9:44 AM

> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call