Subject: Re: [Lsr] When is an IANA Registry Required

From: Alvaro Retana <[email-masked]>
Date: Tue, 16 Mar 2021 12:38:43 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 16 Mar 2021 22:24:16 +0000

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 <[email-masked]>

> Sent: Tuesday, March 16, 2021 12:39 PM

> To: Les Ginsberg (ginsberg) <[email-masked]>; draft-ietf-lsr-isis-srv6-

> [email-masked]

> Cc: John Scudder <[email-masked]>; [email-masked]; [email-masked];

> Christian Hopps <[email-masked]>

> Subject: Re: When is an IANA Registry Required

> > largely unrelated to each other - might need to allocate an ID from the

> same

> > against this in the past and you relented – but only temporarily it seems.

> 😊

> > rather than have this request be made based on the personal preference

> of the

> largely

> > unrelated to each other - might need to allocate an ID from the same

> > (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>)

> > (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>)

> > field. It was expected (and it has happened) that unrelated documents had

> a

> > Management of the flag space in such cases has never required the

> overhead of

> > IMO, such a policy is not needed, does not add value, but does add

> additional

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Mar 2021 00:45:58 +0100

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=
[email-masked]> wrote:

> 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
>
>
>
>
>
>
>
> > > (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>
> )
>
> > >
>
> > > (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>
> )
>
> > >
>
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Mar 2021 03:31:45 +0000

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 <[email-masked]>
Sent: Tuesday, March 16, 2021 4:46 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; [email-masked]; Christian Hopps <[email-masked]>
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=[email-masked]<mailto:[email-masked]>> wrote:

Alvaro -

Thanx.

   Les

> From: Alvaro Retana <[email-masked]<mailto:[email-masked]>>

> To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; draft-ietf-lsr-isis-srv6-

> [email-masked]<mailto:[email-masked]>

> Cc: John Scudder <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> Christian Hopps <[email-masked]<mailto:[email-masked]>>

_______________________________________________
Lsr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lsr

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Mar 2021 12:06:08 +0100

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) <[email-masked]>
wrote:

> 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 <[email-masked]>
> *Sent:* Tuesday, March 16, 2021 4:46 PM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>
> *Cc:* Alvaro Retana <[email-masked]>; [email-masked]; Christian
> Hopps <[email-masked]>
> *Subject:* Re: [Lsr] When is an IANA Registry Required
>
>
>
> Hi Les,
>
>
>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 17 Mar 2021 07:04:10 -0700

On March 16, 2021 at 6:24:22 PM, Les Ginsberg wrote:

Les:

Hi!

> YOU think needs to be addressed?

I simply think that the specifications are not complete without
guidance on how to use/assign the unused bits.  I rather try to close
that door before a potential problem may come up.

In the extreme case anyone can make use of the bits, through the ISE
or a different SDO -- ideally we will be paying attention, but may
not.  Sure, a registry doesn't stop implementations from squatting on
codepoints either (even inside the IETF), but at least people have to
want to bypass the allocation rules.

My 1c.

Alvaro.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Mar 2021 16:25:23 +0000

Alvaro -

Inline.

> Sent: Wednesday, March 17, 2021 7:04 AM
> Subject: RE: When is an IANA Registry Required
> 
[Les:] Specifications typically say:

"Remaining bits are RESERVED. SHOULD/MUST be transmitted as 0 and MUST be ignored on receipt."

And the same wording is used for bits covered by a registry.
Consider https://www.rfc-editor.org/rfc/rfc7794.html#section-2.1 (for which we do have a registry):

"Undefined bits MUST be transmitted as 0 and MUST be ignored on
   receipt."

> want to bypass the allocation rules.

[Les:] When a specification says "all other bits are reserved, MUST be sent as 0 and MUST be ignored on receipt", I do not see how anyone can assume they can use them - nor why the existence of a  registry would prevent such a squatter from doing whatever they want outside of normal channels.
Are you suggesting that normative statements in RFCs simply don’t mean anything?

Sorry, don’t mean to be argumentative. Just expressing why I am not understanding/agreeing w your POV.

   Les

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 17 Mar 2021 11:27:58 -0700

On March 17, 2021 at 12:25:25 PM, Les Ginsberg wrote:

> [Les:] When a specification says "all other bits are reserved, MUST be sent
> as 0 and MUST be ignored on receipt", I do not see how anyone can assume they
> can use them - nor why the existence of a registry would prevent such a
> squatter from doing whatever they want outside of normal channels.
>

Not at all!

The "MUST send as 0 and MUST ignore" text is normally used when the
application of those bits has not been defined.  If you define the use
of one of the bits then you will obviously set/not ignore it, whether
it has been defined in an ID/RFC or not.  As I said, "a registry
doesn't stop implementations from squatting on codepoints either (even
inside the IETF), but at least people have to want to bypass the
allocation rules."

I don't know that you and I are getting anywhere.  I know Robert also
cares about this topic, I hope others do too.

Alvaro.

---

From: Tony Li <[email-masked]>
Date: Wed, 17 Mar 2021 11:37:22 -0700

> cares about this topic, I hope others do too.

I care.

It seems to me that we have registries where we have different documents allocating values from the same space. This makes sense: we need to coordinate things.

IMHO, whether that space is a set of bit values, octets, shorts, longs, or strings doesn’t matter at all.

It should be tracked and coordinated so that we don’t have collisions. Shared namespaces are fine, but anything shared needs to be managed.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Mar 2021 19:30:56 +0000

Tony -

> From: Tony Li <[email-masked]> On Behalf Of Tony Li
> Sent: Wednesday, March 17, 2021 11:37 AM
> To: Alvaro Retana <[email-masked]>
> Cc: Les Ginsberg (ginsberg) <[email-masked]>; draft-ietf-lsr-isis-srv6-
> [email-masked]; [email-masked]; John Scudder <[email-masked]>;
> Christian Hopps <[email-masked]>; [email-masked]
> It seems to me that we have registries where we have different documents
> allocating values from the same space. This makes sense: we need to
> coordinate things.
> 
> It should be tracked and coordinated so that we don’t have collisions. Shared
> namespaces are fine, but anything shared needs to be managed.
> 
[Les:] The question here is whether there is a qualitative difference between two classes of bit fields.

Category 1 
Flags field in TLVs/sub-TLVs  used for a specific purpose. Addition of new flags to these TLVs would be defined either in a bis draft or a draft which updates the corresponding base draft.
Currently we do not have registries for these cases.

A few examples (there are many more):
1)Flags field in TLV 236 (RFC 5308)
2)Flags field in Prefix Segment Identifier (Prefix-SID) Sub-TLV ( https://www.rfc-editor.org/rfc/rfc8667.html#section-2.1 )
3)Flags field in SRv6 Locator TLV ( https://tools.ietf.org/html/draft-ietf-lsr-isis-srv6-extensions-11#section-7.1 )

Category 2

Flag fields available for use by a variety of unrelated applications.  There are currently two existing examples - both of which have registries.

 https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#prefix-attribute-flags

 https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22

As you can see from the current assignments, in both cases bit definitions occur in the context of drafts which are otherwise unrelated.

The question here is whether bit registries are also appropriate for category 1.

If you could clarify your opinion to speak to this more specific question that would be helpful - at least to me.

Thanx.

   Les

---

From: Tony Li <[email-masked]>
Date: Wed, 17 Mar 2021 13:56:06 -0700

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Mar 2021 00:24:56 +0000

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 <[email-masked]> On Behalf Of Tony Li
Sent: Wednesday, March 17, 2021 1:56 PM
To: Les Ginsberg (ginsberg) <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; John Scudder <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] When is an IANA Registry Required

Les,

