Re: [Lsr] When is an IANA Registry Required

Les

>From an operators perspective my take is what is important to be registered
as is what is required today  for any protocol specification with IANA is
the TLV and Sub TLV codepoints that are allocated by the protocol
specification being designed.  That is all that is requirement for any new
 specification.

The bit allocation for flags I think is unnecessary to be registered with
IANA.  Those flag details defined in the RFC protocol specification is what
is implemented by the vendors.   I think going down the road of registering
flags bits with IANA would be a complex task and I think more room for
error as two many moving parts that need to be synced and updated and could
lead to discrepancies which is far worse.

We just need the truth of the protocol specification which is what the
implementation follows and that is based on the RFC standard protocol
specification and IANA codepoints allocated for the design.

https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml

https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml

I believe we can proceed as we have been doing for the last 20+ years.  No
harm no foul.

Kind Regards

Gyan

On Wed, Mar 17, 2021 at 8:26 PM Les Ginsberg (ginsberg) <ginsberg=
40cisco.com@dmarc.ietf.org> wrote:

> Tony –
>
>
>
> 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.
>
>
>
> But, if the WG consensus turns out to be to create registries in such
> cases, so be it – though it raises the question of what to do about
> existing flags fields which don’t have a registry (all of them currently).
> But I guess your “registry-on-write” policy could be used to address that -
> meaning no need to backtrack – just create registries when any new flag
> definitions come along.
>
>
>
> I will leave it to the WG chairs as to how to determine WG consensus. Just
> hope we don’t have to write an RFC to define the WG policy on this. 😊
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
> *From:* Tony Li <tony1athome@gmail.com> *On Behalf Of *Tony Li
> *Sent:* Wednesday, March 17, 2021 1:56 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> *Cc:* Alvaro Retana <aretana.ietf@gmail.com>;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; lsr@ietf.org; John Scudder <
> jgs@juniper.net>; Christian Hopps <chopps@chopps.org>; lsr-chairs@ietf.org
> *Subject:* Re: [Lsr] When is an IANA Registry Required
>
>
>
>
>
> Les,
>
>
>
>
>
> [Les:] The question here is whether there is a qualitative difference
> between two classes of bit fields.
>
>
>
>
>
> That is indeed the key question. IMHO, there is not.
>
>
>
> I don’t much care if a field is updated by a bis document or a related
> document. Regardless of the cause, as soon as there is more than one source
> of truth about the field, we are
>
> creating ambiguity and confusion.
>
>
>
> At the same time, I see no point in a registry with contents that never
> change. Thus, I will propose an alternative: by analogy to copy-on-write
> shared memory semantics, I propose that
>
> we apply ‘registry-on-write’ semantics.
>
>
>
> Specifics: When a potentially shared field is created, the defining
> document speciifies the name of a future registry, but does NOT request
> IANA create the registry at this time. When any document wishes
>
> to update the field, it requests that IANA create it and populate it with
> both legacy and updated values.
>
>
>
> Implementors that come along either document know where the source of
> truth is.  If the registry has not been created, then there is no
> ambiguity. If it has been, then there is no ambiguity.
>
>
>
> Thoughts?
>
>
>
> Tony
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD