Speaking as WG Member and primary author of RFC 8362: Hi John,
On 9/6/22, 1:17 PM, "John Scudder" <[email protected]> wrote: Hi Acee, > On Sep 5, 2022, at 1:23 PM, Acee Lindem (acee) <[email protected]> wrote: > > First of all, I think this IANA OSPFv3 Extended-LSA Sub-TLV specification, if it is to be done at all, should be done in a separate draft. I guess by “specification” you mean “registry reorganization”, right? I’m OK with that, though I think I will wait a little longer to see if other WG contributors want to weigh in. [ACEE] Actually, it is much more than "reorganization" as it is adding lots of additional information, i.e., additional "specification". > When we originally created the registry for RFC 8362, the purpose was avoid Sub-TLV code point collisions while affording maximum reuse of Sub-TLV definitions. It was NOT to avoid reading the specifications in order to determine everywhere a Sub-TLV is allowed. I agree that reading all the RFCs is (or should be) sufficient. My thoughts are as I mentioned in my earlier reply to Ketan — organizing the registry to reflect the restrictions imposed by the RFCs serves two possibly-useful purposes. First, it gathers the information in one place for quick reference. Second and more important, it reduces the chance that the author of a future spec might overlook the need to carefully specify where their sub-TLV can and can’t be used. [ACEE] There are a lot of IETF work items that would provide value. However, there is only a limited amount of resource and time to complete them. This draft has already gone through working group last call and I think this additional IANA specification would require more work and reviews than the original draft. > In fact, I don’t believe IS-IS had yet adopted this IANA practice when this became a WG document in 2007. OSPFv3 Extended LSAs took some time to standardize as we held it until there were implementations and there weren’t implementations until Segment Routing offered a strong incentive. > > If this information is to be represented in the IANA registry, I’d stay away from columns with Y’s and N’s. Note that Sub-TLVs can nested so conceivably a given Sub-TLV could be used by other Sub-TLVs. Are there existing restrictions on the use of one sub-TLV within other sub-TLVs that would need to be captured, or are you just mentioning that for completeness? (Completeness is good of course.) If the latter, maybe one option could be a catch-all column, called something like “other restrictions on use” that can list other restrictions either in line or in a footnote with sub-bullets as you suggest. [ACEE] I don't believe there are any nested Sub-TLVs today but we certainly don't want the IANA specification/organization to make adding them unwieldy. > Rather, one could list the Sub-TLVs with the individual usages and references (if different from the creation reference) as sub-bullets. I can’t comment because I can’t quite picture what you’re describing, and how the registry would look? [ACEE] As it does today except with indented lines as to the usage of the Sub-TLVs. The exact formatting would be for the new draft. I guess if we do decide to either abandon the reorganization suggestion altogether, or to pursue it as a separate draft, then draft-ietf-lsr-ospf-l2bundles should just stick to its existing approach of listing restrictions in their own subsections of the main spec, do you agree? Recall that we got here (in part) because it seemed strange to me to update the registry to list some restrictions, but not all of them. [ACEE] This would be my choice except I wouldn't add the "L2 Member Bundle Attributes" restriction to the IANA registry unless we do it for all the Sub-TLVs as you suggest. Thanks, Acee Thanks, —John _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
