Last Call Review of draft-ietf-netmod-rfc6991-bis-16
review-ietf-netmod-rfc6991-bis-16-yangdoctors-lc-bjorklund-2024-09-03-00

Request Review of draft-ietf-netmod-rfc6991-bis-16
Requested revision 16 (document currently at 18)
Type IETF Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2024-09-13
Requested 2024-08-27
Requested by Mahesh Jethanandani
Authors Jürgen Schönwälder
I-D last updated 2025-12-22 (Latest revision 2025-06-23)
Completed reviews Yangdoctors IETF Last Call review of -16 by Martin Björklund (diff)
Opsdir IETF Last Call review of -16 by Giuseppe Fioccola (diff)
Secdir IETF Last Call review of -16 by Rifaat Shekh-Yusef (diff)
Dnsdir IETF Last Call review of -16 by Florian Obser (diff)
Genart IETF Last Call review of -16 by Russ Housley (diff)
Artart IETF Last Call review of -16 by Bron Gondwana (diff)
Dnsdir Telechat review of -17 by Florian Obser (diff)
Artart Telechat review of -17 by Bron Gondwana (diff)
Intdir Telechat review of -17 by Antoine Fressancourt (diff)
Comments 
While the request for YANG Doctors is obvious, the other directorate reviews are more to make sure there is nothing that the WG might have overlooked. In particular, there was quite a bit of discussion around date/time and zone offset, that could use another pair of eyes.
Assignment Reviewer Martin Björklund
State Completed
Request IETF Last Call review on draft-ietf-netmod-rfc6991-bis by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/Z5aMiDX_n52gTbrU1EDTKd1JKRA
Reviewed revision 16 (document currently at 18)
Result Ready w/nits
Completed 2024-09-03
review-ietf-netmod-rfc6991-bis-16-yangdoctors-lc-bjorklund-2024-09-03-00
Here is my YANG doctor's review of draft-ietf-netmod-rfc6991-bis-16.  


o  typedef email-address

  The domain part of "email-address" is different from the type
  "domain-name".  This looks a bit odd.  If special characters can
  occur in the domain part of an email address, one would assume that
  they can occur in a domain name as well.


o  typedef protocol-number

     "The protocol-number type represents an 8-bit Internet
      protocol number, carried in the 'protocol' field of the
      IPv4 header or in the 'next header' field of the IPv6
      header. If IPv6 extension headers are present, then the
      protocol number type represents the upper layer protocol
      number, i.e., the number of the last next header' field
                                         ^^^ ' missing
      of the IPv6 extension headers.


o  typedef ipv6-address-and-prefix

     "The ipv6-address-and-prefix type represents an IPv6
      address and an associated ipv4 prefix.

   s/ipv4 prefix/IPv6 prefix/


o  typedef ipv4-address-and-prefix

     "The ipv4-address-and-prefix type represents an IPv4
      address and an associated ipv4 prefix.

   s/ipv4 prefix/IPv4 prefix/


o  "schema node instance"

  This term is used in a few places in ietf-yang-types, for example:

      A schema node instance of this type will be set to zero (0)
      on creation

  This isn't correct, since a schema node is a node in the schema
  tree, and doesn't have a value.  With RFC 7950 terminology, it would
  be "a node in the data tree".  It is unfortunate that there is no
  specific term for this in RFC 7950.

  Perhaps it would be easier to just write "An instance of this
  type...".

  (I know that this was not correct RFC 6991 either)


/martin