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-boun...@ietf.org <lsr-boun...@ietf.org> *On Behalf Of *Les
Ginsberg (ginsberg)
*Sent:* Monday, March 22, 2021 2:37 PM
*To:* Tony Li <tony...@tony.li>
*Cc:* Christian Hopps <cho...@chopps.org>; Alvaro Retana
<aretana.i...@gmail.com>; lsr-cha...@ietf.org;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org; John Scudder
<j...@juniper.net>; 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 <tony1ath...@gmail.com <mailto:tony1ath...@gmail.com>>
*On Behalf Of *Tony Li
*Sent:* Thursday, March 18, 2021 8:24 AM
*To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com
<mailto:ginsb...@cisco.com>>
*Cc:* Alvaro Retana <aretana.i...@gmail.com
<mailto:aretana.i...@gmail.com>>;
draft-ietf-lsr-isis-srv6-extensi...@ietf.org
<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>; lsr@ietf.org
<mailto:lsr@ietf.org>; John Scudder <j...@juniper.net
<mailto:j...@juniper.net>>; Christian Hopps <cho...@chopps.org
<mailto:cho...@chopps.org>>; lsr-cha...@ietf.org
<mailto:lsr-cha...@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: l...@pi.nu
Senior MPLS Expert loa.pi...@gmail.com
Bronze Dragon Consulting phone: +46 739 81 21 64
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
