Subject: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

From: John Scudder via Datatracker <[email-masked]>
Date: Thu, 13 May 2021 08:43:15 -0700

John Scudder has entered the following ballot position for
draft-ietf-lsr-isis-srv6-extensions-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Below are some questions and comments. I'd appreciate a reply, thanks.

1. Abstract

   The Segment Routing (SR) allows for a flexible definition of end-to-

You either have too many, or not enough words here. Either “segment routing“
(remove “the“), or something like “the segment routing architecture“.

   called "segments".  Segment routing architecture can be implemented

And here you do need “the“ in front of “segment”.

   over an MPLS data plane as well as an IPv6 data plane.  This document

“An” -> “the” (two places)

   over an IPv6 data plane.

“An” -> “the”

   This documents updates RFC 7370 by modifying an existing registry.

“Documents” -> “document”

Also, this doesn’t seem to me like an update to RFC 7370. It’s normal for an
RFC to update an IANA registry, without saying it updates a previous RFC that
established that registry. I think the “updates” just confuses matters and
clutters things up, and should be removed.

2. Section 1

   This documents updates [RFC7370] by modifying an existing registry
   (Section 11.1.2).

“Documents” -> “document”

See also comment #1 regarding update.

3. Section 4.3

   A non-zero SRH Max H.encaps MSD indicates that the headend can insert
   an SRH up to the advertised value.

“Up to the advertised value” doesn’t make sense. I guess you mean “can insert
an SRH with up to the advertised number of SIDs”?

4. Section 4.4

   The Maximum End D MSD Type specifies the maximum number of SIDs
   present in an SRH when performing decapsulation.

That makes sense.

              These includes, but
   not limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with
   USD as defined in [RFC8986].

That doesn’t. How can a number include all those specific things? A number’s
just an integer, right? Maybe you are providing some helpful context about the
types of SIDs that are permitted to be present? If so, I expect this is
specified elsewhere already, and this sentence is not helping; I would suggest
removing it. If it does need to stay, it needs a rewrite for grammar and
clarity. (Maybe you want something like “As specified in [RFC 8986] the
permitted SID types include, but are not limited to, <list>.”)

      If the advertised value is zero or no value is advertised
      then the router cannot apply any behavior that results in
      decapsulation and forwarding of the inner packet if the
      other IPv6 header contains an SRH.

What “other” IP header? Do you mean the outer header? The inner header?
Something else?

5. Section 5

   In cases where a locator advertisement is received in both a Prefix
   Reachability TLV and an SRv6 Locator TLV - (e.g. prefix, prefix-
   length, MTID all being equal and Algorithm being 0 in Locator TLV),

Since “e.g.” means “for example” you’re saying the thing in the parentheses is
only one example of a locator advertisement received in both? What’s another
example? (Maybe the algo being 1 in both cases?)

But in any case the text above appears redundant with the text that immediately
follows. Can’t the text above be deleted?

   In case where the same prefix, with the same prefix-length, MTID, and
   algorithm is received in both a Prefix Reachability TLV and an SRv6
   Locator TLV, the Prefix Reachability advertisement MUST be preferred
   when installing entries in the forwarding plane.  This is to prevent
   inconsistent forwarding entries between SRv6 capable and SRv6
   incapable routers.

“In case” -> “in the case” or “in cases”

6. Section 7.2

   Supported behavior values together with parent TLVs in which they
   area advertised are specified in Section 10 of this document.  Please

“Area” -> “are”

      Length: variable.

      Flags: 1 octet.  No flags are currently defined.

When you write “length: variable“, I think you mean “length: a 1 octet field,
whose value is variable“, don’t you? Just like you write “flags: 1 octet“? I
get that the value placed into the length field is variable, but the way you’ve
written it, it says that the length of the length field is itself variable,
which would make no sense.

This is not the only place in the document you specify a length field this way,
but I guess you should fix all of them. I’m only noting it here.

   The SRv6 End SID MUST be a subnet of the associated Locator.  SRv6
   End SIDs which are not a subnet of the associated locator MUST be
   ignored.

Is a host route (which is what a SID is) technically a “subnet”? Can something
which is not a net, be a subnet? It reads funny that way. If you change it,
possibly “MUST be covered by the associated Locator“? (Although then for
clarity you might need to define “covered“, which might not be any better.)
(Same comment applies to Section 8 which also mentions “subnet”.)

7. Section 8.1

         B-Flag: Backup flag.  If set, the SID is eligible for
         protection (e.g., using IPFRR) as described in [RFC8355].

Please expand IPFRR on first use. And since you say “e.g.” meaning “for
example”, do you contemplate some other kind of protection which is not IPFRR?
If not, I think you could delete the parenthesis without loss of clarity.

8. Section 9

   SRv6 SID Structure Sub-Sub-TLV is used to advertise the as defined in
   [RFC8986].  It has the following format:

You’re missing something between “advertise the” and “as defined”.

      Length: 4 octets.

Similar to my earlier comment, I think what you mean is something like “Length:
a 1 octet field, whose value is 4”.

   associated with it.  It's usage is outside of the scope of this
   document.

“It’s” -> “its”

9. Section 11

   and sub-sub-TLVs as well updating the ISIS TLV registry and defining

“As well as”

   a new registry.

Doesn’t it define several new registries?

10. Section 11.2

Shouldn’t there be a new subsection for the registry creation?

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 13 May 2021 10:20:08 -0700

On May 13, 2021 at 11:44:44 AM, John Scudder wrote:

John:

Hi!

Thanks for the review!

Just replying to one of your comments:

...
> clutters things up, and should be removed.

In this case the document is not only registering a value.  It is
changing the name of the registry, adding an extra column, and
updating all the other entries (§11.1.*).  The Updates tag is used
because it significantly changes the registry.

Thanks!

Alvaro.

---

From: John Scudder <[email-masked]>
Date: Thu, 13 May 2021 18:00:13 +0000

On May 13, 2021, at 1:20 PM, Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:

Still seems unnecessary to me, registries are moving targets, citation of all the relevant RFCs in their references should be sufficient. So, the registry would be updated so that it cited both this spec and 7370, and someone wanting to know “how did the registry get this way?” would be able to work it out.

I’m not going to fight about it; the “updates” is not very harmful. I say “not very” because the diligent reader might be led to think they need to go read RFC 7370 in order to properly understand this spec, and waste some time realizing that isn’t true. Since for better or worse we don’t have a firm definition of when we do, and don’t, use “updates”, it comes down to a matter of personal taste in the end.

$0.02,

—John

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 13 May 2021 19:12:36 +0000

Alvaro –

FWIW, I agree w John here.

There are many examples – to cite a few:

Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute TLVs)
…
Reference
    [RFC5305][RFC5316][RFC7370][RFC8668]

RFC 8868 is not marked as updating RFC 7370.
RFC 7370 is not marked as updating RFC 5316/RFC 5305.

Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)
…
Reference
    [RFC5305][RFC7370]

Again, RFC7370 is not marked as updating RFC 5305.

I think it is sufficient to request that IANA add the new RFC to the list of References for the modified registry.

   Les

From: Lsr <[email-masked]> On Behalf Of John Scudder
Sent: Thursday, May 13, 2021 11:00 AM
To: Alvaro Retana <[email-masked]>
Cc: John Scudder via Datatracker <[email-masked]>; Christian Hopps <[email-masked]>; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

$0.02,

—John

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 May 2021 12:42:47 +0200

John, Alvaro,

do we have a consensus whether we need the update to RFC 7370 or not?

thanks,
Peter

