Thanks,
Acee
*From: *John Scudder <jgs=40juniper....@dmarc.ietf.org>
*Date: *Monday, May 17, 2021 at 8:48 AM
*To: *Acee Lindem <a...@cisco.com>
*Cc: *Alvaro Retana <aretana.i...@gmail.com>, "Les Ginsberg (ginsberg)"
<ginsb...@cisco.com>, "Peter Psenak (ppsenak)" <ppse...@cisco.com>, John
Scudder via Datatracker <nore...@ietf.org>,
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
<draft-ietf-lsr-isis-srv6-extensi...@ietf.org>, "lsr@ietf.org"
<lsr@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, The IESG
<i...@ietf.org>, Christian Hopps <cho...@chopps.org>
*Subject: *Re: John Scudder's No Objection on
draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
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=40cisco....@dmarc.ietf.org> wrote:
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 <aretana.i...@gmail.com>
*Date: *Monday, May 17, 2021 at 6:55 AM
*To: *"Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "Peter Psenak
(ppsenak)" <ppse...@cisco.com>, John Scudder
<jgs=40juniper....@dmarc.ietf.org>
*Cc: *John Scudder via Datatracker <nore...@ietf.org>,
"draft-ietf-lsr-isis-srv6-extensi...@ietf.org"
<draft-ietf-lsr-isis-srv6-extensi...@ietf.org>, "lsr@ietf.org"
<lsr@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, The
IESG <i...@ietf.org>, Christian Hopps <cho...@chopps.org>
*Subject: *Re: John Scudder's No Objection on
draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
*Resent-From: *<alias-boun...@ietf.org>
*Resent-To: *Yingzhen Qu <yingzhen.i...@gmail.com>, Christian Hopps
<cho...@chopps.org>, Acee Lindem <a...@cisco.com>
*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.”
I rather you leave it in.
Thanks!
Alvaro.
On May 17, 2021 at 6:42:48 AM, Peter Psenak (ppse...@cisco.com
<mailto:ppse...@cisco.com>) wrote:
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:
> 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 <lsr-boun...@ietf.org
<mailto:lsr-boun...@ietf.org>> *On Behalf Of *John Scudder
> *Sent:* Thursday, May 13, 2021 11:00 AM
> *To:* Alvaro Retana <aretana.i...@gmail.com
<mailto:aretana.i...@gmail.com>>
> *Cc:* John Scudder via Datatracker <nore...@ietf.org
<mailto:nore...@ietf.org>>; Christian Hopps
> <cho...@chopps.org <mailto:cho...@chopps.org>>;
lsr-cha...@ietf.org <mailto:lsr-cha...@ietf.org>; The IESG
<i...@ietf.org <mailto:i...@ietf.org>>;
> draft-ietf-lsr-isis-srv6-extensi...@ietf.org
<mailto:draft-ietf-lsr-isis-srv6-extensi...@ietf.org>;
lsr@ietf.org <mailto:lsr@ietf.org>
> *Subject:* Re: [Lsr] John Scudder's No Objection on
> draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
>
> On May 13, 2021, at 1:20 PM, Alvaro Retana
<aretana.i...@gmail.com <mailto:aretana.i...@gmail.com>
> <mailto:aretana.i...@gmail.com
<mailto:aretana.i...@gmail.com>>> wrote:
>
> This documents updates RFC 7370 by modifying an existing
> registry.
>
> 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.
>
>
> 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.
>
> 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
>
