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

Alvaro Retana <aretana.ietf@gmail.com> Mon, 17 May 2021 10:54 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C173A32D8; Mon, 17 May 2021 03:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b2AT2Q1joC5; Mon, 17 May 2021 03:54:49 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59FF93A32D4; Mon, 17 May 2021 03:54:48 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id i13so6302863edb.9; Mon, 17 May 2021 03:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=svYa0zGQgk52wtUCKUkI0HamVxIlYxm+di030qq0j8k=; b=PlxZwiEVBP5oX+X1BJibOA9Iz1Kf++17cOPLkLHb8SRQvjPb/QZA0IjiiNq1hZDwAG Wuinb8bsoiY8jO28mZyzDic9AVgjGG/XZIA/KnviE1W1jpWf71FDDgmo+1q98usdNyBl 2Dtm2EgbfRPYML5Z63uaWOnS4imCQprFr7hxwdLeNv24kPadqoE1ajaoBS5OaiqqtS5F usPBGFTkqlH80om1e6WpKCYx7O7Rk5/nzhWP4tWJ/1mJHSNTD3Qo++ytW0AmQdT7EqoR 2kDk4OCQx0pmKmHBscgis9aENZiUJMMW8xGkT4aXpZGcUEwO1AzLq+Z/oeu2DDjEPxo1 eS6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=svYa0zGQgk52wtUCKUkI0HamVxIlYxm+di030qq0j8k=; b=FaudVYnfPBowu1BDB98VgJYKgq+tXYUEO2aqDWXoObNPaX5O4Zx7C+URv2zKHiOafc 8DfImu45G4sy3j4+VXEjzRlSQ3g48GwKvFLNKc1AHzLJPYmBlk6oGlQ9/6yNi1b5IBkm KTCqPhTfO/2qQgVtr/KO3bVpzwqxEjonTTepxw69Qt6r8aExH3vcj0Qxnvvj5KpkqNMP KmGdFL57Rteh69CUYlzTns5LpNm3DRBcaPYX83Fs3P4N+botiVE2EsFVR6MvVDzHmTLq AAm640iFGDhn1MpMaSThASHlHX7KNXs7IkxoC7NUxZ5YjHMR3InMRW3Q+8ObBRXSL/ot i75A==
X-Gm-Message-State: AOAM5315fKHaRGM+AumN3TL0V4FAD1a/IetKZsPa4cWeR2NrY7h6ngyi jPvuzfG/X7M3LYQEPEPGlqUEAdBq+XVAPP6OwLw=
X-Google-Smtp-Source: ABdhPJwLxE81lqGh11ZO+CD/6k0z7pPOzaWQBaBhnHey4LAR7cgusesGhaI/epnzSG2PUg6FoXOoi8SNbcwedf/SmPI=
X-Received: by 2002:a05:6402:310a:: with SMTP id dc10mr71248036edb.38.1621248885728; Mon, 17 May 2021 03:54:45 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 17 May 2021 03:54:45 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <ddcfb6db-f5e4-1aa7-e45f-c9b5905de147@cisco.com>
References: <162092059520.16031.2606295470570253120@ietfa.amsl.com> <CAMMESsw7V4YrsgUf9RR7GOqmTrc9T0gxVs7omF4E34zg0R2RgQ@mail.gmail.com> <8702605F-CF59-4F1E-B4CE-02951B894D1F@juniper.net> <BY5PR11MB4337994AA5C89060CAEE3E2FC1519@BY5PR11MB4337.namprd11.prod.outlook.com> <ddcfb6db-f5e4-1aa7-e45f-c9b5905de147@cisco.com>
MIME-Version: 1.0
Date: Mon, 17 May 2021 03:54:44 -0700
Message-ID: <CAMMESsyk0=ro8V3bVQddU=kn+Z7howEiCZ6mGP7bmFnWvMqXOA@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Peter Psenak <ppsenak@cisco.com>, John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: John Scudder via Datatracker <noreply@ietf.org>, "draft-ietf-lsr-isis-srv6-extensions@ietf.org" <draft-ietf-lsr-isis-srv6-extensions@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-chairs@ietf.org" <lsr-chairs@ietf.org>, The IESG <iesg@ietf.org>, Christian Hopps <chopps@chopps.org>
Content-Type: multipart/alternative; boundary="000000000000ed2a3d05c2846b29"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/HuY3OJWgodBoH7dJsV9hcM41fSs>
Subject: Re: [Lsr] John Scudder's No Objection on draft-ietf-lsr-isis-srv6-extensions-14: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 10:54:54 -0000

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 (ppsenak@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-bounces@ietf.org> *On Behalf Of *John Scudder
> *Sent:* Thursday, May 13, 2021 11:00 AM
> *To:* Alvaro Retana <aretana.ietf@gmail.com>
> *Cc:* John Scudder via Datatracker <noreply@ietf.org>rg>; Christian Hopps
> <chopps@chopps.org>rg>; lsr-chairs@ietf.org; The IESG <iesg@ietf.org>rg>;
> draft-ietf-lsr-isis-srv6-extensions@ietf.org; 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.ietf@gmail.com
> <mailto:aretana.ietf@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
>