Skip to main content

Last Call Review of draft-ietf-alto-unified-props-new-18
review-ietf-alto-unified-props-new-18-secdir-lc-wouters-2021-09-15-00

Request Review of draft-ietf-alto-unified-props-new
Requested revision No specific revision (document currently at 24)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2021-08-26
Requested 2021-08-12
Authors Wendy Roome , Sabine Randriamasy , Y. Richard Yang , Jingxuan Zhang , Kai Gao
I-D last updated 2021-09-15
Completed reviews Opsdir Last Call review of -18 by Scott O. Bradner (diff)
Artart Last Call review of -18 by Spencer Dawkins (diff)
Secdir Last Call review of -18 by Paul Wouters (diff)
Assignment Reviewer Paul Wouters
State Completed
Request Last Call review on draft-ietf-alto-unified-props-new by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/uhS5FKY1XLGQLvEVkLjx6AxMWMU
Reviewed revision 18 (document currently at 24)
Result Has nits
Completed 2021-09-15
review-ietf-alto-unified-props-new-18-secdir-lc-wouters-2021-09-15-00
I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the  IESG.  These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

The summary of the review is Has Nits

This document extends RFC 7285 (the ALTO protocol) with some new registries and
values. As such, there is no real change to the protocol, only to the possible
information conveyed via the ALTO protocol. Therefor it is appropriate to refer
to RFC 7285 for the Security Considerations, as is done in this document.

While extensions to a protocol don't necessitate an Updates: clause, in this
case I think it should because the document addresses shortcomings in the
original protocol. That is, new implementations are expected to really require
implementing this new document as part of the "core specification". Thus
implementers reading 7285 should really be warned to also read (and implement)
this document.

The IANA considerations are quite verbose. Usually, this section only contains
the minimal information for an IANA operator to read to implement the requested
changes. In this case there is lots of text on justifying things that are
better omitted or written out in another section.

The new IANA registries do not all seem to allow for private use registrations?
This means technically any new value cannot be tested unless by violating the
RFC. At least, that is my reading but I'm a little confused by it.