Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-rfc7752bis-14: (with COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Rob,

Thanks for your helpful suggestions. Putting together your suggestions with
what is currently in the document and was discussed with Lars, we get the
following:

To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be
ordered in ascending order by TLV Type. If there are multiple TLVs of the
same type within a single NLRI, then the TLVs sharing the same type MUST be
first in ascending order based on the length field followed by ascending
order based on the value field. Comparison of the value fields is performed
by treating the entire field as opaque binary data and ordered
lexicographically (i.e., treating each byte of binary data as a symbol to
compare, with the symbols ordered by their numerical value).

Does that work?

Thanks,
Ketan


On Fri, Feb 17, 2023 at 6:37 PM Rob Wilton (rwilton) <[e-mail]>
wrote:

> Hi Ketan,
>
>
>
>
>
>
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* 17 February 2023 12:01
> *To:* Rob Wilton (rwilton) <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: Robert Wilton's No Objection on
> draft-ietf-idr-rfc7752bis-14: (with COMMENT)
>
>
>
> Hi Rob,
>
>
>
> Indeed, this is the equivalent of memcmp. Don't both memcmp and strcmp
> follow lexicographical order in comparison?
>
> *[Rob Wilton (rwilton)] *
>
> *As per,  *Lexicographic order - Wikipedia
> <https://en.wikipedia.org/wiki/Lexicographic_order>, *if you want
> lexicographical ordering then I think that you should define what the
> symbols are (if they are not characters), and what the ordering of these
> symbols are.*
>
>
>
>
>
> The difference is about strcmp terminating on '\0' while memcmp doesn't?
>
> *[Rob Wilton (rwilton)] *
>
> *That’s not my main objection to the text.  In the case of string
> comparison, the symbols being compared are characters (since a string is a
> sequence of characters).  In the case of binary, I think that the symbols
> being compared needs to be clarified.*
>
>
>
>
>
>
>
> I am open to any suggestions to better clarify this in the spec.
>
>
>
> *[Rob Wilton (rwilton)]*
>
> *Perhaps something along the lines of:*
>
>
>
>
> *Comparison of the value fields is performed by treating the entire field
> as opaque binary data, ordered lexicographically (i.e., treating each byte*
>
> *of binary data as a symbol to compare, with the symbols ordered by their*
>
> *numerical value).  If two value fields compare identically up to the
> length*
>
> *of the shorter value field, then the shorter length value field is
> ordered*
>
> *before the longer length value field.*
>
>
>
> Regards,
>
> Rob
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
> On Fri, Feb 17, 2023 at 5:17 PM Rob Wilton (rwilton) <[e-mail]>
> wrote:
>
> Hi Ketan,
>
>
>
> It is unclear to me what you mean by “treating the entire field as opaque
> binary data and ordered lexicographically”.  I.e., I think that it is
> poorly defined and potentially risks different implementations interpreting
> this in different ways.
>
>
>
> My guess is that the ordering that you are intending here is equivalent to
> what memcmp() would give you, but I wouldn’t interpret that as a
> lexicographical ordering.
>
> Regards,
>
> Rob
>
>
>
>
>
> *From:* Ketan Talaulikar <[e-mail]>
> *Sent:* 17 February 2023 11:23
> *To:* Rob Wilton (rwilton) <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: Robert Wilton's No Objection on
> draft-ietf-idr-rfc7752bis-14: (with COMMENT)
>
>
>
> Hi Rob,
>
>
>
> My apologies for the delay in responding back to this one. Thanks for your
> review and comments.
>
>
>
> Please check inline below for responses.
>
>
>
> On Thu, Dec 15, 2022 at 6:32 PM Robert Wilton via Datatracker <
> [e-mail]> wrote:
>
> Robert Wilton has entered the following ballot position for
> draft-ietf-idr-rfc7752bis-14: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-idr-rfc7752bis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Thanks for this update to RFC 7752.  I've been short of time this week, and
> hence I'm somewhat relying on the responsible AD and OPSDIR review (thanks
> Gyan!).
>
> I did have a couple of minor comments:
>
> On:
>    To compare NLRIs with unknown TLVs, all TLVs within the NLRI MUST be
>    ordered in ascending order by TLV Type.  If there are multiple TLVs
>    of the same type within a single NLRI, then the TLVs sharing the same
>    type MUST be in ascending order based on the value field.  Comparison
>    of the value fields is performed by treating the entire field as
>    opaque binary data and ordered lexicographically.
>
> I'm not convinced that lexicographical comparison of binary data is that
> well-defined, since it is generally applied to strings, so I this could
> potentially be stated more clearly.
>
>
>
> KT> Not sure if it is limited to strings as in printable characters. This
> text was arrived at during the Shepherd review with Jeff Haas. Refer
> https://mailarchive.ietf.org/arch/msg/idr/4kGNJJsNIYNpOwgU7Rx2r0ZvrsI/
>
>
>
>
> It also wasn't obvious to me why BGP-LS Attribute TLVs SHOULD be ordered,
> but
> are allowed to be unordered.  I.e., if sending them unordered doesn't
> break
> interop then is it really a 'should' rather than a 'SHOULD'?
>
>
>
> KT> As part of this bis work, we came to know of implementations that
> enforced the ordering of TLVs that was meant only for the NLRI also for the
> BGP-LS attribute. If unordered, the update was declared malformed. Hence
> the recommendation to do the ordering - it also has other benefits from an
> operational/ease of use. The MUST NOT was to ensure that we address those
> interop issues with early implementations.
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
> Regards,
> Rob
>
>