IETF Logo Mail Archive

Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt

Kent Watsen <kent+ietf@watsen.net> Thu, 08 December 2022 03:02 UTC

Return-Path: <01000184efaf6098-44b9712e-b4e6-43c8-a7ed-1245b811ee1a-000000@amazonses.watsen.net>
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 D2BF3C14CF01 for <netmod@ietfa.amsl.com>; Wed, 7 Dec 2022 19:02:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrN7aLiHL6fZ for <netmod@ietfa.amsl.com>; Wed, 7 Dec 2022 19:02:40 -0800 (PST)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46011C14CEFC for <netmod@ietf.org>; Wed, 7 Dec 2022 19:02:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1670468559; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=mmlVfSykd90TZy9WrZ5MQm7l2K+/0eMho4w6mIDO7kM=; b=OFvR0arTNM8ESgzzExMmrQJhLN3eLnNqL0vt/rE3fDP0h1wTn46vqXlyVaBQc/Zq qL3KuBf5kYMrQCV8WCD3yu8e/AjPJvu7nMILzB9UqRfNAgAr6lfr9FalGzFrPnWYJUf hJp15eT5xRxdDn9ZNnjkg0nRyQDdvO9V9L7F4ipE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <20221207.092731.2267015585780052231.id@4668.se>
Date: Thu, 08 Dec 2022 03:02:39 +0000
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-ID: <01000184efaf6098-44b9712e-b4e6-43c8-a7ed-1245b811ee1a-000000@email.amazonses.com>
References: <01000184e3f14a15-95feeb1e-c027-4366-ab2c-291ac3f03cc8-000000@email.amazonses.com> <20221205223741.mxeacefm46mkpwrl@anna> <CABCOCHQ1JxcDn0OPnKWFpz9vcZzW8YOjEP8_wdF_KK2z=EoREQ@mail.gmail.com> <20221207.092731.2267015585780052231.id@4668.se>
To: Andy Bierman <andy@yumaworks.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.12.08-54.240.48.94
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ESz4H9ZD5zGvBos_PJfyNjvtYA4>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-14.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 08 Dec 2022 03:02:40 -0000

>> Deprecating ip-address (and ipv4-address and ipv6-address?) is probably the
>> most disruptive
>> change to YANG that one could make.  

No, the most disruptive thing would be to do what roughly 1/2 of the WG was proposing before, which is to introduce now a non-backwards compatible change in the existing definitions, which would immediately break all legacy uses.


>> A type name cannot be changed.

Nothing of the sort is being proposed here.


>> A new name can be introduced so there are 2 types that do the same thing.
>> IMO this will increase the overall confusion, and not help in any way.

We are addressing the current/existing confusion, as discussed in the last 9 months and in a virtual interim.  Not doing anything would be truly unhelpful.

The strategy is to gradually move towards having only explicit names.   The first step is to introduce a new explicit name, while deprecating the legacy ambiguous name.  This provides time for modules to slowly migrate to the new name.  The second step, to be done only after the "versioning" work lands, is to remove the legacy deprecated name, while marking the module revision as having an NBC change.  

Between the two steps is when there may be confusion but even then, not really, if tooling properly warns about deprecated nodes. 


Kent // contributor

v2.23.0 | Report a Bug | By Email