Telechat Review of draft-ietf-netmod-rfc6991-bis-17
review-ietf-netmod-rfc6991-bis-17-intdir-telechat-fressancourt-2024-12-12-00

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.