Re: [Lsr] When is an IANA Registry Required

Robert Raszuk <robert@raszuk.net> Tue, 16 March 2021 23:46 UTC

Return-Path: <robert@raszuk.net>
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 957F63A1366 for <lsr@ietfa.amsl.com>; Tue, 16 Mar 2021 16:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 dRr4NkxyCWZc for <lsr@ietfa.amsl.com>; Tue, 16 Mar 2021 16:46:12 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 2231B3A1363 for <lsr@ietf.org>; Tue, 16 Mar 2021 16:46:12 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id u20so891665lja.13 for <lsr@ietf.org>; Tue, 16 Mar 2021 16:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A0w1u1I+IdZRF4mNcJdAq5Y2j8iU5k6/FuRTCpJMAfM=; b=NFdm6iBke5GWp86Z9L89vhJx2TknhRkTnJqHqI4OduLtT/LVlS9ottw5e5iijUojer jJ4uJaeHADjnXw+DnYSaJZAipIFDmYv63RP73QGnHVef+mM6K2RLEEnUFNTbGHqJ/eYY zVyrb0rxFy30usmdrt/+5HsWfYlzt0q9ePtOsQBd5oCKw0Oi5Bs5kaEVGOWp9ylyUKNl A2xgi0RAQczhU9YY7C6+eL1Wl9yPETii4BbgjgK8OkX5bjZKvnCFfmWxmuALWN1hywjQ CEIYCOG4Hx3mw2xcelvKGfBOhwHJm2RUZp1iKOMEKdCgd6clVXxdT3Vedanr+XA3X1N7 mmlg==
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=A0w1u1I+IdZRF4mNcJdAq5Y2j8iU5k6/FuRTCpJMAfM=; b=nlmPtT4KX46CKT2sSgGps5Dg25DVF/jZfVrqcY3pmtVZIZNtDkNhzWOMIrwyuZqUE6 iSGKtFaQBf8JAHflzoyoWgLplVb0vEcBXLAxTSDk0EJaGkLbU21QlW72VDXDMCZZRuLA hfXmG8MEWkK7Z7yCg1+GmA8Y8LWAN2HsVETiSrczO0WgUL4q9E99DEe8KkXekDEBeGhm i0u7C3yVpwVjm3mJrQoJKLb8IBOtG+zOil1RvkTJt1OTFiqLQTipixF3F9A9kqbxg4zR xOFUdl2o8+IvnYIbKS0Jmg4liPFS9OtGzhUcfOInyMTC/JrwF+Hw+nZMXGltx9AODTLm NncQ==
X-Gm-Message-State: AOAM533kx+rzCYf2Bky33lQPVyKlyGobgC852TLL7qsf+i9Ep+CVe3cg Mm5AljpSXKEmLqpPCA7v6XW5Zodeyhir9HKDGsk03g==
X-Google-Smtp-Source: ABdhPJwTbNeE0L8PjB0o5fxx7cWLO4xa/Ypd1Mrnp0MTiZkCaTA+mTmS+05bfVYeESq4p8nkovSqa5XJceyHf0gkABY=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr653986ljb.37.1615938369624; Tue, 16 Mar 2021 16:46:09 -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>
In-Reply-To: <BY5PR11MB4337AB9127DCEBDC780B52F0C16B9@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 17 Mar 2021 00:45:58 +0100
Message-ID: <CAOj+MMH7GeUw3wZ3VUx5h2Qh0BVk7c-Q4kn3Yw4q7ZJ-tCzE5g@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="00000000000080537405bdaff898"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yMbbZq9E3z4iTuxVI-6-71GsRFw>
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 23:46:16 -0000

Hi Les,

I would like to share my personal experience that when debugging network
issues say using wireshark or tcpdump often dissectors only decode what is
in IANA registry. Anything beyond they print as hex.

Sure if someone needs to decode it he or she will find an RFC where all
fields are described. But this usually requires manual labor we as lazy
humans are not always best at.

So just from pure convenience (while I do understand heavy labor to move
all flags to IANA) there is some operational value I could see doing it.

Best,
Robert.


On Tue, Mar 16, 2021 at 11:24 PM Les Ginsberg (ginsberg) <ginsberg=
40cisco.com@dmarc.ietf.org> wrote:

> Alvaro -
>
>
>
> Thanx - as always - for the thoughtful response.
>
>
>
> I would like to state up front that I would never consider you to be a
> "casual reader". ๐Ÿ˜Š
>
>
>
> I am also glad you are opening this topic up to comments from others -
> that was my intent as well.
>
>
>
> But one thing I find missing in your response is some info on what problem
> YOU think needs to be addressed?
>
> Do you think there have already been cases where assignment of the bits in
> the flags field associated w a prefix or a neighbor or other object
> comparable to the new TLVs defined in draft-ietf-lsr-isis-srv6-extensions
> (e.g., Locator) has become confusing due to the lack of a registry?
>
> I'd like to think you are motivated by more than a theoretical concern but
> have at least one example based on your many years of experience working on
> protocols.
>
> Such an example would help me understand your motivation better and might
> even convince me that this is a good idea.
>
>
>
> Thanx.
>
>
>
>    Les
>
>
>
>
>
>
>
> > -----Original Message-----
>
> > From: Alvaro Retana <aretana.ietf@gmail.com>
>
> > Sent: Tuesday, March 16, 2021 12:39 PM
>
> > To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>om>;
> draft-ietf-lsr-isis-srv6-
>
> > extensions@ietf.org
>
> > Cc: John Scudder <jgs@juniper.net>et>; lsr-chairs@ietf.org; lsr@ietf.org;
>
> > Christian Hopps <chopps@chopps.org>
>
> > Subject: Re: When is an IANA Registry Required
>
> >
>
> > 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-
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22>
>
> > codepoints.xhtml#isis-tlv-codepoints-19of22
> <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-
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags>
>
> > codepoints.xhtml#prefix-attribute-flags
> <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 mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>