Re: [Lsr] When is an IANA Registry Required

[[e-mail]]

+1
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.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:[e-mail]]
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) <[e-mail]>; Tony Li <[e-mail]>
Cc: Alvaro Retana <[e-mail]>; [e-mail]; [e-mail]; John Scudder <[e-mail]>; Christian Hopps <[e-mail]>; [e-mail]
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 https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
Thanks,
Acee

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

   Les

From: Tony Li <[e-mail]<mailto:[e-mail]>> On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>
Cc: Alvaro Retana <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; John Scudder <[e-mail]<mailto:[e-mail]>>; Christian Hopps <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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



_________________________________________________________________________________________________________________________

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.