Re: [GROW] draft-ietf-grow-bmp-local-rib terminology edits

[Paolo Lucente <[e-mail]>]

Hi Jeff,

Thank you for your feedback. Inline my comments:

> On 18 Jul 2019, at 14:55, Jeffrey Haas <[e-mail]> wrote:
> 
> Thanks for addressing my comments.  One final reply on this thread:
> 
> On Thu, Jul 11, 2019 at 12:30:53PM +0000, Paolo Lucente wrote:
>> Done. This opened a further consideration at my end. The document lacks a
>> statement as in https://tools.ietf.org/html/draft-lucente-bmp-tlv-00 about
>> “TLVs can be sent in any order.
> 
> 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.

Suggestion accepted, thank you, i will include it in the next edit. 

>> 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.”. In the specific case of VRF/Table Name one could have both a
>> VRF id/name and a Table Name, hence the same TLV could be repeated twice
>> (my take is that it’s a perfectly valid scenario). I’d tackle this case
>> once i get green light from you that we are good about how your feedback
>> was processed.
> 
> I suspect most vendors will eventually generate a composite name and send a
> single TLV for the name.
> 
> It would not shock me at some point if this becomes sufficiently vendor
> specific that we start seeing vendor specific TLVs here.

Totally, i agree on your both points. My line of thought was: there are two main approaches for using the standard VRF/Table Name TLV: stacking values in a single TLV (what you mention) and breaking values in multiple TLVs. The former method is a given; i was simply thinking why not allowing also for the latter: while it increases flexibility “it does not seem to produce any harm” (tm).

Paolo