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 rev. no specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-11-07
Requested 2019-10-10
Authors Dave Thaler, Dan Romascanu
Draft last updated 2019-10-25
Completed reviews Genart Last Call review of -06 by Peter Yee
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
Secdir Telechat review of -06 by Melinda Shore
Assignment Reviewer Melinda Shore
State Completed
Review review-thaler-iftype-reg-05-secdir-lc-shore-2019-10-25
Posted at https://mailarchive.ietf.org/arch/msg/secdir/S271QjGXL4oUJrimc5EytGH2sN0
Reviewed rev. 05 (document currently at 06)
Review result Has Issues
Review completed: 2019-10-25

Review
review-thaler-iftype-reg-05-secdir-lc-shore-2019-10-25

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.