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

[Ketan Talaulikar <[e-mail]>]

Hi Rob,

The update with the changes as discussed below has been posted:
https://datatracker.ietf.org/doc/html/draft-ietf-idr-rfc7752bis-16

Thanks,
Ketan


On Fri, Feb 17, 2023 at 7:48 PM Ketan Talaulikar <[e-mail]>
wrote:

> 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
>>
>>