Tony Li <tony...@tony.li> writes:
Hi all,On Oct 3, 2022, at 8:37 AM, Christian Hopps <cho...@chopps.org> wrote: [As wg-member] I think the draft should include a table of all top level TLVS as rows and for columns we have - "Implicit Single TLV Only" (e.g., no key info) - "Implicit Multi-TLV Only" - "Explicit Single TLV Only" - "Explicit Multi-TLV-Allowed" This draft then would *explicitly* cover the existing "implicit" cases and we have the table to point at to be precise about what we are talking about.I have completed this effort.
Wow, thanks for doing this! This is very interesting and useful data. If I am reading it correctly, we have no(*) published TLVs which might implicitly use multi-part TLV encoding. And, we have only 3 that are not yet published in RFCs that fall into this "implicitly multi-part TLV" category. That is great news b/c it means we can fix those 3 unpublished TLV to be explicit multi-part. After fixing those 3 we are in a much friendly place of defining only future behavior/standard requirements without concern of impacting current deployments. Thanks again! Chris. (*) TRILL TLV has been published, but that is an entirely different protocol.
Rather than burden the draft with this, I have created a spreadsheet and am sharing a link to the sheet: https://docs.google.com/spreadsheets/d/1VWQHsJTq7JRUVdRVcRd_QYYyY_LiOX7H0ZKn8feRZo4/edit?usp=sharing There are numerous proprietary TLVs that I cannot evaluate. I have ignored them. I am human. I expect that I will have missed several things. If you have a correction, please unicast me. Regards, Tony
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
