[Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-idr-rfc5575bis-23: Discuss

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-idr-rfc5575bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I don't know if this is a valid discuss point, so happy to be educated that it
is always written this way and I'll remove my discuss ...

I note that in 5 places this document has text that states the equivalent to
"SHOULD be set to 0 on encoding, and MUST be ignored during decoding." (example
given below).

Doesn't this make extending this in future more risky because if new meaning
are given to these bits then there could be senders already transmitting non 0
values which a receiver might then misinterpret?

Hence, I was surprised that the constraints did not also include a MUST on the
encoding side (i.e. be strict in what you send ...), i.e. "MUST be set to 0 on
encoding, and MUST be ignored during decoding."

Example:
   The extended is encoded as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   reserved    |   reserved    |   reserved    |   reserved    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   reserved    | r.|    DSCP   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 6: Traffic Marking Extended Community Encoding

   o  DSCP: new DSCP value for the transiting IP packet.

   o  reserved, r.: SHOULD be set to 0 on encoding, and MUST be ignored
      during decoding.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I also had a few minor comments on this document:

4.1.  Length Encoding

   o  If the NLRI length is smaller than 240 (0xf0 hex) octets, the
      length field can be encoded as a single octet.

   o  Otherwise, it is encoded as an extended-length 2-octet value in
      which the most significant nibble of the first octet is all ones.

This describes the first nibble in binary, and then later it is shown in hex. 
It might be more clear to write ... in which the most significant nibble has
the hex value 0xf.

   In Figure 1 above, values less-than 240 are encoded using two hex
   digits (0xnn).  Values above 239 are encoded using 3 hex digits
   (0xfnnn).  The highest value that can be represented with this
   encoding is 4095.  For example the length value of 239 is encoded as
   0xef (single octet) while 240 is encoded as 0xf0f0 (2-octet).

4.2.  NLRI Value Encoding

   Components MUST follow strict type ordering by increasing numerical
   order.  A given component type may (exactly once) or may not be
   present in the Flow Specification.  If present, it MUST precede any
   component of higher numeric type value.

I wasn't sure, but wondering whether "may (exactly once) or may not be" should
be "MAY (exactly once) be"?

5.1.  Ordering of Flow Specifications

   For all other component types, unless otherwise specified, the
   comparison is performed by comparing the component data as a binary
   string using the memcmp() function as defined by [ISO_IEC_9899].  For
   strings with equal lengths the lowest string (memcmp) has higher
   precedence.  For strings of different lengths, the common prefix is
   compared.  If the common prefix is not equal the string with the
   lowest prefix has higher precedence.  If the common prefix is equal,
   the longest string is considered to have higher precedence than the
   shorter one.

I think that the intended comparison here is clear, but I was wondering whether
this text should flag endian concerns at all.  E.g. if the component data has
been stored in memory and any numeric values have had endian conversion
performed on them then a naive memcmp() could give a different answer.