Thanks for your review, comments inline. On Thu, Dec 12, 2024 at 08:03:51AM -0800, Antoine Fressancourt via Datatracker wrote: > > 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. Base types etc. are defined as part of the YANG language, see the references to RFC 7950. > * 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. This was done to fit the table into the traditional character per line limit for the textual RFC format... > * 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? A date-no-zone value is not representing a specific 24 hour period as the time zone offset is unknown and hence this is closer to a 48 hour period. > * 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. I am not sure about adding a reference for the sake of having a reference. I think RFC 4001 is not a suitable reference for IPv4 addresses (the definition of InetAddressIPv4 in there also has no reference, so we just point somewhere else that is not more useful than what this document has). /js -- Jürgen Schönwälder Constructor University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
