Re: [Lsr] When is an IANA Registry Required
Robert Raszuk <robert@raszuk.net> Wed, 17 March 2021 11:06 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 5CA443A1292 for <lsr@ietfa.amsl.com>; Wed, 17 Mar 2021 04:06:25 -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 p4yvlUn4PYwv for <lsr@ietfa.amsl.com>; Wed, 17 Mar 2021 04:06:22 -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 83ECB3A1290 for <lsr@ietf.org>; Wed, 17 Mar 2021 04:06:21 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id u20so2538638lja.13 for <lsr@ietf.org>; Wed, 17 Mar 2021 04:06:21 -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=DkdgphULwz4mMP0dbteCLvP5NW9uf0fTklfUmOpRNZI=; b=b+on+Lu7amIDZCWMdDZC/+g0mlwDTQY4pQmR3AG+Zt1V1sP5FIhgyZKFjoVvfTZqjI z/gcOGmLlinn0UIgYZ9wmXEqVbvZ3HrfDOsmnjIYT8Psr7nUFXtvUA/B1WEFJGnSjD7M HYe8uZ29ak6vWeY4PY7DCYIiL4VgBgMv+oBDJ5gHFbwuTA50gtChTxtGFj7GXr6i8VsS rsw/QmbyvxTWL5ZlLR9QdgQS0ga4fifwFwy9DNXhCdhAYBRJu10eRiXoJWsoADqAwU7a S0+ZPwQBcjZzktDZ/RTMqEZEAavBMoECTT34NRGaCxuBK9PeCMn/X2SraxPjA2N39Mf0 T8mg==
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=DkdgphULwz4mMP0dbteCLvP5NW9uf0fTklfUmOpRNZI=; b=cpL52TFHcCQ8Bmd8AUlZkceSMEXMr+Kbj9EqWIX0hiUb7u2JDvS/3A8jSrCnc4ULFr X7RGZ2Ikrt9/MGlsxDfTm9wLev9c7Z3ewenVunMg39Hmxju6qMQTnM05Ipt4B81TOawi ovqpBeDM9SGfFT5dEB8GkxQb8rfnw5IO0PG0D+O6kjaaaKHqe8fDaFpaIFU4wLLdcE2A vqRj0uXM7nRqTMkaJqZq1dtuKB4bfK8DlErctvPcWCSQ763+boejdIMZjFZInrUxdbcY YKBxZ10z5q1QLV5a+CCjXypKTuwVIe35F/mhqy+u0+DQ9Aunpxzh9oIcdcX7rVZZfP6B fXnA==
X-Gm-Message-State: AOAM532qikwurQ+Ipbxdc8XBVm3eOB0aL74diij/2ATkV/WOX78/Iwhh wsbPISxqx8xNCMOEcaUgiKDJsF5Bt6hA5Ntblq0Mhw==
X-Google-Smtp-Source: ABdhPJzcQQHkooxK21fNSTlcl9uwaWFoVv5hFIEg1itW99kZKcA0QLMTAYzBjqZz5+Hl8DOcrSMh+Y7yg+TMfrlna/Q=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr2009370ljb.37.1615979178557; Wed, 17 Mar 2021 04:06:18 -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> <CAOj+MMH7GeUw3wZ3VUx5h2Qh0BVk7c-Q4kn3Yw4q7ZJ-tCzE5g@mail.gmail.com> <BY5PR11MB4337988146230CD1E3DFDE8DC16A9@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337988146230CD1E3DFDE8DC16A9@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 17 Mar 2021 12:06:08 +0100
Message-ID: <CAOj+MMG_LqsVYVMH80ZZRW_sEEjan_=RaAW=nxNTfktX95fFnA@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="000000000000e7169905bdb97863"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/apxjMqBne9b3_v_G9QqGPpKzMvs>
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: Wed, 17 Mar 2021 11:06:25 -0000
Hi Les, Perhaps I did not express my point clearly. My intention was not to say that implementors *only* look at IANA codepoints. I said often not always :) They sure look at RFCs too. My point was that if I need to decode something - IANA gives me sort of decode cheatsheet and reference to RFC. It's type of dictionary in networking. We do not have alternative I am afraid and having protocols be defined in bunch of RFCs and sometimes still in drafts makes it a bit of a challenge to find the right one. Even flags in a number of cases are added in subsequent documents so even if you know to look at base spec then you need to follow "Updated by XYZ ..." and dig via a lot of text to find an answer instead of just a simple one page table lookup. Many thx, R. On Wed, Mar 17, 2021 at 4:31 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote: > Robert – > > > > My experience with Wireshark does not match yours. > > > > In my experience, packet decoders aren’t always up on the latest spec > revisions – it is always a catchup game – but it isn’t true that only > values from an IANA registry are displayed. > > And from an implementation standpoint, the engineer writing the decoder > always has to look at the draft/RFC. An IANA Registry does not provide the > format of the fixed fields (e.g., prefix, metric) – so I have a hard time > agreeing with your perception that implementors only look at IANA > registries. > > I actually think it is the other way round – they look at drafts/RFCs and > only look at registries when the document points to them. 😊 > > > > Les > > > > > > *From:* Robert Raszuk <robert@raszuk.net> > *Sent:* Tuesday, March 16, 2021 4:46 PM > *To:* Les Ginsberg (ginsberg) <ginsberg@cisco.com> > *Cc:* Alvaro Retana <aretana.ietf@gmail.com>; lsr@ietf.org; Christian > Hopps <chopps@chopps.org> > *Subject:* Re: [Lsr] When is an IANA Registry Required > > > > 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>; > draft-ietf-lsr-isis-srv6- > > > extensions@ietf.org > > > Cc: John Scudder <jgs@juniper.net>; 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 > >
- [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