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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 10 February 2022 23:18 UTC

Return-Path: <mjethanandani@gmail.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 8E98B3A0DD8; Thu, 10 Feb 2022 15:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=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 (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 E6m-82giloCf; Thu, 10 Feb 2022 15:17:58 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 85D233A0DB4; Thu, 10 Feb 2022 15:17:58 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id q8so7723220oiw.7; Thu, 10 Feb 2022 15:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=fEmNSpLO4ks40NSmATXHL7EY671f802zQ5AmpT0wRgE=; b=odT5MVb2aWhPJ79ss24VPL4PRyECbe080LQ1hBfwLL/HMAv2t73O+3XgAYF0eUfR0V rqmnT5r2ktwaiDG0+x8WFsIOnLaWQl0B0KDmv9iS796c2X6ax8KyzEnM+88W50E9tB3X c1Up1jrAVWhiVQGHVQCyFd5dJx19QDsVSu0QiJYZ4AMpr28mqNp0Rud9VJMdvoYTI955 dQjQtg6Ypvor8wbtptroDGBKWSjRo609RKkwaYucGu0Hbcj2pkoAXfCaczu2+U4N8/BY BBcOUXhZvbZsILmjtMbcPDpJiRKvsMQXP3VKoPVN4US6S8AJU0DtvD8vJPIlsyFEY3N2 yxfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=fEmNSpLO4ks40NSmATXHL7EY671f802zQ5AmpT0wRgE=; b=KJdNgOkhlkVNjgBZHFodSyNVWht2n15Q75dNgKPyzQAKPmW+ewGJmKNgazrYyLHndq /6OLP4wJsl7i1cJyUcMb537NPqkL6T94JuzJbGHuxVVxYuagdKcXdV1dECsk+k/WZVSJ 8ixL/f/vmMT+wjCMkCRC6v3eSUXLk9kZiQ5bfw0tC4wX/mGuiK8zv0JdgfISlCCb9/kd y532sz0wOxf/DU8uwHmIDUqMUu/LONh8wxxH1na8Pdfqy/OsyxgVpQublfjTW6ZWkvwg F7CrYokC5/yoSyxwMIOtpXOnUDgERJt4rCBGSafMJIjctrkl4ez72HZsWG/ShSjkyLbk 71zA==
X-Gm-Message-State: AOAM530YlEQgnIhbstfvKa3Je30EIXZtUvYX7kSJ+1DJYUdeRAeY7hrc wleZ5uWJGDk0uiaAjz5EVOU=
X-Google-Smtp-Source: ABdhPJwTTAbqNX9r3rM0mXyIC3E7ONCtVzJtTAO9ofOPDaV6mzrcNbfsl8RANghcObSe9O2apaWc9w==
X-Received: by 2002:a05:6808:1a86:: with SMTP id bm6mr2022421oib.182.1644535074800; Thu, 10 Feb 2022 15:17:54 -0800 (PST)
Received: from smtpclient.apple (adsl-70-234-233-187.dsl.rcsntx.sbcglobal.net. [70.234.233.187]) by smtp.gmail.com with ESMTPSA id bj8sm9183879oib.20.2022.02.10.15.17.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Feb 2022 15:17:54 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <B0B97325-6200-4B04-8D72-911883A615B2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_87EF5367-00BD-4E09-B971-73E16A7EA987"
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
Date: Thu, 10 Feb 2022 15:17:52 -0800
In-Reply-To: <22A163B4-F2B0-48EF-8334-AD234F886327@cisco.com>
Cc: tom petch <daedulus@btconnect.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>
To: Jan Lindblad <jlindbla@cisco.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>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/mgyep-8WW2-P61RYmQ35UA9t3xI>
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 23:18:04 -0000

Hi Jan,

How about this?

OLD:
      This revision is non-backwards-compatible with the previous revision.

NEW:
       This revision is non-backwards compatible with the
       previous version of this model.

       This revision adds an 'if-feature' statement called 
       'client-base-cfg-parms' for client configuration parameters.
       Clients expecting to use those parameters now need to
       declare the feature to include them.

       The change was introduced for clients that do not need
       them, and have to deviate to prevent them from being
       included.



> On Feb 7, 2022, at 7:49 AM, Jan Lindblad (jlindbla) <jlindbla@cisco.com> 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.
> 
> 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>


Mahesh Jethanandani
mjethanandani@gmail.com