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.