Hi Ben,

Thank you for your review, very much appreciated. I will merge your PR on GitHub asap. With regards to the other two points:

1) This came through a suggestion back then from Jeff Haas that i support as it made sense to me, see here his comment on this list:

==
While a bit pedantic, I strongly suggest "TLVs SHOULD be sorted by their
code point.".

Many implementations that deal with TLV based protocols will canonicalize data structures based on the TLVs using sorted structures. Having them sorted on the wire means the canonicalization step is cheaper.

Note that this is a general justification for the procedure and it's not
critical for something like BMP.
==

2) That is right & suggestion accapted. I will make it further explicit.

Paolo


On 8/12/21 09:40, Ben Maddison wrote:
Hi all,

On 12/02, Job Snijders wrote:
Hi Folks,

Please take 15 minutes out of your day to review this *really short!*
internet-draft. The authors were kind enough to make it only 3 pages of
actual content :-)

I have read the draft, and agree with others that it is a straight
forward solution to a genuine problem.

I have a couple of questions/comments:

1.  I don't understand the purpose of the SHOULD in:
TLVs SHOULD be sorted by their code point. Multiple TLVs of the
         same type can be repeated as part of the same message, and it is
         left to the specific use-cases whether all, any, the first or
         the last TLV should be considered.

     A receiver clearly cannot optimise for receiving the TLVs sorted,
     since it isn't a MUST. Beyond this, why is it useful?

2.  In the types defined in section 4.2, I read "value MUST be boolean"
     as meaning "length MUST be 1 and value MUST be either 0x00 or 0x01".

     Is that correct? If so, perhaps it is better to be explicit?

3.  I had a variety of grammatical/editorial suggestions. Rather than
     gum-up the list with these, I have opened a pull-request at:
     https://github.com/paololucente/draft-ietf-grow-bmp-tlv/pull/2

     I hope that makes review more convenient for the authors.

Cheers,

Ben


_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow


_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow

Reply via email to