Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01

Jan Lindblad via Datatracker <noreply@ietf.org> Thu, 03 February 2022 11:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A47DF3A1213; Thu, 3 Feb 2022 03:22:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jan Lindblad via Datatracker <noreply@ietf.org>
To: yang-doctors@ietf.org
Cc: draft-ietf-bfd-rfc9127-bis.all@ietf.org, last-call@ietf.org, rtg-bfd@ietf.org
Subject: Yangdoctors last call review of draft-ietf-bfd-rfc9127-bis-01
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164388736861.32491.11649774516476095771@ietfa.amsl.com>
Reply-To: Jan Lindblad <janl@tail-f.com>
Date: Thu, 03 Feb 2022 03:22:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/zP-d1ujDwAiPyBfPbKGGfdLtjEY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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, 03 Feb 2022 11:23:00 -0000

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.