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" <daedulus@xxxxxxxxxxxxx>
To: "Michael Richardson" <mcr+ietf@xxxxxxxxxxxx>
Cc: <draft-ietf-anima-bootstrapping-keyinfra.all@xxxxxxxx>;
<gen-art@xxxxxxxx>; "Alissa Cooper" <alissa@xxxxxxxxxx>; "Last Call"
<last-call@xxxxxxxx>; "Dan Romascanu" <dromasca@xxxxxxxxx>;
<anima@xxxxxxxx>
Sent: Tuesday, October 29, 2019 9:44 AM
> seeing if I can switch from ietf to Last Call
> inline
>
> Tom Petch
>
> ----- Original Message -----
> From: "Michael Richardson" <mcr+ietf@xxxxxxxxxxxx>
> Sent: Monday, October 28, 2019 10:06 PM
>
> > tom petch <daedulus@xxxxxxxxxxxxx> 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 <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
>
> --
> last-call mailing list
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
