Hi Adam, On 10/11/17, 8:44 PM, "Adam Roach" <[email protected]> wrote:
>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. The YANG types are clustered together based on functional affinity in much the same way as one would group type definitions in a programming language header file. > > uint24 > This type defines a 24-bit unsigned integer. It is used by > target="I-D.ietf-ospf-yang"/>. Will fix. > >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. We’ll look at this and get back to you - a lot of time has already gone into formulating and testing these patterns. > >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. We’ll either change the pattern or the text. Thanks, Acee > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
