Thanks a lot for your review Melinda! Authors, will you get a chance to look at this before the submission deadline? Regards Suresh > On Oct 25, 2019, at 11:07 PM, Melinda Shore via Datatracker <noreply@xxxxxxxx> wrote: > > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
