[netmod] [Technical Errata Reported] RFC7950 (6885)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 16 March 2022 05:21 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 5A6633A0E4C for <netmod@ietfa.amsl.com>; Tue, 15 Mar 2022 22:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ReB4LiNu1MBt for <netmod@ietfa.amsl.com>; Tue, 15 Mar 2022 22:21:12 -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 B5EE13A0E27 for <netmod@ietf.org>; Tue, 15 Mar 2022 22:21:12 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 499) id 9F47A20D6AD; Tue, 15 Mar 2022 22:21:12 -0700 (PDT)
To: mbj@tail-f.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, joelja@bogus.com, lberger@labn.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: kaja.mohideen@nokia.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220316052112.9F47A20D6AD@rfc-editor.org>
Date: Tue, 15 Mar 2022 22:21:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/u6-39vj8YuwKXsT3W9zxcc97ypY>
Subject: [netmod] [Technical Errata Reported] 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: Wed, 16 Mar 2022 05:21:18 -0000
The following errata report has been submitted for RFC7950, "The YANG 1.1 Data Modeling Language". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6885 -------------------------------------- Type: Technical Reported by: R Kaja Mohideen <kaja.mohideen@nokia.com> 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- 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
- [netmod] [Technical Errata Reported] RFC7950 (688… RFC Errata System
- Re: [netmod] [Technical Errata Reported] RFC7950 … Jürgen Schönwälder
- Re: [netmod] [Technical Errata Reported] RFC7950 … Randy Presuhn
- Re: [netmod] [Technical Errata Reported] RFC7950 … Rob Wilton (rwilton)
- Re: [netmod] [Technical Errata Reported] RFC7950 … Andy Bierman
- Re: [netmod] [Technical Errata Reported] RFC7950 … Mohideen, Kaja (Nokia - IN/Chennai)
- Re: [netmod] [Technical Errata Reported] RFC7950 … Jürgen Schönwälder
- Re: [netmod] [Technical Errata Reported] RFC7950 … Mohideen, Kaja (Nokia - IN/Chennai)
- Re: [netmod] [Technical Errata Reported] RFC7950 … Jürgen Schönwälder
- Re: [netmod] [Technical Errata Reported] RFC7950 … Carsten Bormann
- Re: [netmod] [Technical Errata Reported] RFC7950 … Jürgen Schönwälder