Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

Jeffrey Haas <jhaas@pfrc.org> Thu, 10 February 2022 12:03 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC583A0BD6; Thu, 10 Feb 2022 04:03:47 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 9XYuVQ9xP0f1; Thu, 10 Feb 2022 04:03:42 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EB6E23A0BCA; Thu, 10 Feb 2022 04:03:41 -0800 (PST)
Received: from smtpclient.apple (99-59-193-67.lightspeed.livnmi.sbcglobal.net [99.59.193.67]) by slice.pfrc.org (Postfix) with ESMTPSA id B4DD01E32F; Thu, 10 Feb 2022 07:03:39 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_C717E957-EE42-4BCE-8ADB-589E9CA3D475"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <6204EFEE.1090006@btconnect.com>
Date: Thu, 10 Feb 2022 07:03:39 -0500
Cc: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>, t petch <ietfa@btconnect.com>, Mahesh Jethanandani <mjethanandani@gmail.com>, YANG Doctors <yang-doctors@ietf.org>, "rtg-bfd@ietf. org" <rtg-bfd@ietf.org>, "draft-ietf-bfd-rfc9127-bis.all@ietf.org" <draft-ietf-bfd-rfc9127-bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Message-Id: <6E3FCDCE-F6AC-4369-BE4B-1E1C1DDA5BDA@pfrc.org>
References: <164388736861.32491.11649774516476095771@ietfa.amsl.com> <E68495BC-E0D3-4192-9C7F-C4E6F1EF8E9A@gmail.com> <61FCF2DA.7080706@btconnect.com> <22A163B4-F2B0-48EF-8334-AD234F886327@cisco.com> <6201581F.1010901@btconnect.com> <C5882481-1B62-44C8-889C-E64E611BE38F@pfrc.org> <6203F4C0.5050106@btconnect.com> <11F2C8D5-3A28-4ACA-8E26-4CE7ABF1B8EE@cisco.com> <6204EFEE.1090006@btconnect.com>
To: tom petch <daedulus@btconnect.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/cbAgIaSBHWkeRri186yjAnf-n8w>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Feb 2022 12:03:48 -0000


> On Feb 10, 2022, at 5:58 AM, tom petch <daedulus@btconnect.com> wrote:
> 
> Second, you may be right that no implementations exist but what if, in a few years time, an implementor looks at the two versions, sees one that is horribly complicated with a Cartesian explosion of YANG feature and sees no reason not to implement the much simpler, if earlier, one. Obscure may be, but who knows who will be doing what in the lifetime of these two documents (which we should assume is several years IMO).

If you're a vendor that supports the nodes that are being made if-feature conditional in 9127-bis and you want to ship 9127 as your supported module?

Go for it.

This entire discussion is weird.  For all of your hand wringing, absolutely none of this discussion can force a future implementor to choose to support one version of a module over another.  

The trend will ideally be to support newer versions of models because they include features they want. But perhaps they want older base-level stuff.  If that implementation is somewhere between?  Deviation modules will be crafted for that implementation.

If you think this minor bit of work creates compatibility issues even though it doesn't move or rename a single leaf?  Then you'd be for a rather rude awakening at how other organizations do this stuff.  Those other organizations don't have to give a damn about supporting the entire set of possible features or arbitrary vendor quirks.  They get to pick and choose.  The trend there isn't to use features, it's to force the deviations.  We have it easy.

-- Jeff