Common YANG Data Types for the Routing Area

Note: This ballot was opened for revision 15 and is now closed.

(Alia Atlas) Yes

(Benoît Claise) Yes

Alvaro Retana Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2017-10-11 for -16)
No email
send info
I agree with Kathleen's comment about calling out or labeling elements likely to have privacy or security implications.

Alissa Cooper No Objection

Comment (2017-10-12 for -16)
No email
send info
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.

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) No Objection

(Kathleen Moriarty) No Objection

Comment (2017-10-11 for -16)
No email
send info
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.

(Eric Rescorla) No Objection

(Adam Roach) No Objection

Comment (2017-10-11 for -16)
No email
send info
Section 2:

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

      This type defines a 24-bit unsigned integer.  It is used by

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.