Adam Roach's No Objection on draft-ietf-rtgwg-routing-types-16: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-rtgwg-routing-types-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-routing-types/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 2:

Are these types in any particular order? If not, you might consider
alphabetizing them to make thing easier to find.

   uint24
      This type defines a 24-bit unsigned integer.  It is used by
      target="I-D.ietf-ospf-yang"/>.

There appears to be some XML damage here.

____

There are several patterns in the YANG definition that perform significant
restriction of numbers (e.g., to ensure they don't fall outside the range that
can be stored in 16 or 32 bits). In many cases, these patterns include the
ability to zero-prefix some (but not all) decimal values. For example, the
production for route-origin would allow leading zeros in "2:0100:0555" but not
in "2:04294967295:065535" (even though "2:4294967295:65535" is okay). I don't
know offhand whether it makes sense to allow leading zeros in these fields, but
I would argue that the production should be consistent in allowing or
disallowing them. This issue arises in various forms in route-target,
ipv6-route-target, route-origin, and ipv6-route-origin.

The definition of bandwidth-ieee-float32 includes the following text:

          The encoding format is the external hexadecimal-significant
          character sequences specified in IEEE 754 and C99. The
          format is restricted to be normalized, non-negative, and
          non-fraction: 0x1.hhhhhhp{+}d or 0X1.HHHHHHP{+}D
          where 'h' and 'H' are hexadecimal digits, 'd' and 'D' are
          integers in the range of [0..127].

Notably, this prose clearly says that values can start with "0x1" and "0X1",
but not "0x0" or "0X0" -- while the pattern production does allow 0x0, and the
examples even include values starting with 0x0. The quoted prose above should
be re-worked so it also allows values starting with 0x0 and 0X0.