Re: [Lsr] When is an IANA Registry Required

Loa Andersson <> Tue, 23 March 2021 05:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CA823A1E33; Mon, 22 Mar 2021 22:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4tiVq2JaRIqv; Mon, 22 Mar 2021 22:28:08 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A45E3A1E31; Mon, 22 Mar 2021 22:28:08 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 6769832A725; Tue, 23 Mar 2021 06:28:02 +0100 (CET)
To: Aijun Wang <>, "'Les Ginsberg (ginsberg)'" <>, 'Tony Li' <>
Cc: 'Christian Hopps' <>, 'Alvaro Retana' <>,,, 'John Scudder' <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <009401d71f8a$ddc14de0$9943e9a0$>
From: Loa Andersson <>
Message-ID: <>
Date: Tue, 23 Mar 2021 13:27:57 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <009401d71f8a$ddc14de0$9943e9a0$>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Lsr] When is an IANA Registry Required
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Mar 2021 05:28:15 -0000

Toni, Ajun,,

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.


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:
> <>
> 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:* <> *On Behalf Of *Les 
> Ginsberg (ginsberg)
> *Sent:* Monday, March 22, 2021 2:37 PM
> *To:* Tony Li <>
> *Cc:* Christian Hopps <>; Alvaro Retana 
> <>;; 
>; John Scudder 
> <>;
> *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 
> <> 
> 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 
> <> 
> 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 
> <> 
> 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 < <>> 
> *On Behalf Of *Tony Li
> *Sent:* Thursday, March 18, 2021 8:24 AM
> *To:* Les Ginsberg (ginsberg) < 
> <>>
> *Cc:* Alvaro Retana < 
> <>>; 
> <>; 
> <>; John Scudder < 
> <>>; Christian Hopps < 
> <>>; 
> <>
> *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


Loa Andersson                        email:
Senior MPLS Expert                
Bronze Dragon Consulting             phone: +46 739 81 21 64