Dear Dale, Thank for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Dale Worley via Datatracker [mailto:noreply@xxxxxxxx] > Envoyé : lundi 6 mai 2019 04:22 > À : gen-art@xxxxxxxx > Cc : softwires@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-softwire- > iftunnel.all@xxxxxxxx > Objet : Genart last call review of draft-ietf-softwire-iftunnel-04 > > Reviewer: Dale Worley > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-softwire-iftunnel-04 > Reviewer: Dale R. Worley > Review Date: 2019-05-05 > IETF LC End Date: 2019-05-07 > IESG Telechat date: [not known] > > Summary: > > This draft is ready for publication as a Standards Track RFC. > > Nits/editorial comments: > > Editorial Note (To be removed by RFC Editor) > > This section is a great idea. I haven't seen this usage before. > > Please update the "revision" date of the YANG modules. > > This sentence doesn't say what to update the revision date to. > [Med] The revision date will be updated with the publication date of the (future) RFC. The RFC editor is used with that. > 1. Introduction > > This document specifies the initial version of the iana-tunnel-type > YANG module identifying tunnel interface types. > > This could be made more specific, e.g., > > This document specifies the initial version of the iana-tunnel-type > YANG module containing a collection of IANA maintained YANG > identities identifying tunnel interface types. > [Med] OK. > -- > > 2. IANA Tunnel Type YANG Module > > The initial version of the module includes tunnels types defined in > [RFC4087], [RFC7856], [RFC7870], and [RFC6346]. > > s/tunnels types/tunnel types/ > [Med] Fixed. > Should this mention the provenance of IP-HTTPS, which is in none of > these RFCs? [Med] This is already covered by the "reference" clause. > > identity iphttps { > base ift:tunnel; > description > "IP over HTTPS (IP-HTTPS) Tunneling Protocol."; > reference > "Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling > Protocol Specification, > https://msdn.microsoft.com/en-us/library/dd358571.aspx";; > } > > This type's reference doesn't appear in the list of references. [Med] That is on purpose because otherwise that reference will need to be called out in the core text. > > 3. Security Considerations > > These identies are intended to be > referenced by other YANG modules, and by themselves do not expose any > nodes which are writable, contain read-only state, or RPCs. > > Logically, this is correct, but I think it would read better if > s/contain read-only state/contain readable state/. [Med] I will leave the initial wording. > > 4.1. YANG Module > > The name of the "identity" is the same as the corresponding > enumeration in the IANAifType-MIB (i.e., IANAtunnelType). > > This should be "... is the lower-case of the corresponding enumeration > ...". > > "base": Contains the name assigned to the tunnel type, in > lowercase. > > The description of this item should be "Contains 'ift:tunnel'.". [Med] Good catch. Thanks. > > 6.2. Informative References > > [TUNNELTYPE-IANA-REGISTRY] > Internet Assigned Numbers Authority, "tunnelType > Definitions", <https://www.iana.org/assignments/smi- > numbers/smi-numbers.xhtml#smi-numbers-6>. > > Given that this document specifies substantial interaction with this > registry, this reference should be normative. [Med] We used to have this one as normative but we received comments asking to move it informative. I will leave this one to the AD. > > The title of this reference cannot be "tunnelType Definitions", > because that text does not appear in either the referenced URL or the > IANA assigned numbers index (https://www.iana.org/protocols). The > title of the entire web page is "Structure of Management Information > (SMI) Numbers (MIB Module Registrations)"; the title of the section > that is referenced is "Internet-standard MIB - > mib-2.interface.ifTable.ifEntry.ifType.tunnelType", which is a > subsection of the section titled "ifType definitions". There is no > reference to the section from the IANA assigned numbers index. > > Comparing with this passage from section 4.1 > > They must instead be respectively added to the > "tunnelType" sub-registry (under the "ifType definitions" > registry). > > suggests the title "ifType definitions: tunnelType" may be in > informal use. [Med] I went for: s/tunnelType Definitions/ifType definitions: tunnelType > > [END] >
