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

tom petch <daedulus@btconnect.com> Thu, 10 February 2022 10:59 UTC

Return-Path: <daedulus@btconnect.com>
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 62C553A07EF; Thu, 10 Feb 2022 02:59:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level:
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.714, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 e4SSZH_SPsic; Thu, 10 Feb 2022 02:59:10 -0800 (PST)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0c::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8CF3A067B; Thu, 10 Feb 2022 02:59:08 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ipZuQcPyDSNdy83FCVZxL5qG9Bk0kGe9HqpRw3f76SWaFLenoaQBtNn8Gm3ogRMjcjW0BcDa3Z6AEqwa1uugP9ucX/VtqufYgLWxwp69LRJDhB8lkTVIPs+cCYUvyup/iL/n1R+rLgNWBkPP27U6Tl63fncMLgdobFbnPY/S7sxgWgtt81hgjqGwB/wsMTFZCDrzgDsAtgN5FPbaDSfeBzayY8Y+wLdK0uuaYIr3D2jL9DWcG1uCUion1vCez7s7Bo0NcSTxWhSyAV4iNxXNuGM7sBfRf152oZNb8LXVK2QSJ+QjiJVc1E7ksXj7CELFgqWNEpLLETbxOvxj6qT2oA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KiAC/LU8pI6Rhl+diOQG5M9HKxjx09Q+V5XHic/Rhzs=; b=GBQJZq56RI5mFlfs7wzZKC5VqEFnzpor4MkRjJt5Qo9AUDiS62StoBzJLowXvGYO08g6XtCvNrdTjtlcNRsip0HF2MAk4pC3nzNw8Mx5P1PIbo+gP9czYd5yTtP3w+ihaECJsCqMJKvawgXBkVGQmBpK/Ja6g1uPivOPbrK89EMtApQm5XSNbT9sOpMTmYe5kUwlcm0BA5V/lzBvmwDF9pWwRRNVGbxe10eGPn5gLNqF6KtPcgM4xU0wcUtRhMuCtIr5nV4jV00OJxO4IJYosgGD/YVVFBBxwkappDFj1A7wnSIB4VU4HlHFu4ESw7/YhF2DQ4m2qWGCWPOYoL40hg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KiAC/LU8pI6Rhl+diOQG5M9HKxjx09Q+V5XHic/Rhzs=; b=CGHL9lwjTJdQmwnBsQ4B3tfj/TF+mwo+iq4ypEW5Wmj9GV8RkZCWfLKVevc1Lr6bJQsPHhLfnkr3/o39WJWwtyfgBZDW8sfiHowYbC7E3Tz6dERlc8yGJfbMcmK6ReYaVnarMeSFHNAC/EFi7PEdfkRG6J5rFalPGPC8gFXzzv4=
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB2638.eurprd07.prod.outlook.com (2603:10a6:801:4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.6; Thu, 10 Feb 2022 10:59:03 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::1040:a0b:e4e1:f512]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::1040:a0b:e4e1:f512%5]) with mapi id 15.20.4975.011; Thu, 10 Feb 2022 10:59:03 +0000
Subject: Re: [Last-Call] Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01
To: "Jan Lindblad (jlindbla)" <jlindbla@cisco.com>, t petch <ietfa@btconnect.com>
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>
Cc: Jeffrey Haas <jhaas@pfrc.org>, 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>
From: tom petch <daedulus@btconnect.com>
Message-ID: <6204EFEE.1090006@btconnect.com>
Date: Thu, 10 Feb 2022 10:58:54 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <11F2C8D5-3A28-4ACA-8E26-4CE7ABF1B8EE@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: LO4P123CA0122.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:192::19) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8)
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e62a2b7b-c63e-470c-dfe5-08d9ec8458f2
X-MS-TrafficTypeDiagnostic: VI1PR0701MB2638:EE_
X-Microsoft-Antispam-PRVS: <VI1PR0701MB263826C8AF4BE0E7E33ED052C62F9@VI1PR0701MB2638.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 41GG2efAO05jnhuYustzOnUJo4cgOGxaBXZPjGsXjblX/aU0Yv4Gb0J1uB0YbtjLK/xKLfQzvyRA2BseNPNVn2ffbDjinUriaHCEOnb1BOOmtLAANbKTP7NM4BOA55gTQwlviFVsNI8+WkTTc9pWQsQ+j0yhF6mlTTZU74tf2PcVLM6qJqYbBLE2kHXBMZnRVnKGPYlSP41jbheVoT+D6gMgNr/2smduUbp9KBjRLIcHMmBEjGdFL73RuFsxen8vSC5lxCFfynJEwGwiCKYyn1O6H2N0TgcW8sszbtUr0xEcKUSDTRWhQKarVT4s5qJXJ8mSLRBTLqe/9310e1cS/boPJ5drI6BiJI0tj1cS3Ir0LC2rjKJ/lIQmvBo1apmxyeElWvhzqIqoxzBbIAyCqJuWXPlIxvoSvbZ6npcbn+b8LoNp73BFBvNKUVfBD09IlAYTqvOgpMb5zEOwH/bZU5ypuIOq28EjF0fFduqBJi8FLmGmO4gXEqGHKHYMQ+4b+MY/76m6wF9GLS/Xu7xmAnD/p6EEyHzQN27W75AMkzC/3fKhXmhMj1bshJy714eeBddmQi6Ncqqo1hPyuW0f8rHocxvsEQq27f1gDtphIDuK7kTooy7crKp079dV2rngThyaNpUrbsZ23Vt1LffGtnhcRzq1Ocw59Ls4wuM78xfLMFjFEbr7CadfQoqsWej2d6WvUCpaqPMnd2ag/1R/ktqFRNTWxR936qPKwVryCnjSOadUpM0kPUtYQhl13SOR8WHfJNhSsYkWDWzMoSRoxQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(5660300002)(33656002)(36756003)(966005)(6486002)(508600001)(8936002)(6512007)(186003)(26005)(2616005)(83380400001)(87266011)(53546011)(52116002)(6666004)(6506007)(66574015)(2906002)(38100700002)(316002)(54906003)(6636002)(86362001)(110136005)(38350700002)(8676002)(66946007)(82960400001)(66476007)(66556008)(4326008); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: mnFYX50wYNqtvaObFA3NSLLxdFyShHET0S31dTY/HYo55P3vPR4cdrISlNcWo4UNY0XS1rNw+GJ3jKfuubrP5SJEYvYPsIWoX3FaK+BrNVRocjfPD/7v766is+UEXoZReCX390dHdNOztcZCCprMSK32etNCGXCR3q1ireE4aynlUcgMVAWHF9pM8Yaj0LIUZfT1xgEHlwN+lxMb4Zx4d+3ED89CSbS/wtSq0BEURjOE4z3aIjNOjWzxj71ur9VY5Ljbq2zcbRkTUlfwmYiyE4g2EAngIA+wLySMBGx+9O0aQYCP5XHWZvhCrnyWcJeppq29wCJoJNrzRNsOdDqqTin0zWtA0v7M5iP9RMNFrgA7vo7F5GiUUF/pdab4D4ecbKeoAGQEqhHoXNDP+MHnfqTbxmsg8r1Kh2mOLo4T1CnI4aS2jMHaB2xhxSMSRJtzIe2qZJEWacFw2GIn9nXzGjVRsjSKhHuNAXGdRx0EncYQrD9GP84I7gOZRU50aDd4yuVWb0oYLyxjcm91Ttweg791EzjTbdzWC1RcOHu8gbgWeSeelF2ZdZ0LquQQ4LgdB0gU0DZFY5lPPsk4TrkEObAN1FeAPmUdYbOwJfL+E1giOBW5OukKtB0lcm5710IIvD8i01sHz2q8nflThE//troJIwRsnZ25x+JjSkflHiM42/Jx0sWhUiQ4SEB7XqsrJYuRyIDD+ojr7p1LdEq0rHj9TmhvUs5uukWVIwJBnfMQrWmxRCTWCFcrWTVNQWPAIFi9/axdLViJ/WGMTtj6Wc6ZWm5ZBJrR5Ins/Q6fVBHBloSVQiRGX+6de9fM+Re/CCHBsxwiX72EJ7AQoEMgpJ7hQK/BXvNJUhpfL7kCatmG/ZFR7HtjKCP2an4jhVF92coNV6zL0MrISpeqRp/YRGA2HRGP+qGkWnsTF/IccFqbWB6yg0mi1ikB5gn/YIQdLfQOJkwwT4iJ0iDrC6fgd3zZrb6DhK3GhK0JrXLoT//2DIENPchgC4psmyU4zguVTVIXeUB8xuuz2kxIaUNrsyYXVNwyc3Ey5n/0wOA2NmT7R/hjCROzFryezgnCQ/Do28qQNzeNJnHWScHHhoCqPswQcmleD2u5EfzL9MtHE4iRWr7QkuwBpHzt9RI5mrZXAhfSLRK6zxxG+U0kIS4JwwfkL1Bu7HmqeovZrUzI/f7hLlI9uqxIW6BCZ3RANMNK7dccBjejJaJBBRtuI4y/OArym324rOJEU1uxlNUuGFQvua4Ib03DFoReN6p6jCwA+PtHXAhFr7G6iQO1qH0mgsQexYU/Yo8lsCJpT52a/c7Og4geerS9P7wG+7rKuYZ3y4pX0Ga5zP1mv4J47tciIZIcNQ/dIq1NLJYE3SY8hcOgaWLUZdw8u+fYhxlSi1EekAg+iCpxTQ8FsM43AVWJi32E98BFutR3werYD8gPHlCQoLwTzJEWboOInlY1m/1fQOGPqg8ktRlUOvv5GQIe42WnKupPH1qi7XfiPANxwI56Qq0FNsIxkuhPBR5LzBUkDgitcqyBFQ2HJOU2MZWkBd2LI7bGlIG3xHvRAYlb+kX34SqYewyO3HaykCByr0TDwWmUxj5aeVOZznmiwuLA+f/uL0DpXVscMJ/nWxmhXnA=
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e62a2b7b-c63e-470c-dfe5-08d9ec8458f2
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2022 10:59:03.1784 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: qoghD5H2hhT1Y3Hs/vLaW7r6Hzsa2jFEbFwI4F30Ho/3JLDmgfNHCaKJVKbRlJO6bA2Ned6neqig8BaPXMX7WQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2638
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/2Bn15z2T7Soxqys-0QNCAGNe_Ig>
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 10:59:16 -0000

On 09/02/2022 17:36, Jan Lindblad (jlindbla) wrote:
> Tom, Jeff,
>
>>> If an implementation, for whatever reason, couldn't support the items that were covered under the new if-feature, they would have already deviated them away.
>>
>> I do not understand.  The case that concerns me is an implementation written to RFC9127 that knows the rules for backwards compatibility and so knows what it can rely on when a revised module of the same name is found.  Except, AFAICT, it cannot because we are breaking the rules and giving the user little or no help in this I-D to work out why their software no longer works.
>
> I think what Jeff and the BFD team are saying is that there are no such implementations in the real world. As far as I can tell, that may well be true.
>
>> As Jan said, we have not done this before and are in uncharted territory.  I think we should be more helpful.  And the NETMOD WG or the YANG doctors, or both, need to produce guidelines ready for the next time.
>
> This is exactly my point. We're setting a precedence here. Let's do it right. There may be nobody that cares that it's not compatible, but I still prefer that we establish a good template for how to declare breakages of this kind, and then stick to it. At least until the YANG Rev DT publishes revised rules and official YANG statements.

Two thoughts.  I can see very little text in the body of this I-D 
explaining what is going on and why.  That is obvious to those that 
track the BFD WG list but we are creating documents for posterity that 
need to make sense in five years time when memories of this have faded 
and there may be no BFD WG.

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).

Tom Petch

> Best Regards,
> /jan
>
>
>>>
>>> An implementation now has the option to not advertise the feature for that case.  It may also perversely choose to continue to apply a deviation.
>>>
>>> No new nodes have been added.  Implementations (however unlikely they were to have been done) for RFC 9127 for these nodes would have already had to have dealt with them.
>>>
>>> -- Jeff
>>>
>>>
>>>> On Feb 7, 2022, at 12:34 PM, t petch <ietfa@btconnect.com> wrote:
>>>>
>>>> On 07/02/2022 15:49, Jan Lindblad (jlindbla) wrote:
>>>>> Mahesh, all,
>>>>>
>>>>> I tend to agree with Tom that the revision description you proposed was a bit terse. What I had in mind was perhaps more along these lines:
>>>>>
>>>>>      description
>>>>>        "This revision is non-backwards-compatible with the previous revision.
>>>>>
>>>>>         This revision adds an if-feature statement for the client configuration parameters.
>>>>>         If a client using the previous YANG revision of this module connects to a
>>>>>         server that implements the current YANG revision of this module, but does
>>>>>         not implement the feature, the client may not function properly.
>>>>>
>>>>>         This change was introduced despite this incompatibility because ...
>>>>>         ...
>>>>>        ";
>>>>>
>>>>> Don't take the text above literally, I only wrote that to give an idea what I had in mind. There isn't much precedence for how IETF documents NBC breakage in YANG modules, so we have to decide upon the right verbiage level here. In the drafts produced by the versioning design team, there will be an annotation to include in cases like this,   rev:non-backwards-compatible;   which will make this rather clear. While waiting for that to be implemented, I'd say we should err on the side of making it a little overly clear, rather than hiding the fact.
>>>>
>>>>
>>>> That is more what I would hope to see.  The key part for me is that fact that an if-feature has been added.  I would have added something like
>>>> 'Consequently, a client that does not support this feature may be unable to retrieve the objects it would expect to be able to.'
>>>> although that may be stating the obvious!
>>>>
>>>> Tom Petch
>>>>
>>>>
>>>>>
>>>>> Best Regards,
>>>>> /jan
>>>>>
>>>>>
>>>>>
>>>>> Thanks first of all for the review.
>>>>>
>>>>> On Feb 3, 2022, at 3:22 AM, Jan Lindblad via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
>>>>>
>>>>> Reviewer: Jan Lindblad
>>>>> Review result: Ready with Issues
>>>>>
>>>>> This is the last call YANG Doctor review of draft-ietf-bfd-rfc9127-bis.
>>>>> Browsing the mail archives, this has been a long story. Realizing that the
>>>>> context of the bis is to fix a particular issue, I have focused only on the
>>>>> diffs from RFC 9127. I feel any additional nitpicks I might find in a complete
>>>>> review would not be welcome at this stage.
>>>>>
>>>>> I have reviewed the diffs, and find them fulfill the desired technical goals.
>>>>> Since this update breaks backwards compatibility as defined in RFC 6020 sec 10
>>>>> and RFC 7950 sec 11, the process for approving this change has been discussed
>>>>> at length. One argument that has been put forward for going ahead is that the
>>>>> previous version of this module was released only a short time ago, so there is
>>>>> no proliferation of impacted systems in the field.
>>>>>
>>>>> Another argument has been that the YANG Versioning Design Team is working on
>>>>> updated backwards compatibility rules. The Ver-DT proposed updates to the
>>>>> compatibility rules would indeed allow a change of this kind under certain
>>>>> conditions. A key condition for allowing such a break with the backwards
>>>>> compatibility is that the module revision history announces this break clearly
>>>>> to all readers. This is not the case in the -01 version of the modules.
>>>>>
>>>>>    revision 2022-01-04 {
>>>>>        description
>>>>>          "Updates to add client configuration parameters feature.";
>>>>>
>>>>> In my YANG Doctor opinion, updating the revision statement to clearly state
>>>>> that this version is not backwards compatible with the previous version is an
>>>>> absolute requirement. I think it would also be fair to module readers to add a
>>>>> few sentences explaining what's going on here.
>>>>>
>>>>> How does this sound?
>>>>>
>>>>> OLD:
>>>>>        "Updates to add client configuration parameters feature.";
>>>>>
>>>>> NEW:
>>>>>        "Updates to add client configuration parameters feature.
>>>>>         This update breaks backward compatability with earlier
>>>>>         version of the model. The new feature prevents up to
>>>>>         three client configuration parameters from being
>>>>>         included, where they were not needed.";
>>>>>
>>>>>
>>>>> I think that you need more than that (for the reader who does not follow the BFD WG).  I think that there needs to be a reference to where the compatability rules are - RFC7950 s.11 - and the nature of the breakage in the language of NETMOD so that readers can judge the impact thereof.
>>>>>
>>>>> Tom Petch
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Mahesh Jethanandani
>>>>> mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>
>>>>>
>>>>>
>>>>
>>>> --
>>>> last-call mailing list
>>>> last-call@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/last-call
>>>
>>> .
>>>
>
> .
>