On 13/05/2021 21:12, Les Ginsberg (ginsberg) wrote:
> Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 (Extended IS 
> reachability, IS Neighbor Attribute, L2 Bundle Member Attributes, 
> inter-AS reachability information, MT-ISN, and MT IS Neighbor Attribute 
> TLVs)
> 
> …
> 
> Reference
> 
> Sub-TLVs for TLVs 135, 235, 236, and 237 (Extended IP reachability, MT 
> IP. Reach, IPv6 IP. Reach, and MT IPv6 IP. Reach TLVs)
> 
> …
> 
> Reference
> 
>      [RFC5305][RFC7370]
> 
> I think it is sufficient to request that IANA add the new RFC to the 
> list of References for the modified registry.
> 
>     Les
> 
> *From:* Lsr <[email-masked]> *On Behalf Of *John Scudder
> *Sent:* Thursday, May 13, 2021 11:00 AM
> *To:* Alvaro Retana <[email-masked]>
> *Cc:* John Scudder via Datatracker <[email-masked]>; Christian Hopps 
> <[email-masked]>; [email-masked]; The IESG <[email-masked]>; 
> [email-masked]; [email-masked]
> *Subject:* Re: [Lsr] John Scudder's No Objection on 
> draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
> 
> Still seems unnecessary to me, registries are moving targets, citation 
> of all the relevant RFCs in their references should be sufficient. So, 
> the registry would be updated so that it cited both this spec and 7370, 
> and someone wanting to know “how did the registry get this way?” would 
> be able to work it out.
> 
> I’m not going to fight about it; the “updates” is not very harmful. I 
> say “not very” because the diligent reader might be led to think they 
> need to go read RFC 7370 in order to properly understand this spec, and 
> waste some time realizing that isn’t true. Since for better or worse we 
> don’t have a firm definition of when we do, and don’t, use “updates”, it 
> comes down to a matter of personal taste in the end.
> 
> $0.02,
> 
> —John
>

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 17 May 2021 03:54:44 -0700

Peter:

Hi!

As John mentioned, "Since for better or worse we don’t have a firm
definition of when we do, and don’t, use “updates”, it comes down to a
matter of personal taste in the end.”

I rather you leave it in.

Thanks!

Alvaro.

On May 17, 2021 at 6:42:48 AM, Peter Psenak ([email-masked]) wrote:

John, Alvaro,

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 17 May 2021 12:21:27 +0000

That we be my preference as well. We’ve had several discussions on what constitutes “update” and I believe that the consensus was that a document isn’t “updated” unless the current behavior is changed. If we’ve done our jobs, protocols are designed to be extended and these extensions shouldn’t constitute updates.
Thanks,
Acee

From: Alvaro Retana <[email-masked]>
Date: Monday, May 17, 2021 at 6:55 AM
To: "Les Ginsberg (ginsberg)" <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, John Scudder <jgs=[email-masked]>
Cc: John Scudder via Datatracker <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Christian Hopps <[email-masked]>
Subject: Re: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
Resent-From: <[email-masked]>
Resent-To: Yingzhen Qu <[email-masked]>, Christian Hopps <[email-masked]>, Acee Lindem <[email-masked]>
Resent-Date: Monday, May 17, 2021 at 6:54 AM

Peter:

Hi!

As John mentioned, "Since for better or worse we don’t have a firm definition of when we do, and don’t, use “updates”, it comes down to a matter of personal taste in the end.”

Thanks!

Alvaro.

On May 17, 2021 at 6:42:48 AM, Peter Psenak ([email-masked]<mailto:[email-masked]>) wrote:
John, Alvaro,

thanks,
Peter

On 13/05/2021 21:12, Les Ginsberg (ginsberg) wrote:
> *From:* Lsr <[email-masked]<mailto:[email-masked]>> *On Behalf Of *John Scudder
> *To:* Alvaro Retana <[email-masked]<mailto:[email-masked]>>
> *Cc:* John Scudder via Datatracker <[email-masked]<mailto:[email-masked]>>; Christian Hopps
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On May 13, 2021, at 1:20 PM, Alvaro Retana <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

---

From: John Scudder <[email-masked]>
Date: Mon, 17 May 2021 12:48:13 +0000

Acee,

I think you are saying you prefer to remove the “updates”. Is that right? It was a little confusing given the reply chain.

(I’ve already given my opinion but said I’m not going to go to the mat over it.)

—John

On May 17, 2021, at 8:21 AM, Acee Lindem (acee) <acee=[email-masked]> wrote:

