Re: [Lsr] When is an IANA Registry Required

Loa Andersson <loa@pi.nu> Tue, 23 March 2021 05:28 UTC

Return-Path: <loa@pi.nu>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA823A1E33; Mon, 22 Mar 2021 22:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tiVq2JaRIqv; Mon, 22 Mar 2021 22:28:08 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A45E3A1E31; Mon, 22 Mar 2021 22:28:08 -0700 (PDT)
Received: from [192.168.1.11] (unknown [124.104.184.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6769832A725; Tue, 23 Mar 2021 06:28:02 +0100 (CET)
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Les Ginsberg (ginsberg)'" <ginsberg=40cisco.com@dmarc.ietf.org>, '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
References: <BY5PR11MB433721C068856ECE2AE4EC5DC19C9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESsyrUTPgkjEPy13W6DRv6ofbW9o_=H9C5bZD3cinGYDD_w@mail.gmail.com> <BY5PR11MB4337AB9127DCEBDC780B52F0C16B9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESsw3vLJudFJ0VMJ-OJBAtQ6w0=_=zn4pGsyVsmyqFWcG5Q@mail.gmail.com> <BY5PR11MB4337CD595C0E577039A1A110C16A9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESszo-LkSLAj+x-JOAb+6J8WWNufPVQ4xJHnC8389KPgMXA@mail.gmail.com> <DACD9B38-106D-49CD-B868-5AED579F63EE@tony.li> <BY5PR11MB4337C479A81A6DC4259D9D8AC16A9@BY5PR11MB4337.namprd11.prod.outlook.com> <94E74912-C3C8-4F6C-BE4D-9F1ADA5D6D5F@tony.li> <BY5PR11MB433783F0EC86C03927CA2EC9C1699@BY5PR11MB4337.namprd11.prod.outlook.com> <A1A50CAE-2D36-45AC-B7C7-F8A23B8DAB36@tony.li> <BY5PR11MB43372085328960699E4EFE05C1659@BY5PR11MB4337.namprd11.prod.outlook.com> <009401d71f8a$ddc14de0$9943e9a0$@tsinghua.org.cn>
From: Loa Andersson <loa@pi.nu>
Message-ID: <65af4b8d-26be-b03e-dc27-7d24a2ebb0db@pi.nu>
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$@tsinghua.org.cn>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/oCF33HUhnCFPl91XCcQz8b80GV0>
Subject: Re: [Lsr] When is an IANA Registry Required
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 05:28:15 -0000

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>rg>; Alvaro Retana 
> <aretana.ietf@gmail.com>om>; lsr-chairs@ietf.org; 
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; John Scudder 
> <jgs@juniper.net>et>; 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