Thoughts?

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 17 Mar 2021 21:11:00 -0400

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=
[email-masked]> 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 <[email-masked]> *On Behalf Of *Tony Li
> *Sent:* Wednesday, March 17, 2021 1:56 PM
> *Cc:* Alvaro Retana <[email-masked]>;
> [email-masked]; [email-masked]; John Scudder <
> [email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
> 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
>
> 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
>
> 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
>
> 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
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: tom petch <[email-masked]>
Date: Thu, 18 Mar 2021 12:13:11 +0000

From: Lsr <[email-masked]> on behalf of Tony Li <[email-masked]>
Sent: 17 March 2021 20:56

Les,

Thoughts?

<tp>
I keep seeing YANG modules which reference the RFC that set up the IANA Registry which by then is of course out-of-date as the Normative definition is now in the IANA Registry.  I suspect that the authors fail to notice that this is now an IANA registry just reading the body of the RFC.  We do hide IANA Considerations out of site in Section 42 or some such tucked away at the end of the document.

The other issue is that if you want an example of abysmal choice of an identifier, then the IANA Registry names provide a wealth of examples, along with a comprehensive set of examples of how not to structure information in a hierarchy (assuming, that is, that you want others to be able to find the information).

LSR is not bad in this regard, compared to some routing WG, but it could do better.  Thus I see
Sub-sub-TLV
sub-sub-TLVs
Sub-TLVs
etc
For me everyone of these is not as helpful as it could be.  What matters?  TLV 144, so that comes first; to me, it is a no-brainer but clearly my brain is different.

Tom Petch

Tony

---

From: Tony Li <[email-masked]>
Date: Thu, 18 Mar 2021 08:24:21 -0700

Les,

> 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 b…

With all due respect Les, you appear to operate with an eidetic memory of all things IS-IS, so I think that you discount the confusion that the rest of us live in. 

If a field has values defined in two documents, then there’s confusion. Even just finding both is a challenge.

Regards,
Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 18 Mar 2021 16:44:18 +0000

Tony –

In this context I don’t find the use of a registry of value. The primary issue for me for these fields is not managing the bit assignments but understanding the functionality – and for that I need to look at the document(s) which have that definition. A registry in these cases provides little value and adds process and a possibility for inconsistency.

But, I am not expecting that there is anything I can say to change your opinion – nor vice versa. So I appreciate that you have made your POV clear and the reasons for it – and I am not trying to change your opinion.

I started this thread because I did not think a change in WG policy should be made solely based on a single document review comment from one individual – even one as highly respected as Alvaro.
Thus far we have a handful of opinions – I am hoping more members of the WG will respond to the thread and then we can proceed appropriately.

   Les

Sent: Thursday, March 18, 2021 8:24 AM

Les,

Regards,
Tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Mar 2021 17:14:33 +0000

Speaking as WG member:

Hi Les,
My opinion is there is no harm and some advantage in having IANA registries for unique IGP protocol bit flag fields. For the existing fields that don’t have registries, there is no burning requirement to go back and define an IANA registry until such time as that flag field is extended.

Note that for OSPF, we did add these registries in https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
Thanks,
Acee

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, John Scudder <[email-masked]>, Christian Hopps <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: <[email-masked]>
Resent-To: Acee Lindem <[email-masked]>, Yingzhen Qu <[email-masked]>, Christian Hopps <[email-masked]>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

   Les

Les,

Regards,
Tony

---

From: "Aijun Wang" <[email-masked]>
Date: Fri, 19 Mar 2021 09:30:23 +0800

Adding the bit registries when there is extension for the defined flag field is helpful for reviewing the related IETF documents.

For newly defined flag field, such policy can also apply considering there maybe no bit extensions for some flag field.

And, should this action be discussed in more broader range? I think this is one general issue, not specific to LSR WG.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Acee Lindem (acee)
Sent: Friday, March 19, 2021 1:15 AM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; John Scudder <[email-masked]>; [email-masked]
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les, 

Thanks,

Acee

From: "Les Ginsberg (ginsberg)" <[email-masked] <mailto:[email-masked]> >
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li <[email-masked] <mailto:[email-masked]> >
Cc: Alvaro Retana <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >, John Scudder <[email-masked] <mailto:[email-masked]> >, Christian Hopps <[email-masked] <mailto:[email-masked]> >, "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: <[email-masked] <mailto:[email-masked]> >
Resent-To: Acee Lindem <[email-masked] <mailto:[email-masked]> >, Yingzhen Qu <[email-masked] <mailto:[email-masked]> >, Christian Hopps <[email-masked] <mailto:[email-masked]> >
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

   Les

From: Tony Li <[email-masked] <mailto:[email-masked]> > On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) <[email-masked] <mailto:[email-masked]> >
Cc: Alvaro Retana <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; John Scudder <[email-masked] <mailto:[email-masked]> >; Christian Hopps <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Lsr] When is an IANA Registry Required

Les,

 

Regards,

Tony

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 19 Mar 2021 01:02:21 -0400

I really like the way the RFC 4940 OSPF registries is a one stop shop and
has all the bit flags for both OSPFv2 and OSPFv3 that can be referenced for
all RFCs.

  Nice!!

Great sanity check and helps when reading RFCs as well as I think for IETF
protocol development adding new flags or updating bit values in new drafts
that you are seeking the correctly documented truth to know what to add or
change in your proposed IANA early allocations.

I am changing my position and agree it is a good idea to have the bit flags
IANA registry sanity check and also good for not on operators but vendors
implementations of codepoint and bit flags so they get it right.

Is all of what is covered in the RFC 4940 also covered in the IANA OSPF
links below.

https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml

If all the bit flags are covered in the IANA links is there really a need
for an RFC to that lists all the IANA flags as well,  two sources of the
truth.

So then the only gap is ISIS IANA  codepoints cover all the TLVs, Sub TLVs
but now I think we just need a consensus to agree to bit flag IANA
registries.

I am all for it as their is definitely value in the proposition.

Gyan

On Thu, Mar 18, 2021 at 9:30 PM Aijun Wang <[email-masked]>
wrote:

> Adding the bit registries when there is extension for the defined flag
> field is helpful for reviewing the related IETF documents.
>
> For newly defined flag field, such policy can also apply considering there
> maybe no bit extensions for some flag field.
>
>
>
> And, should this action be discussed in more broader range? I think this
> is one general issue, not specific to LSR WG.
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Friday, March 19, 2021 1:15 AM
> *To:* Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <
> [email-masked]>
> *Cc:* Christian Hopps <[email-masked]>; Alvaro Retana <
> [email-masked]>; [email-masked];
> [email-masked]; John Scudder <
> [email-masked]>; [email-masked]
> My opinion is there is no harm and some advantage in having IANA
> registries for unique IGP protocol bit flag fields. For the existing fields
> that don’t have registries, there is no burning requirement to go back and
> define an IANA registry until such time as that flag field is extended.
>
>
>
> Note that for OSPF, we did add these registries in
> https://www.rfc-editor.org/rfc/rfc4940.txt (thanks to Kireeti).
>
> Thanks,
>
> Acee
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <[email-masked]>
> *Date: *Thursday, March 18, 2021 at 12:44 PM
> *To: *Tony Li <[email-masked]>
> *Cc: *Alvaro Retana <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, John Scudder <[email-masked]>, Christian Hopps <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [Lsr] When is an IANA Registry Required
> *Resent-From: *<[email-masked]>
> *Resent-To: *Acee Lindem <[email-masked]>, Yingzhen Qu <
> [email-masked]>, Christian Hopps <[email-masked]>
> *Resent-Date: *Thursday, March 18, 2021 at 12:44 PM
>
>
>
> Tony –
>
>
>
> In this context I don’t find the use of a registry of value. The primary
> issue for me for these fields is not managing the bit assignments but
> understanding the functionality – and for that I need to look at the
> document(s) which have that definition. A registry in these cases provides
> little value and adds process and a possibility for inconsistency.
>
>
>
> But, I am not expecting that there is anything I can say to change your
> opinion – nor vice versa. So I appreciate that you have made your POV clear
> and the reasons for it – and I am not trying to change your opinion.
>
>
>
> I started this thread because I did not think a change in WG policy should
> be made solely based on a single document review comment from one
> individual – even one as highly respected as Alvaro.
>
> Thus far we have a handful of opinions – I am hoping more members of the
> WG will respond to the thread and then we can proceed appropriately.
>
>
>
>    Les
>
>
>
> *Sent:* Thursday, March 18, 2021 8:24 AM
> With all due respect Les, you appear to operate with an eidetic memory of
> all things IS-IS, so I think that you discount the confusion that the rest
> of us live in.
>
>
>
-- 

