[prev in list] [next in list] [prev in thread] [next in thread]
List: ms-ospf
Subject: Re: [Lsr] When is an IANA Registry Required
From: Loa Andersson <loa () pi ! nu>
Date: 2021-03-23 5:27:57
Message-ID: 65af4b8d-26be-b03e-dc27-7d24a2ebb0db () pi ! nu
[Download RAW message or body]
Toni, Ajun, et.al.,
I think that what Ajun says is that a IANA registry is often (very)
practical long before it is "required".
I'm a bit concerned that by stating a requirement, we might in practice
raise the bar for then a registry is created. People read the
requirement and says that ""Nay, it is not really need, so I won't
create a new registry", and then a few years down the line we find that
a registry would have been helpful.
So I'd say that as soon as you see that there might be more code points
registered from the namespace you are creating, create a registry.
/Loa
On 23/03/2021 10:18, Aijun Wang wrote:
> Hi, Les:
>
> Even for IS-IS, there is already the flag registries example, please see
> the following pointer:
>
> https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags>
>
> And, even for your proposal 2), it is still not concise as the flag
> registries. Considering that we have one flag filed that has 16bit, and
> there will be 16 updates to the original document if it defines no bit
> at the beginning and every additional document defines one bit only?
>
> Best Regards
>
> Aijun Wang
>
> China Telecom
>
> *From:*lsr-bounces@ietf.org <lsr-bounces@ietf.org> *On Behalf Of *Les
> Ginsberg (ginsberg)
> *Sent:* Monday, March 22, 2021 2:37 PM
> *To:* Tony Li <tony.li@tony.li>
> *Cc:* Christian Hopps <chopps@chopps.org>; Alvaro Retana
> <aretana.ietf@gmail.com>; lsr-chairs@ietf.org;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; John Scudder
> <jgs@juniper.net>; lsr@ietf.org
> *Subject:* Re: [Lsr] When is an IANA Registry Required
>
> 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.
>
> 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 <tony1athome@gmail.com <mailto:tony1athome@gmail.com>>
> *On Behalf Of *Tony Li
> *Sent:* Thursday, March 18, 2021 8:24 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com
> <mailto:ginsberg@cisco.com>>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com
> <mailto:aretana.ietf@gmail.com>>;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org
> <mailto:draft-ietf-lsr-isis-srv6-extensions@ietf.org>; lsr@ietf.org
> <mailto:lsr@ietf.org>; John Scudder <jgs@juniper.net
> <mailto:jgs@juniper.net>>; Christian Hopps <chopps@chopps.org
> <mailto:chopps@chopps.org>>; lsr-chairs@ietf.org
> <mailto:lsr-chairs@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
> https://www.ietf.org/mailman/listinfo/lsr
>
--
Loa Andersson email: loa@pi.nu
Senior MPLS Expert loa.pi.nu@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic