Re: [Lsr] When is an IANA Registry Required

Gyan Mishra <hayabusagsm@gmail.com> Thu, 18 March 2021 01:11 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAF63A19C4; Wed, 17 Mar 2021 18:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp3Vq91YAZ9d; Wed, 17 Mar 2021 18:11:12 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966D73A19C1; Wed, 17 Mar 2021 18:11:12 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id k4so436247plk.5; Wed, 17 Mar 2021 18:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CNSGNxdCmLnUpT6ZGG9ZIW+b5IZLJ6IEcoGu+/GavqQ=; b=KzH1XU6FlX9RvmmJqbdsKXDLGB00vlJieoZ7IWVw4Z0fisuv59aUTYf7cxeI+EzViL 1HPt/37JcF/JBZFomFxKbnizAxJ7QljI1gtsqi2+gob49uaEOam5vadSURmfhmzsU2yY HBjq7ylWeXH8ZWN9nd61tzEpIwd30137+bhVXy/Z2VSBfGclSUwqKVM7b1UORPLfS/vI pl1LiocqHOeaCRBx2dJAdaqK/FQhEd+pGg4te9kMZ8JGsV+J+cf1a/W9en/3PaeBvMxE VtZplgI+CgIw3ZcI6JI1X+Xf/OB9jFl14phPzXy/ZsYS6ckqblBqLOj9VLdPHtJdH1QV yZOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CNSGNxdCmLnUpT6ZGG9ZIW+b5IZLJ6IEcoGu+/GavqQ=; b=lJ30EsbdaUUwxFecD2wxxxd8Mrbueh5FXl46r+91oY4PWbD7Cx2CNhV7i5+dIEIo+4 9EEjJm6h1tA2wRPDXFUD5uqwbgpVXLib2XY+EjUPvqSYzYJRV1dfLWenSnry6WqAymk4 l6GQ3XmW4gMHDe6lLm33VNeZ7/pai4haGF+gZNjwYRf11EvPmhB0TSIfP9/1TA30T0wQ EtL0Z/DyNupwdKdCoivkYbVWrN7QrCU7czMU4ALbQgirRgfr+h/6l2CEzuR2E2ZinvDY wF43TrY1XzE24zRbS84Xd358omBzaoDLDG5WITokW2qT8AXtpn4Lfzpy1h+ITRp8dDUz omfA==
X-Gm-Message-State: AOAM531vTMYBohYIoFmQmQqN/YUQwTOfg4/HrN5sKWp7dvxifPEECWY1 TEPQIyZ+AubILjn93fNRd3m61+Ua4dZHttNLh38=
X-Google-Smtp-Source: ABdhPJwJagUaPK7erExEeABMBqOuYzdBqh5uQgWs5LeTY8XECy2tvdn1hyPP4rxg6qx7JN7G/yyIdxef/W9brkg9Wxs=
X-Received: by 2002:a17:90a:7a8b:: with SMTP id q11mr1567345pjf.215.1616029871351; Wed, 17 Mar 2021 18:11:11 -0700 (PDT)
MIME-Version: 1.0
References: <BY5PR11MB433721C068856ECE2AE4EC5DC19C9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESsyrUTPgkjEPy13W6DRv6ofbW9o_=H9C5bZD3cinGYDD_w@mail.gmail.com> <BY5PR11MB4337AB9127DCEBDC780B52F0C16B9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESsw3vLJudFJ0VMJ-OJBAtQ6w0=_=zn4pGsyVsmyqFWcG5Q@mail.gmail.com> <BY5PR11MB4337CD595C0E577039A1A110C16A9@BY5PR11MB4337.namprd11.prod.outlook.com> <CAMMESszo-LkSLAj+x-JOAb+6J8WWNufPVQ4xJHnC8389KPgMXA@mail.gmail.com> <DACD9B38-106D-49CD-B868-5AED579F63EE@tony.li> <BY5PR11MB4337C479A81A6DC4259D9D8AC16A9@BY5PR11MB4337.namprd11.prod.outlook.com> <94E74912-C3C8-4F6C-BE4D-9F1ADA5D6D5F@tony.li> <BY5PR11MB433783F0EC86C03927CA2EC9C1699@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB433783F0EC86C03927CA2EC9C1699@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 17 Mar 2021 21:11:00 -0400
Message-ID: <CABNhwV2GEJxv+nd2xtJz9wdUe2U31VbkL2UDhLzS==HLDR4HWw@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, Christian Hopps <chopps@chopps.org>, John Scudder <jgs@juniper.net>, Tony Li <tony.li@tony.li>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006daa9305bdc5468a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/_GjdXM9jgKaS5h6VPQDDqE8lC_0>
Subject: Re: [Lsr] When is an IANA Registry Required
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2021 01:11:15 -0000

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>om>;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; lsr@ietf.org; John Scudder <
> jgs@juniper.net>gt;; Christian Hopps <chopps@chopps.org>rg>; 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