IETF Logo Mail Archive

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

Christian Hopps <chopps@chopps.org> Sat, 09 April 2022 11:43 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFE3A09B5; Sat, 9 Apr 2022 04:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IJSQcGNITf0m; Sat, 9 Apr 2022 04:43:41 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E41373A0CE9; Sat, 9 Apr 2022 04:43:40 -0700 (PDT)
Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 219A87D05D; Sat, 9 Apr 2022 11:43:40 +0000 (UTC)
References: <164662287026.10186.17661147788695088858@ietfa.amsl.com> <AM7PR07MB62483353E387A0538EDA44C6A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <AM7PR07MB6248D0B4D19EF3168DEC4864A0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <978D3500-5A9C-49FA-A259-B4E234CC9332@cisco.com> <AM7PR07MB6248CE4BDC0B27008D4F04BCA0E59@AM7PR07MB6248.eurprd07.prod.outlook.com> <2C00E058-F836-415E-A357-797E01FE77AD@cisco.com> <DB7E3112-3C2F-4040-81E1-F4625689DA62@chopps.org> <645FCC0B-8279-4070-B052-A553317B8474@cisco.com> <3F7DDA02-DEFA-4680-B048-1AB0A54C2FA1@chopps.org> <BB1D53D0-0D36-40DF-8B9D-4BD4EB6A35C1@cisco.com> <5b05a34d-41b6-7b65-ebe7-9dcaca80eeb2@alumni.stanford.edu> <m2wnfzydgz.fsf@ja.int.chopps.org> <530e30e1-9436-2123-7d03-eb4f876a9f90@alumni.stanford.edu> <72050246-8379-40CE-9171-110997FB0D5C@cisco.com> <28570b96-a7a0-1aee-9104-2402892a2089@alumni.stanford.edu>
User-agent: mu4e 1.7.12; emacs 28.0.92
From: Christian Hopps <chopps@chopps.org>
To: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
Cc: "lsr@ietf.org" <lsr@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Date: Sat, 09 Apr 2022 07:36:42 -0400
In-reply-to: <28570b96-a7a0-1aee-9104-2402892a2089@alumni.stanford.edu>
Message-ID: <m2fsmmfpn8.fsf@ja.int.chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X2PpR-16poIeJIcdyqTj3t-NAR4>
Subject: Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2022 11:43:46 -0000

Randy Presuhn <randy_presuhn@alumni.stanford.edu> writes:
> 30+ years of tradition (and BCP) not permitting types to be changed
> after they've been published, I suppose, motivated by our total lack
> of control over unpublished usage of these types after their definitions
> have been published.
>
> If there were actually something wrong with the semantics or syntax,
> I'm sure there would be more sympathy for the argument.  But the heart
> of the argument is that the types label's mnemonicity is poor.  That,
> coupled with the collateral damage resulting from a "fix", makes
> the whole argument terribly unpersuasive to me, particularly
> when the definition in question was been published, implemented, and
> deployed years ago.

FWIW, I'm not arguing for this change; however, to be fair, isn't this also about the existing published modules that are using the incorrect type?

Thanks,
Chris.


>
> Randy
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

v2.23.0 | Report a Bug | By Email