Reviewer: Antoine Fressancourt Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-netmod-rfc6991-bis-17.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>. Based on my review, if I was on the IESG I would ballot this document as YES. Overall, the document is clear and detailed. The following are minor issues (typos, misspelling, minor text improvements) with the document. Note that I would describe myself as a total beginner / non-expert with regards to YANG, so my comments should be interpreted with this in mind: * After being puzzled by the lack of definition of the "union" base type, I realized that the document assumes a description of some base types such as uint32, uint64, string or union, without indicating clearly a reference document where these types are presented and defined (or at least I didn't get this reference from reading the document). I wonder whether it would be possible to state (maybe in Section 2?) where those "basic" base types are defined. * In table 3, I would give the module associated with the SMIv2 type in a separate column rather than in parenthesis after the SMIv2 type name. * In the "date-no-zone" typedef, it was not clear for me from the text in the description how an entity receiving a YANG document with this date type should interpret it: should he use its local time zone, or a reference (say, UTC) time zone? * Some type definitions have no reference. While I understand this reference might be optional, for some type definitions, I think this lack of reference is problematic, for instance for the following types: * date-no-zone * type-no-zone * ipv4-address * ipv4-address-no-zone * ipv4-prefix * ipv4-address-and-prefix For the ipv4-related type, I would just reference RFC 4001, as it is already referenced in the document. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
