Hi Jeff, Thank you for your feedback. Inline my comments:
> On 18 Jul 2019, at 14:55, Jeffrey Haas <jh...@pfrc.org> 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 _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
