[I'm not one of the authors, but I have opinions. :-) ]
> On Jun 2, 2025, at 11:37 AM, Maxence Younsi <[email protected]> > wrote: > What is the use case for the ordering of TLVs by codepoint in BMPv4? I might > have missed it, but I could not find the original discussion in the mail > archive or the recordings/minutes of past meetings regarding this specific > part of the draft. > > I agree that TLVs should have some kind of ordering. You'll obviously prefer > having your Stateless Parsing TLV before the BGP PDU TLV for example. > > I don't think that the ordering should be based on the TLV type value though. > This, in my opinion, might make it a complicated to plan and organize. Later > on, there is probably going to be people that want to define a TLV that comes > before the BGP PDU. We would need to leave some space in the IANA registry > before that codepoint. Maybe someone wants a TLV before the Stateless Parsing > TLV, or in between two currently allocated TLVs, how do we do that? > > Would it be possible to define the relative position of a TLV in the same > document that defines the TLV? Something like "This TLV SHOULD be placed > before TLV X" or "after TLV Y". While this desire is quite reasonable, a receiving implementation MUST be able to deal with receiving things in arbitrary order. Even messier when TLVs may permit code points to repeat. Attempting to put in rules about abstract ordering will eventually lead to conflicting RFC spaghetti. That said, the code point space is wide enough that gaps can be left in the assignments. With such gaps, there's a level of room for "SHOULD be sorted" and the assignments accomplish the same goal. -- Jeff _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
