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

["Acee Lindem (acee)" <[e-mail]>]

Hi Adam, 

On 10/11/17, 8:44 PM, "Adam Roach" <[e-mail]> 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 
>
>