[Lsr] When is an IANA Registry Required

["Les Ginsberg (ginsberg)" <[e-mail]>]

Alvaro -



In your review of draft-ietf-lsr-isis-srv6-extensions you requested the authors to



"Please ask IANA to set up a registry for the Flags."



in multiple cases e.g., the flags field defined in the new SRv6 Capabilities sub-TLV.



This isn't the first time you have made such a request (I believe I argued against this in the past and you relented – but only temporarily it seems. 😊 ).

As it is a deviation from historical practice, I think it would be better if the WG discussed whether there is a good reason to change our practices rather than have this request be made based on the personal preference of the current AD.



Historically, we have created IANA registries for identifiers which are likely to be needed by a variety of unrelated features supported by the protocol. The expectation in these cases is that multiple documents - largely unrelated to each other - might need to allocate an ID from the same space.

Obvious examples are TLV/sub-TLV code points.

In the case of flags, there are currently only two such registries:



link-attribute bit values for sub-TLV 19 of TLV 22<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22>



Bit Values for Prefix Attribute Flags Sub-TLV<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags>



In both of these cases the sub-TLVs were defining a general purpose bit field.  It was expected (and it has happened) that unrelated documents had a need to allocate a bit in these fields.



What we have NOT done, historically, is create a registry for a flags field which is not provided as a general purpose mechanism,  but is specifically scoped for use only within the context of the feature which defined the TLV/sub-TLV. (There are many examples.)

It is expected in these cases that if an additional flag is required, that it will be defined in a document directly related to the original feature – either a bis version of the original document or a new document which is marked specifically as an update to the original document.

Management of the flag space in such cases has never required the overhead of a registry.



You seem to want to change that and I would like to know why?

What problem exists that you are trying to solve?



IMO, such a policy is not needed, does not add value, but does add additional overhead to what is already a considerable set of hoops which drafts must navigate on their way to becoming an RFC.

The number of existing TLV/sub-TLVs which have flags fields is significant – and the lack of a registry for these fields has not yet caused any problem.



Appreciate if we could have open discussion on this.



   Les