*Gyan Mishra*

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 19 Mar 2021 09:51:30 +0000

+1
The information needs to be tracked and consolidated. Seems better done by a single person than by many persons duplicating the work, not to mention by zero person (surely someone else is doing the job).
This may be less important in LSR though, as we have designated experts which may already do this work. However:
-IINM, the designated expert is only appointed when there is a registry.
-IMHO there would be value in having the tracking data been public. IANA looks good to me. In theory, github may also work.

That also assumes that code point/flags be tracked -hence allocated- soon enough, rather than been hidden in a draft or specific implementation.

Thanks,
--Bruno

From: Acee Lindem (acee) [mailto:[email-masked]]
Sent: Thursday, March 18, 2021 6:15 PM
To: Les Ginsberg (ginsberg) <[email-masked]>; Tony Li <[email-masked]>
Cc: Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; John Scudder <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]
Subject: Re: [Lsr] When is an IANA Registry Required

Speaking as WG member:

Hi Les,

From: "Les Ginsberg (ginsberg)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 18, 2021 at 12:44 PM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, John Scudder <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Lsr] When is an IANA Registry Required
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Acee Lindem <[email-masked]<mailto:[email-masked]>>, Yingzhen Qu <[email-masked]<mailto:[email-masked]>>, Christian Hopps <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, March 18, 2021 at 12:44 PM

Tony –

   Les

From: Tony Li <[email-masked]<mailto:[email-masked]>> On Behalf Of Tony Li
Sent: Thursday, March 18, 2021 8:24 AM
To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
Cc: Alvaro Retana <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; John Scudder <[email-masked]<mailto:[email-masked]>>; Christian Hopps <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Lsr] When is an IANA Registry Required

Les,

Regards,
Tony

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 22 Mar 2021 06:37:21 +0000

Tony –

I hope I can be forgiven for one more post on this subject. In any case, here it is.

First, at the risk of some repetition, I want to emphasize that the reason I started this thread was to define a consistent policy. Currently we do not have registries for the flags fields in various TLVs. In recent document reviews, Alvaro strongly suggested that we introduce a registry for the flag field in the new TLV(s) which were being defined. I do not think the policy should be inconsistent in this regard, so I started this thread to get the WG to agree on what the policy will be across all such fields in all TLVs. Whatever the outcome of this discussion (i.e., to have such registries or to NOT have them), so long as there is a consistent policy, this thread will have served the purpose and I will be satisfied. (For those of you who may be fans of Ralph Waldo Emerson, I consider this to be NOT a “foolish consistency”. 😊 )

Now, as regards the potential usefulness of such registries, I think this has nothing to do with “memory”.  I can assure you that I refer to the existing registries with great frequency and do not trust my memory on such things.

Registries exist today (and are very useful) for number spaces for which requests come from a large number of largely unrelated documents. So, for top level TLVs, almost every IS-IS related RFC which has been published defines one or more codepoints. Without a registry our ability to track what is currently allocated and what is available would be severely compromised. Similarly for sub-TLVs and the other registries under the TLV Codepoints umbrella. However, in regards to flags fields which are part of the fixed portion of a TLV format definition, tracking bit allocation has not been an issue – and I argue that it is best tracked in other ways which are already defined. To be specific:

If an additional flag bit for an existing  TLV is defined in the future, there are two possible ways of doing this:

1)A bis document is written. The new document then contains all normative content from the original document as well as the new content (in this example an additional flag bit). The new document is required to be marked as “obsoleting” the original version. Once the document is published, the original document is marked as “obsoleted by xxx” and the existing entry for the affected code point in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml is marked to point to the new document.

2)A separate document is written focused only on the additions to the base definition for the TLV. The new document is required to be clearly marked as “updating” the original document. The original document is marked as “updated by new document”. In addition, the existing entry in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml would be updated to point to both the original document and the new document.

