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) <ginsb...@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 <rob...@raszuk.net>
> *Sent:* Tuesday, March 16, 2021 4:46 PM
> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>
> *Cc:* Alvaro Retana <aretana.i...@gmail.com>; lsr@ietf.org; Christian
> Hopps <cho...@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....@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.i...@gmail.com>
>
> > Sent: Tuesday, March 16, 2021 12:39 PM
>
> > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>;
> draft-ietf-lsr-isis-srv6-
>
> > extensi...@ietf.org
>
> > Cc: John Scudder <j...@juniper.net>; lsr-cha...@ietf.org; lsr@ietf.org;
>
> > Christian Hopps <cho...@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 mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
