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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Ketan,

That looks good.

Thanks,
Rob


From: Ketan Talaulikar <[e-mail]>
Sent: 21 February 2023 06:34
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,

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]<mailto:[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]<mailto:[e-mail]>> wrote:
Hi Ketan,



From: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Sent: 17 February 2023 12:01
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Sent: 17 February 2023 11:23
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: The IESG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[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