< adding the WG alias and our AD > Hi Paul,
Thanks for the discussion. I will summarize the two points as follows: 1) Should the reference to [IEEE802.1AX] be informative? It is currently normative. The context is covered in draft-kucherawy-bcp97bis-02. We will wait for guidance from our AD/IESG on this. 2) There is a proposal to take a "half-step" to build guard rails at the point of IANA allocations so future documents that introduce new sub-TLVs, that they cover the applicability of those new sub-TLVs to the L2 Bundle Member sub-TLV. Following is a draft proposed text (feel free to suggest alternative) to be added to the IANA considerations of this document. I am not aware of any such precedent and so would like to seek feedback from the WG and our chairs/AD if this is something that we should do. <NEW> This document updates the guidance to IANA for further allocations from the "OSPFv2 Extended Link TLV Sub-TLVs" [1] and the "OSPFv3 Extended LSA Sub-TLVs" [2] registries and requests the addition of this document as a reference to those registries. It requires that any document requesting allocation of code point from these two registries need to indicate the applicability of the introduced sub-TLV to the L2 Bundle Member TLV in that document. [1] https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-tlv-sub-tlvs [2] https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-sub-tlvs </NEW> Thanks, Ketan On Wed, Sep 21, 2022 at 8:16 PM Paul Kyzivat <[email protected]> wrote: > Ketan, > > I've trimmed the conversation down to just the relevant points. > > On 9/21/22 10:07 AM, Ketan Talaulikar wrote: > > > KT> This ID-nits warning is perhaps simply because the normative > > reference is not from an IETF publication and so perhaps the tool is not > > able to determine if that publication is "standards" or informational. > > As far as the guidance from draft-kucherawy, I'll wait for our AD and > > IESG to share their views - we'll do as indicated by the IESG. > > OK > > > KT> If I understand your point, and I am paraphrasing, the idea is that > > we add this document as reference on the OSPFv2/v3 code point registry > > and in this document's IANA section we add guidelines for IANA to look > > for whether the allocation request has specified the applicability to > > the L2 Bundle Member Sub-TLV. So that acts as a checkpoint before future > > allocations out of this registry. Is that correct? > > Yes > > > So this is half-step > > between the current state of the document and the suggested new document > > that changes the registry organization. > > I guess. If this hypothetical new document straightens things out > better, then this would simply cover anything that happens until that > new document is adopted, or in case that never happens. > > Alternately, you could hold this document until that other one is ready. > > > One last thought: have you considered whether potential future > updates > > to the definitions to currently defined sub-TLVs could ever change > > their > > applicability? > > > > > > KT> That would be very remote/unlikely IMO. > > > > I suspect any time a change is made to the registry that > > adds/replaces a reference to a document defining a sub-TLV, the newly > > referenced document will need to "indicate applicability". > > > > KT> Sure and this should be taken care of by the IANA checks when the > > new document reference is updated in registry. > > Yes. > > Thanks, > Paul >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