This seems to me be fully functional and easy to use. Even if your memory on such matters is not fresh, by simply bookmarking https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml you will easily be able to find whatever information you need.

The addition of a separate registry for each flags field is then redundant at best. And redundancy in such matters introduces additional work and the possibility of unintentional inconsistency which I find hard to justify. Hence my conclusion that the value of such additional registries does not justify their creation.

You (and others) may still disagree. And I assure you that as my primary motivation for this thread was to have a consistent WG policy for such fields, I will abide by whatever policy is chosen by the WG even if it is not my preferred choice. But I do think the arguments being made for the creation of such registries bear closer scrutiny. Just my opinion of course…

Thanx (again) for listening.

   Les

Les,

Regards,
Tony

---

From: Christian Hopps <[email-masked]>
Date: Mon, 22 Mar 2021 04:56:31 -0400

> On Mar 22, 2021, at 2:37 AM, Les Ginsberg (ginsberg) <ginsberg=[email-masked]> wrote:
> 
> Tony –
> 
> 1)A bis document is written. The new document then contains all normative content from the original document as well as the new content (in this example an additional flag bit). The new document is required to be marked as “obsoleting” the original version. Once the document is published, the original document is marked as “obsoleted by xxx” and the existing entry for the affected code point in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> is marked to point to the new document.
> 
> 2)A separate document is written focused only on the additions to the base definition for the TLV. The new document is required to be clearly marked as “updating” the original document. The original document is marked as “updated by new document”. In addition, the existing entry in https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> would be updated to point to both the original document and the new document.

As WG member,

I have approached this generally in the following way. If the flags field seems to be of the type (1) no IANA registry should be required. If the flags field seems to be of the type (2) then one could allocate a registry or leave it to the updating document to do so. The more one expects that a type (2) document is likely to be written, the more one should really consider creating the registry up-front in the field defining document.

IOW I don't think one should have to follow a tree of "updates" links hunting down *possible* new flag definitions, but following an "obsoleted by" chain to the latest version of a document is expected, and in this case the registry content would always point at a single document so would not be of any real value.

Thanks,
Chris.

> This seems to me be fully functional and easy to use. Even if your memory on such matters is not fresh, by simply bookmarking https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> you will easily be able to find whatever information you need.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr <https://www.ietf.org/mailman/listinfo/lsr>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 23 Mar 2021 10:18:51 +0800

Hi, Les:

Even for IS-IS, there is already the flag registries example, please see the following pointer:

And, even for your proposal 2), it is still not concise as the flag registries. Considering that we have one flag filed that has 16bit, and there will be 16 updates to the original document if it defines no bit at the beginning and every additional document defines one bit only?

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Les Ginsberg (ginsberg)
Sent: Monday, March 22, 2021 2:37 PM
To: Tony Li <[email-masked]>
Cc: Christian Hopps <[email-masked]>; Alvaro Retana <[email-masked]>; [email-masked]; [email-masked]; John Scudder <[email-masked]>; [email-masked]
Subject: Re: [Lsr] When is an IANA Registry Required

Tony –

   Les

 

Les,

 

Regards,

Tony

---

From: Loa Andersson <[email-masked]>
Date: Tue, 23 Mar 2021 13:27:57 +0800

Toni, Ajun, et.al.,

I think that what Ajun says is that a IANA registry is often (very) 
practical long before it is "required".

I'm a bit concerned that by stating  a requirement, we might in practice 
raise the bar for then a registry is created. People read the 
requirement and says that ""Nay, it is not really need, so I won't 
create a new registry", and then a few years down the line we find that 
a registry would have been helpful.

So I'd say that as soon as you see that there might be more code points 
registered from the namespace you are creating, create a registry.

/Loa

