Reviewer: Melinda Shore Review result: Has Issues 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@xxxxxxxx, 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@xxxxxxxx." 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
