Common YANG Data Types for the Routing Area
draft-ietf-rtgwg-routing-types-17

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.

This is a small thing, but in general I think it would be preferable not to embed the name "iana" in identifiers that can be consumed programmatically (the namespace URN and module name). What distinguishes the iana-routing-types module seems to be that the types define values for address family identifiers, not the fact that the registries containing those identifiers happen to be administered by IANA. If somebody else administered those registries it would have no effect on the contents of the module.

I agree with Kathleen's comment about calling out or labeling elements likely to have privacy or security implications.

It would be good to call out the elements that are identifiers in the security considerations section as the ones that might have an impact on security and privacy.  The text in 7950 is good, but just adding something to list the identifiers or state that identifiers may be of concern would be an improvement.  Thanks.