Les >From an operators perspective my take is what is important to be registered as is what is required today for any protocol specification with IANA is the TLV and Sub TLV codepoints that are allocated by the protocol specification being designed. That is all that is requirement for any new specification.
The bit allocation for flags I think is unnecessary to be registered with IANA. Those flag details defined in the RFC protocol specification is what is implemented by the vendors. I think going down the road of registering flags bits with IANA would be a complex task and I think more room for error as two many moving parts that need to be synced and updated and could lead to discrepancies which is far worse. We just need the truth of the protocol specification which is what the implementation follows and that is based on the RFC standard protocol specification and IANA codepoints allocated for the design. https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml I believe we can proceed as we have been doing for the last 20+ years. No harm no foul. Kind Regards Gyan On Wed, Mar 17, 2021 at 8:26 PM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > Tony – > > > > IMO, there is no need for registries for the first category. The WG has > been alive for over 20 years, defined many new TLVs with flags fields, and > I am not aware of any confusion – so if it ain’t broke don’t fix it. > > > > But, if the WG consensus turns out to be to create registries in such > cases, so be it – though it raises the question of what to do about > existing flags fields which don’t have a registry (all of them currently). > But I guess your “registry-on-write” policy could be used to address that - > meaning no need to backtrack – just create registries when any new flag > definitions come along. > > > > I will leave it to the WG chairs as to how to determine WG consensus. Just > hope we don’t have to write an RFC to define the WG policy on this. 😊 > > > > Thanx. > > > > Les > > > > > > *From:* Tony Li <[email protected]> *On Behalf Of *Tony Li > *Sent:* Wednesday, March 17, 2021 1:56 PM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* Alvaro Retana <[email protected]>; > [email protected]; [email protected]; John Scudder < > [email protected]>; Christian Hopps <[email protected]>; [email protected] > *Subject:* Re: [Lsr] When is an IANA Registry Required > > > > > > Les, > > > > > > [Les:] The question here is whether there is a qualitative difference > between two classes of bit fields. > > > > > > That is indeed the key question. IMHO, there is not. > > > > I don’t much care if a field is updated by a bis document or a related > document. Regardless of the cause, as soon as there is more than one source > of truth about the field, we are > > creating ambiguity and confusion. > > > > At the same time, I see no point in a registry with contents that never > change. Thus, I will propose an alternative: by analogy to copy-on-write > shared memory semantics, I propose that > > we apply ‘registry-on-write’ semantics. > > > > Specifics: When a potentially shared field is created, the defining > document speciifies the name of a future registry, but does NOT request > IANA create the registry at this time. When any document wishes > > to update the field, it requests that IANA create it and populate it with > both legacy and updated values. > > > > Implementors that come along either document know where the source of > truth is. If the registry has not been created, then there is no > ambiguity. If it has been, then there is no ambiguity. > > > > Thoughts? > > > > Tony > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
