> On Mar 22, 2021, at 2:37 AM, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > Tony – > > I hope I can be forgiven for one more post on this subject. In any case, here > it is. > > First, at the risk of some repetition, I want to emphasize that the reason I > started this thread was to define a consistent policy. Currently we do not > have registries for the flags fields in various TLVs. In recent document > reviews, Alvaro strongly suggested that we introduce a registry for the flag > field in the new TLV(s) which were being defined. I do not think the policy > should be inconsistent in this regard, so I started this thread to get the WG > to agree on what the policy will be across all such fields in all TLVs. > Whatever the outcome of this discussion (i.e., to have such registries or to > NOT have them), so long as there is a consistent policy, this thread will > have served the purpose and I will be satisfied. (For those of you who may be > fans of Ralph Waldo Emerson, I consider this to be NOT a “foolish > consistency”. 😊 ) > > Now, as regards the potential usefulness of such registries, I think this has > nothing to do with “memory”. I can assure you that I refer to the existing > registries with great frequency and do not trust my memory on such things. > > Registries exist today (and are very useful) for number spaces for which > requests come from a large number of largely unrelated documents. So, for top > level TLVs, almost every IS-IS related RFC which has been published defines > one or more codepoints. Without a registry our ability to track what is > currently allocated and what is available would be severely compromised. > Similarly for sub-TLVs and the other registries under the TLV Codepoints > umbrella. However, in regards to flags fields which are part of the fixed > portion of a TLV format definition, tracking bit allocation has not been an > issue – and I argue that it is best tracked in other ways which are already > defined. To be specific: > > If an additional flag bit for an existing TLV is defined in the future, > there are two possible ways of doing this: > > 1)A bis document is written. The new document then contains all normative > content from the original document as well as the new content (in this > example an additional flag bit). The new document is required to be marked as > “obsoleting” the original version. Once the document is published, the > original document is marked as “obsoleted by xxx” and the existing entry for > the affected code point in > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml > > <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> > is marked to point to the new document. > > 2)A separate document is written focused only on the additions to the base > definition for the TLV. The new document is required to be clearly marked as > “updating” the original document. The original document is marked as “updated > by new document”. In addition, the existing entry in > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml > > <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> > would be updated to point to both the original document and the new document.
As WG member, I have approached this generally in the following way. If the flags field seems to be of the type (1) no IANA registry should be required. If the flags field seems to be of the type (2) then one could allocate a registry or leave it to the updating document to do so. The more one expects that a type (2) document is likely to be written, the more one should really consider creating the registry up-front in the field defining document. IOW I don't think one should have to follow a tree of "updates" links hunting down *possible* new flag definitions, but following an "obsoleted by" chain to the latest version of a document is expected, and in this case the registry content would always point at a single document so would not be of any real value. Thanks, Chris. > This seems to me be fully functional and easy to use. Even if your memory on > such matters is not fresh, by simply bookmarking > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml > > <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> > you will easily be able to find whatever information you need. > > The addition of a separate registry for each flags field is then redundant at > best. And redundancy in such matters introduces additional work and the > possibility of unintentional inconsistency which I find hard to justify. > Hence my conclusion that the value of such additional registries does not > justify their creation. > > You (and others) may still disagree. And I assure you that as my primary > motivation for this thread was to have a consistent WG policy for such > fields, I will abide by whatever policy is chosen by the WG even if it is not > my preferred choice. But I do think the arguments being made for the creation > of such registries bear closer scrutiny. Just my opinion of course… > > Thanx (again) for listening. > > Les > > > From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li > Sent: Thursday, March 18, 2021 8:24 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Alvaro Retana <aretana.i...@gmail.com>; > draft-ietf-lsr-isis-srv6-extensi...@ietf.org; lsr@ietf.org; John Scudder > <j...@juniper.net>; Christian Hopps <cho...@chopps.org>; lsr-cha...@ietf.org > Subject: Re: [Lsr] When is an IANA Registry Required > > > Les, > > > > 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. > > > With all due respect Les, you appear to operate with an eidetic memory of all > things IS-IS, so I think that you discount the confusion that the rest of us > live in. > > If a field has values defined in two documents, then there’s confusion. Even > just finding both is a challenge. > > Regards, > Tony > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org <mailto:Lsr@ietf.org> > https://www.ietf.org/mailman/listinfo/lsr > <https://www.ietf.org/mailman/listinfo/lsr>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
