Skip to main content

Last Call Review of draft-thaler-iftype-reg-05
review-thaler-iftype-reg-05-secdir-lc-shore-2019-10-25-00

Request Review of draft-thaler-iftype-reg
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-11-07
Requested 2019-10-10
Authors Dave Thaler , Dan Romascanu
I-D last updated 2019-10-25
Completed reviews Genart Last Call review of -06 by Peter E. Yee (diff)
Tsvart Last Call review of -05 by Tommy Pauly (diff)
Secdir Last Call review of -05 by Melinda Shore (diff)
Tsvart Last Call review of -06 by Tommy Pauly (diff)
Secdir Telechat review of -06 by Melinda Shore (diff)
Assignment Reviewer Melinda Shore
State Completed
Request Last Call review on draft-thaler-iftype-reg by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/S271QjGXL4oUJrimc5EytGH2sN0
Reviewed revision 05 (document currently at 07)
Result Has issues
Completed 2019-10-25
review-thaler-iftype-reg-05-secdir-lc-shore-2019-10-25-00
This document is an update to RFC 2863, providing revised
guidelines for the definition of new interface types and
tunnel types.  In doing so it introduces some guidance for
the development of YANG ifType and tunnelType modules, 
which was not previously covered elsewhere.

To be honest I found the writing occasionally difficult
to follow, as the text was not as well-structured as we
usually see in mature IETF documents.  Even the abstract
doesn't really get to the point until the last sentence.
Similarly, section 7 opens with a comment on some misguidance
on request submission in the MIB module, while I
think it would be much clearer to say "Requests may be
submitted to IANA via email at iana@iana.org, or via
a web form at https://www.iana.org/form/iftype" followed
by some text pointing out the misguidance.   The 
request to IANA to update the MIB module could be dropped
down into IANA considerations (section 8).

Nit:  In section 7 "iana&iana.org" should be "iana@iana.org."

Security considerations:  It might be reasonable to argue
that a document providing guidelines for registering a 
new MIB or YANG interface type module has no security considerations,
but it's worth noting that other documents do include some text.  
See, for example, RFC 6117 on the registration of ENUM services,
which does provide guidance on security considerations to authors 
of new Enumservice Types), and RFC 8436, on DSCP Pool 3 IANA
registration procedures, points authors to the documents
defining new DSCP values.  Sections 6.3.1 and 6.3.2 could/should
provide some broad guidance on writing security considerations
for new ifType and tunnelType modules.

So, I think there's a bit more to say there but ultimately this one 
would be up to the OPS ADs.