Peter:

Hi!

Thanks!

Alvaro.

thanks,
Peter

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 17 May 2021 12:56:11 +0000

Hi John,
Yes – I think “updates” should be removed. Registries are created explicitly for the purpose of tracking extensions and every document that adds to a registry should not update the document creating that registry. Now if the definition or application of the registry were changed, which I don’t believe is the case here, then we could consider “updates”.
Thanks,
Acee

From: John Scudder <jgs=[email-masked]>
Date: Monday, May 17, 2021 at 8:48 AM
To: Acee Lindem <[email-masked]>
Cc: Alvaro Retana <[email-masked]>, "Les Ginsberg (ginsberg)" <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, John Scudder via Datatracker <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG <[email-masked]>, Christian Hopps <[email-masked]>
Subject: Re: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)

Acee,

—John

Peter:

Hi!

Thanks!

Alvaro.

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 May 2021 15:00:18 +0200

Hi John,

thanks for your comments, please see inline (##PP):

> https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-srv6-extensions/

##PP
I reworded the abstract. This text was written prior to me taking over 
the document...

> clutters things up, and should be removed.

##PP
looks like we converged towards keeping it.

> “Documents” -> “document”

##PP
fixed

> an SRH with up to the advertised number of SIDs”?

##PP
fixed

> types of SIDs that are permitted to be present? 

##PP
yes, it was specifically requested by Alvaro during his AD review.

> If so, I expect this is

##PP
I changed to:

"As specified in [RFC 8986] the permitted SID types include, but are not 
limited to, End.DX6, End.DT4, End.DT46, End with USD, End.X with USD."

> What “other” IP header? Do you mean the outer header? The inner header?

##PP
should be "outer" instead of "other", it was a typo, I fixed it.

> follows. Can’t the text above be deleted?

##PP
yeah, that has been pointed out by other reviewers, I have left the old 
text there by mistake. I have removed the above.

> “In case” -> “in the case” or “in cases”

##PP
fixed.

>     area advertised are specified in Section 10 of this document.  Please

##PP
fixed.

> which would make no sense.

##PP
It refers to the value of the Length field. In the case it is static, we 
specify exact value, if it is variable we say "variable". We use this in 
many ISIS RFCs (e.g. RFC8667, section 2.2.2.)

> (Same comment applies to Section 8 which also mentions “subnet”.)

##PP
what about:

"The SRv6 End SID MUST be allocated from its associated locator's 
prefix. SRv6 End SIDs that are not allocated from the associated 
locator's prefix MUST be ignored."

> If not, I think you could delete the parenthesis without loss of clarity.

##PP
done

>     [RFC8986].  It has the following format:

##PP
fixed.

>     associated with it.  It's usage is outside of the scope of this

##PP
fixed
	
>     and sub-sub-TLVs as well updating the ISIS TLV registry and defining

##PP
fixed

> Doesn’t it define several new registries?

##PP
indeed, after we added registries for flag fields

> Shouldn’t there be a new subsection for the registry creation?

##PP
added

thanks,
Peter

---

From: Peter Psenak <[email-masked]>
Date: Mon, 17 May 2021 15:07:21 +0200

Hi Acee,

On 17/05/2021 14:56, Acee Lindem (acee) wrote:
> Hi John,
> 
> Yes – I think “updates” should be removed. Registries are created 
> explicitly for the purpose of tracking extensions and every document 
> that adds to a registry should not update the document creating that 
> registry. Now if the definition or application of the registry were 
> changed, which I don’t believe is the case here, then we could consider 
> “updates”.

RFC 7370 created the registry by merging multiple existing registries. 
It did not really defined any new functionality.

We are changing the name of that merged registry. Given that RFC 7370 
did not define anything new, just defined the merged registry, one can 
consider the name change as an update to RFC 7370.

thanks,
Peter
> 
> Thanks,
> 
> Acee
> 
> *From: *John Scudder <jgs=[email-masked]>
> *Date: *Monday, May 17, 2021 at 8:48 AM
> *To: *Acee Lindem <[email-masked]>
> *Cc: *Alvaro Retana <[email-masked]>, "Les Ginsberg (ginsberg)" 
> <[email-masked]>, "Peter Psenak (ppsenak)" <[email-masked]>, John 
> Scudder via Datatracker <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, The IESG 
> <[email-masked]>, Christian Hopps <[email-masked]>
> *Subject: *Re: John Scudder's No Objection on 
> I think you are saying you prefer to remove the “updates”. Is that 
> right? It was a little confusing given the reply chain.
> 
>     That we be my preference as well. We’ve had several discussions on
>     what constitutes “update” and I believe that the consensus was that
>     a document isn’t “updated” unless the current behavior is changed.
>     If we’ve done our jobs, protocols are designed to be extended and
>     these extensions shouldn’t constitute updates.
> 
>     Thanks,
> 
>     Acee
> 
>     *From: *Alvaro Retana <[email-masked]>
>     *Date: *Monday, May 17, 2021 at 6:55 AM
>     *To: *"Les Ginsberg (ginsberg)" <[email-masked]>, "Peter Psenak
>     (ppsenak)" <[email-masked]>, John Scudder
>     <jgs=[email-masked]>
>     *Cc: *John Scudder via Datatracker <[email-masked]>,
>     "[email-masked]"
>     <[email-masked]>, "[email-masked]"
>     <[email-masked]>, "[email-masked]" <[email-masked]>, The
>     IESG <[email-masked]>, Christian Hopps <[email-masked]>
>     *Subject: *Re: John Scudder's No Objection on
>     *Resent-From: *<[email-masked]>
>     *Resent-To: *Yingzhen Qu <[email-masked]>, Christian Hopps
>     <[email-masked]>, Acee Lindem <[email-masked]>
>     *Resent-Date: *Monday, May 17, 2021 at 6:54 AM
> 
>     Peter:
> 
>     Hi!
> 
>     definition of when we do, and don’t, use “updates”, it comes down to
>     a matter of personal taste in the end.”
> 
>          > *From:* Lsr <[email-masked]
>         <mailto:[email-masked]>> *On Behalf Of *John Scudder
>          > *Cc:* John Scudder via Datatracker <[email-masked]
>         <mailto:[email-masked]>>; Christian Hopps
>          > <[email-masked] <mailto:[email-masked]>>;
>         [email-masked] <mailto:[email-masked]>; The IESG
>         <[email-masked] <mailto:[email-masked]>>;
>          > [email-masked]
>         <mailto:[email-masked]>;
>         [email-masked] <mailto:[email-masked]>
>          > On May 13, 2021, at 1:20 PM, Alvaro Retana
>         <[email-masked] <mailto:[email-masked]>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 17 May 2021 14:02:43 +0000

Hi Peter, 

On 5/17/21, 9:07 AM, "Peter Psenak" <[email-masked]> wrote:

    Hi Acee,

Ok - I missed that. I agree with that it updates RFC 7370 since the registry name changed as opposed to simply adding code points. 

Thanks,
Acee

    thanks,
    Peter

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 May 2021 04:33:23 +0000

Sorry folks - one more attempt to correct what I see as inappropriate dependencies.

Codepoint registries are created in part precisely to avoid having to update pre-existing documents when we need to add additional codepoints to the registry. The registry is the living entity and when additions are required we update the registry - not older documents which have contributed to the existing contents of the registry. Nor do we have to generate a new document to present the updated contents of the registry. All of that is handled simply by updating the registry.

The only legitimate reason to update an older document would be if we are actually changing in some way one or more of the existing codepoints already defined in the registry. That is not happening here.

The suggestion that RFC 7370 needs to be "updated" because draft-ietf-lsr-isis-srv6-extensions requires additions to an existing registry first created by RFC 7370 stands the dependency relationship between a registry and the document(s) which specify entries in the registry on its head.

The argument here seems to be that we are "changing the name of the registry" - hence the document that first created the registry with the existing name has to be considered as updated. This is illogical. The renaming of the registry in no way alters any of the existing codepoints.
This is certainly not what was done when RFC 8668 modified https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-22-23-25-141-222-223  - another registry created by RFC 7370.

Perhaps the somewhat unfortunate choice of the name of the registry - which inserts the codepoint for all the TLVs supported by the registry into the registry name - feeds into this confusion.
If so, I would suggest renaming the registry to:  "Sub-TLVs for TLVs advertising NLRI".
The registry name would then never have to be changed and we could more easily avoid being drawn into an inappropriate use of "update".

   Les

> -----Original Message-----
> From: Acee Lindem (acee) <[email-masked]>
> Sent: Monday, May 17, 2021 7:03 AM
> To: Peter Psenak (ppsenak) <[email-masked]>; John Scudder
> Cc: Alvaro Retana <[email-masked]>; Les Ginsberg (ginsberg)
> <[email-masked]>; John Scudder via Datatracker <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> The IESG <[email-masked]>; Christian Hopps <[email-masked]>
> Ok - I missed that. I agree with that it updates RFC 7370 since the registry
> name changed as opposed to simply adding code points.
> 
> Thanks,
> Acee
> 
>     thanks,
>     Peter
>     >
>     > Thanks,
>     >
>     > Acee
>     >

---

From: Christian Hopps <[email-masked]>
Date: Wed, 19 May 2021 05:52:15 -0400

> The registry name would then never have to be changed and we could more easily avoid being drawn into an inappropriate use of "update".

The existing names are mouthful that's for sure. I think updating the name might make sense.

Thanks,
Chris.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 19 May 2021 06:54:48 -0700

Les:

Hi!

In this case the name is being changed, a new column is added, and all
the existing code points are updated in light of the new column.

I realize this may not be enough for you.  Instead of all of us
discussing this specific case, we should focus our energy on clearly
defining what “Updates” means — there’s a proposal that could be a
starting point [1].

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag

On May 19, 2021 at 12:33:27 AM, Les Ginsberg wrote:

> The only legitimate reason to update an older
> document would be if we are actually changing
> in some way one or more of the existing codepoints
> already defined in the registry. That is not
> happening here.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 19 May 2021 16:46:00 +0000

Alvaro -

I don’t find the referenced draft relevant to this case.

Our difference of opinion has to do with the function of a codepoint registry.
Registries are created as a place to both document existing codepoints and to be updated when the need for additional codepoints arises.
There is no benefit or need (IMO of course) for an RFC which initially created the registry to be marked as "updated" when new codepoints are added to the registry - which is really all that is happening here.

Is there anything in RFC 7370 that states or implies that the name of the registry is not subject to change?
Is there anything in RFC 7370 that states or implies that the set of TLVs under the purview of the registry is not subject to change?
Why are either of these cases functionally any different from adding a new sub-TLV codepoint to the registry?

I do agree that this is not worth the time being spent on it. So, you have my input. I leave it to the ADs/WG chairs/IESG review to close this issue.
Thanx for listening.

   Les

> Sent: Wednesday, May 19, 2021 6:55 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>; Acee Lindem (acee)
> <[email-masked]>; Peter Psenak (ppsenak) <[email-masked]>; John
> Scudder <jgs=[email-masked]>
> Cc: John Scudder via Datatracker <[email-masked]>; draft-ietf-lsr-isis-srv6-
> [email-masked]; Christian Hopps <[email-masked]>; lsr-
> [email-masked]; [email-masked]; The IESG <[email-masked]>
> Subject: RE: John Scudder's No Objection on draft-ietf-lsr-isis-srv6-
> extensions-14: (with COMMENT)
> 
> Les:
> 
> Hi!
>

---

From: Christian Hopps <[email-masked]>
Date: Wed, 19 May 2021 15:06:17 -0400

My final input would be that it is important to maintain the linkages. So if an RFC creates a registry and then that registry's name is changed by another RFC then, unfortunately, I think that the second RFC updates the first.

Otherwise I agree with Les.

How about we pick names that don't need updating in the future?

Thanks,
Chris.