On 23/03/2021 10:18, Aijun Wang wrote:
> And, even for your proposal 2), it is still not concise as the flag 
> registries. Considering that we have one flag filed that has 16bit, and 
> there will be 16 updates to the original document if it defines no bit 
> at the beginning and every additional document defines one bit only?
> 
> Best Regards
> 
> Aijun Wang
> 
> China Telecom
> 
> *From:[email-masked] <[email-masked]> *On Behalf Of *Les 
> Ginsberg (ginsberg)
> *Sent:* Monday, March 22, 2021 2:37 PM
> *To:* Tony Li <[email-masked]>
> *Cc:* Christian Hopps <[email-masked]>; Alvaro Retana 
> <[email-masked]>; [email-masked]; 
> [email-masked]; John Scudder 
> <[email-masked]>; [email-masked]
> First, at the risk of some repetition, I want to emphasize that the 
> reason I started this thread was to define a consistent policy. 
> Currently we do not have registries for the flags fields in various 
> TLVs. In recent document reviews, Alvaro strongly suggested that we 
> introduce a registry for the flag field in the new TLV(s) which were 
> being defined. I do not think the policy should be inconsistent in this 
> regard, so I started this thread to get the WG to agree on what the 
> policy will be across all such fields in all TLVs. Whatever the outcome 
> of this discussion (i.e., to have such registries or to NOT have them), 
> so long as there is a consistent policy, this thread will have served 
> the purpose and I will be satisfied. (For those of you who may be fans 
> of Ralph Waldo Emerson, I consider this to be NOT a “foolish 
> consistency”. 😊)
> 
> Now, as regards the potential usefulness of such registries, I think 
> this has nothing to do with “memory”.  I can assure you that I refer to 
> the existing registries with great frequency and do not trust my memory 
> on such things.
> 
> Registries exist today (and are very useful) for number spaces for which 
> requests come from a large number of largely unrelated documents. So, 
> for top level TLVs, almost every IS-IS related RFC which has been 
> published defines one or more codepoints. Without a registry our ability 
> to track what is currently allocated and what is available would be 
> severely compromised. Similarly for sub-TLVs and the other registries 
> under the TLV Codepoints umbrella. However, in regards to flags fields 
> which are part of the fixed portion of a TLV format definition, tracking 
> bit allocation has not been an issue – and I argue that it is best 
> tracked in other ways which are already defined. To be specific:
> 
> If an additional flag bit for an existing  TLV is defined in the future, 
> there are two possible ways of doing this:
> 
> 1)A bis document is written. The new document then contains all 
> normative content from the original document as well as the new content 
> (in this example an additional flag bit). The new document is required 
> to be marked as “obsoleting” the original version. Once the document is 
> published, the original document is marked as “obsoleted by xxx” and the 
> existing entry for the affected code point in 
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> 
> is marked to point to the new document.
> 
> 2)A separate document is written focused only on the additions to the 
> base definition for the TLV. The new document is required to be clearly 
> marked as “updating” the original document. The original document is 
> marked as “updated by new document”. In addition, the existing entry in 
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> 
> would be updated to point to both the original document and the new 
> document.
> 
> This seems to me be fully functional and easy to use. Even if your 
> memory on such matters is not fresh, by simply bookmarking 
> <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> 
> you will easily be able to find whatever information you need.
> 
> The addition of a separate registry for each flags field is then 
> redundant at best. And redundancy in such matters introduces additional 
> work and the possibility of unintentional inconsistency which I find 
> hard to justify. Hence my conclusion that the value of such additional 
> registries does not justify their creation.
> 
> You (and others) may still disagree. And I assure you that as my primary 
> motivation for this thread was to have a consistent WG policy for such 
> fields, I will abide by whatever policy is chosen by the WG even if it 
> is not my preferred choice. But I do think the arguments being made for 
> the creation of such registries bear closer scrutiny. Just my opinion of 
> course…
> 
> *From:*Tony Li <[email-masked] <mailto:[email-masked]>> 
> *On Behalf Of *Tony Li
> *To:* Les Ginsberg (ginsberg) <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Alvaro Retana <[email-masked] 
> <mailto:[email-masked]>>; 
> [email-masked] 
> <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>; John Scudder <[email-masked] 
> <mailto:[email-masked]>>; Christian Hopps <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>
>     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.
> 
> With all due respect Les, you appear to operate with an eidetic memory 
> of all things IS-IS, so I think that you discount the confusion that the 
> rest of us live in.
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64