Re: [Lsr] When is an IANA Registry Required Fri, 19 March 2021 09:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC6713A0AD1; Fri, 19 Mar 2021 02:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uhI33FrXfvKA; Fri, 19 Mar 2021 02:51:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C13E43A0ACB; Fri, 19 Mar 2021 02:51:33 -0700 (PDT)
Received: from (unknown [xx.xx.xx.68]) by (ESMTP service) with ESMTP id 4F1zgQ58N7zCrpm; Fri, 19 Mar 2021 10:51:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1616147490; bh=U4QIUOXNvU4C8Rx7gkjxsXXiXZQOifQhSZ36tp/FMsk=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=C9xpKYC3QoNEXCg59Q12alr3dDYRmS6HgTrvQRoZBzxzU5MSO9TbgObHyu6EkWFxX AhRXNODY6cYN7Ne/8GTRLKXgsKRxh64xty9Lfe+2Q7pv4ObjyG/Gv38I4w5OhHTfCp cO4HQko1jhrUvC3jT4T0D3gZaSdC7l4GbobCTChjzM7DX+Tdyz1mv7UCBuvMF7y933 ZAKtxUuZYWAx0hvx3G1wdFDdB2W+DN2rmoiu9uDndU0I/vvbfpz2uF1smSC7xId2lu OMI2RQ3TqNnP6xWaXMGdq8y1zrd2JqJauzVnaE7gy8AsgiGKtDS/famxbmWutf5JNl jzSbce4bF/LGg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by (ESMTP service) with ESMTP id 4F1zgQ4B7pz1xpC; Fri, 19 Mar 2021 10:51:30 +0100 (CET)
To: "Acee Lindem (acee)" <>, Tony Li <>
CC: Alvaro Retana <>, "" <>, "" <>, John Scudder <>, Christian Hopps <>, "" <>, "Les Ginsberg (ginsberg)" <>
Thread-Topic: [Lsr] When is an IANA Registry Required
Date: Fri, 19 Mar 2021 09:51:30 +0000
Message-ID: <21297_1616147490_60547422_21297_80_1_53C29892C857584299CBF5D05346208A4CD1F0E4@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CD1F0E4OPEXCAUBM43corp_"
MIME-Version: 1.0
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: Fri, 19 Mar 2021 09:51:37 -0000

The information needs to be tracked and consolidated. Seems better done by a single person than by many persons duplicating the work, not to mention by zero person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which may already do this work. However:
-IINM, the designated expert is only appointed when there is a registry.
-IMHO there would be value in having the tracking data been public. IANA looks good to me. In theory, github may also work.

That also assumes that code point/flags be tracked -hence allocated- soon enough, rather than been hidden in a draft or specific implementation.


From: Acee Lindem (acee) []
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) <>; Tony Li <>
Cc: Alvaro Retana <>;;; John Scudder <>; Christian Hopps <>;
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for unique IGP protocol bit flag fields. For the existing fields that don’t have registries, there is no burning requirement to go back and define an IANA registry until such time as that flag field is extended.

Note that for OSPF, we did add these registries in (thanks to Kireeti).

From: "Les Ginsberg (ginsberg)" <<>>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li <<>>
Cc: Alvaro Retana <<>>, "<>" <<>>, "<>" <<>>, John Scudder <<>>, Christian Hopps <<>>, "<>" <<>>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: <<>>
Resent-To: Acee Lindem <<>>, Yingzhen Qu <<>>, Christian Hopps <<>>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

In this context I don’t find the use of a registry of value. The primary issue for me for these fields is not managing the bit assignments but understanding the functionality – and for that I need to look at the document(s) which have that definition. A registry in these cases provides little value and adds process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion – nor vice versa. So I appreciate that you have made your POV clear and the reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be made solely based on a single document review comment from one individual – even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG will respond to the thread and then we can proceed appropriately.


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


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.



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.