Dale, thanks for your review. Med, thanks for your response. I entered a No Objection ballot. Alissa > On May 6, 2019, at 3:49 AM, mohamed.boucadair@xxxxxxxxxx wrote: > > 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] >> > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
