Re: [Lsr] When is an IANA Registry Required
Alvaro Retana <aretana.ietf@gmail.com> Tue, 16 March 2021 19:38 UTC
Return-Path: <aretana.ietf@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 EA7023A0E29; Tue, 16 Mar 2021 12:38:57 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 XXMjeKMPfJEv; Tue, 16 Mar 2021 12:38:56 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (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 BAAC13A0C86; Tue, 16 Mar 2021 12:38:46 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id bm21so74137019ejb.4; Tue, 16 Mar 2021 12:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=LFeqXNu2i5wI2fHgfx9kRqSZZLLgu1LQeoZaZDj72qc=; b=fkMIoqh+T1UZEzZU25UYvjbSgQTQMqQ5oyDxD6WcGa9sypcksseOpI4ueK5t3noWhv 3tSYQmWH7InEWHZ9QLvDWSKOcM50mBTRUnBkf9d1SV8thb5TBpm+yGV0etwukCtpkDv/ rTXQANHPxesxKHJgBvu0WIKsiJ0LLxtgA7guTYB+YpuXfv01hVFccfdmomXhLFS4xiBn 3Dsc2fhxIk/tNx/Mp1gisE+2/TdisYQjZYjehY64bLpLbecqKBSKOiTg//72FUbmqLQv c8AgrOVHPfXWENTIbzB+bxPjG+WV5WMf+TDoQlPP3giGJh6gif2W2jH9nwe5lXOsEA52 pfPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=LFeqXNu2i5wI2fHgfx9kRqSZZLLgu1LQeoZaZDj72qc=; b=Lg+VJMmZR6HvbVYAxHy+Xq0DEFBOUoxc4+nShzrOdKrMnc58DwqchqZmg2MVa1Rj68 p/dvTLwXT2a3v/hutcVZEYfOr2KvHnbWvGOJ18umDlxusvXzPAGe1UNY4njNfOnn6b36 LNuqgExvrjP/Racpen9BUQRTQzm0dEcX6F8y9kTRqJY8qHFm9aD3zkhKYXDqrTSP1CC9 EIbt+n/07tvjsJCjzFEH622glOy6tPstzAduC/5lZi0cLqEELuVeFdSAVk3gTnO9rE69 tOYrx3bBLXfM3L55r7JKB9ZnLd6yoVEMBkOakuobsIPj6spbizRz3GlQwtMpc0ol1Uf8 HcaQ==
X-Gm-Message-State: AOAM5335ApP4rEE6nWxEwt1JQmyn3d4hfTyDthHj/rMg9Ktg4KNwifZD KYV9jsXKXQrzMZJw3V9L9ACG/1m5u8vuQGzM6Ns=
X-Google-Smtp-Source: ABdhPJx4TSEYOB1O+Q+JID69YE8QO9FDy9tORuWuWHatDGrgWotgsiMN/NW6TOcqwRIUG4UWJxNwbdda0IPZJam+xJg=
X-Received: by 2002:a17:907:20f5:: with SMTP id rh21mr31360541ejb.27.1615923524183; Tue, 16 Mar 2021 12:38:44 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 16 Mar 2021 12:38:43 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <BY5PR11MB433721C068856ECE2AE4EC5DC19C9@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <BY5PR11MB433721C068856ECE2AE4EC5DC19C9@BY5PR11MB4337.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Tue, 16 Mar 2021 12:38:43 -0700
Message-ID: <CAMMESsyrUTPgkjEPy13W6DRv6ofbW9o_=H9C5bZD3cinGYDD_w@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>
Cc: John Scudder <jgs@juniper.net>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/uPxeNiQboob-6FTscpwdEDj9IZ0>
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: Tue, 16 Mar 2021 19:39:04 -0000
On February 27, 2021 at 12:57:12 PM, Les Ginsberg wrote: Les: Hi! Sorry for the delay... §4/rfc8126 presents some general arguments for creating registries. But let's talk about this specific case. I'm taking the liberty of summarizing your message this way: > 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. ... > 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. In general, the expectations about the future use of a specific field (as you describe them) are not always obvious to the casual reader[*]. If the intent was clear, and the expectation ("bis...an update") is spelled out in the document then I would not ask about the management of the bits. And even better, future specifications (when maybe none of us are around anymore) would have clear guidance. Having said that, and knowing that I am not the responsible AD for lsr anymore, I would be very happy if the WG decided on requiring future documents to be clear about the intended use and any requirements for the allocation of flags or other unassigned bits. Thanks for starting this discussion! I hope to see other opinions. Alvaro. [*] Anyone else besides maybe the authors themselves, including me. > 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
- [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Alvaro Retana
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Robert Raszuk
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Robert Raszuk
- Re: [Lsr] When is an IANA Registry Required Alvaro Retana
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Alvaro Retana
- Re: [Lsr] When is an IANA Registry Required Tony Li
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Tony Li
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Gyan Mishra
- Re: [Lsr] When is an IANA Registry Required tom petch
- Re: [Lsr] When is an IANA Registry Required Tony Li
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Acee Lindem (acee)
- Re: [Lsr] When is an IANA Registry Required Aijun Wang
- Re: [Lsr] When is an IANA Registry Required Gyan Mishra
- Re: [Lsr] When is an IANA Registry Required bruno.decraene
- Re: [Lsr] When is an IANA Registry Required Les Ginsberg (ginsberg)
- Re: [Lsr] When is an IANA Registry Required Christian Hopps
- Re: [Lsr] When is an IANA Registry Required Aijun Wang
- Re: [Lsr] When is an IANA Registry Required Loa Andersson
- Re: [Lsr] When is an IANA Registry Required Alvaro Retana