Re: [secdir] [Last-Call] Secdir last call review of draft-thaler-iftype-reg-05

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@ietf.org> 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@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.
> 
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call