Re: [Lsr] When is an IANA Registry Required

[Loa Andersson <[e-mail]>]

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:*[e-mail] <[e-mail]> *On Behalf Of *Les 
> Ginsberg (ginsberg)
> *Sent:* Monday, March 22, 2021 2:37 PM
> *To:* Tony Li <[e-mail]>
> *Cc:* Christian Hopps <[e-mail]>; Alvaro Retana 
> <[e-mail]>; [e-mail]; 
> [e-mail]; John Scudder 
> <[e-mail]>; [e-mail]
> *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 <[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
> 
> 
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
> 

-- 

Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]