[netmod] [Errata Rejected] RFC7950 (6885)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 17 March 2022 10:10 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 0A5473A0029; Thu, 17 Mar 2022 03:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 6GWszjvhsO5E; Thu, 17 Mar 2022 03:10:25 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB4A3A1080; Thu, 17 Mar 2022 03:10:24 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 499) id 19F87120A4F; Thu, 17 Mar 2022 03:10:24 -0700 (PDT)
To: kaja.mohideen@nokia.com, mbj@tail-f.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: rwilton@cisco.com, iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220317101024.19F87120A4F@rfc-editor.org>
Date: Thu, 17 Mar 2022 03:10:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6JSWQ4sMm5hiCLaTSWqAtJ23HfY>
Subject: [netmod] [Errata Rejected] RFC7950 (6885)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Mar 2022 10:10:31 -0000

The following errata report has been rejected for RFC7950,
"The YANG 1.1 Data Modeling Language".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6885

--------------------------------------
Status: Rejected
Type: Technical

Reported by: R Kaja Mohideen <kaja.mohideen@nokia.com>
Date Reported: 2022-03-16
Rejected by: Rob Wilton (IESG)

Section: 11

Original Text
-------------
   A definition in a published module may be revised in any of the
   following ways:

   o  An "enumeration" type may have new enums added, provided the old
      enums's values do not change.  Note that inserting a new enum
      before an existing enum or reordering existing enums will result
      in new values for the existing enums, unless they have explicit
      values assigned to them.

   o  A "bits" type may have new bits added, provided the old bit
      positions do not change.  Note that inserting a new bit before an
      existing bit or reordering existing bits will result in new
      positions for the existing bits, unless they have explicit
      positions assigned to them.

Corrected Text
--------------
See Notes.

Notes
-----
When server is exposing updated yang model as mentioned in Section 11, particularly with enums, bits having new items - client systems that are not updated to use the new yang module will not be able to recognize and use the new values.

This is problematic when there are multiple clients and those systems are getting updated to catch up with yang changes over time. Updated "Client A" recognizing new enum and using it (update datastore with new value using edit-config), will make, old/not-yet-updated "Client B" to encounter the new value (received as response of get-config) that it cannot work with.

So, the "backward compatible" ways of updating a yang module should consider "multiple clients" scenario and make recommendations in such a way that clients are not forced to update all at once.
 --VERIFIER NOTES-- 
The document text accurately represents the consensus of the WG at the time that it was published.  Hence, this errata is beyond the scope of what changes could be considered as part of the errata process, such a change would need to happen via a new or updated RFC.

--------------------------------------
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--------------------------------------
Title               : The YANG 1.1 Data Modeling Language
Publication Date    : August 2016
Author(s)           : M. Bjorklund, Ed.
Category            : PROPOSED STANDARD
Source              : Network Modeling
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG