Common YANG Data Types for the Routing Area
RFC 8294
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Alvaro Retana Yes
Warren Kumari No Objection
(Alia Atlas; former steering group member) Yes
(Benoît Claise; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
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.
(Alissa Cooper; former steering group member) No Objection
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.
(Ben Campbell; former steering group member) No Objection
I agree with Kathleen's comment about calling out or labeling elements likely to have privacy or security implications.
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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.
(Mirja Kühlewind; former steering group member) No Objection
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection