Re: [netmod] [Technical Errata Reported] RFC7950 (6885)

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Wed, 16 March 2022 20:43 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
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 E68DD3A0E64 for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2022 13:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 08dEH8CK5IR9 for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2022 13:43:54 -0700 (PDT)
Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (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 8A2E33A0E67 for <netmod@ietf.org>; Wed, 16 Mar 2022 13:43:54 -0700 (PDT)
Received: by mail-pf1-f182.google.com with SMTP id a5so5099075pfv.2 for <netmod@ietf.org>; Wed, 16 Mar 2022 13:43:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=5qHbyrSveT6rZTGYXlzSQi+NxEU1206CrcApTmozDDg=; b=COB52qUTGbqZt7GTsc1Rkr9TuK8VsPTbfYUgbrGaP3VaTrf6Nttr49VNVQ9JEuwNzW MOpFQAuDAVoyy5QGE4nCL5RjBluF8kEl/x5Kn3pAmDhwjSc5j5GIB0YF7v+kyrekapWC HrJZ5aV1muKD+1Q2Phuxh3YCya4OYbh7djY3o3HrOC1Z2u9rxaN80L+N43SAKjzKgkmi gZQmXb0WGUMDn/UP1oU45pFRnaozDrhknZgXasKMe9Mx4GDUTguJtjsT22e78aNq19GX mikCocb+SEdbWRcn/+h5IcTpaY33FIaFPG1mZVz6nedOHd8ti8vhzUgDmB9U5UZ3QCQU Dmjw==
X-Gm-Message-State: AOAM533eC7vGfI+07UeQVP7Ggu3cVkYqA86yzvZpfvW5mBvLRy9irej5 Ng8WDI4RIYGw2JzSKd3Ktus82g==
X-Google-Smtp-Source: ABdhPJz/Ppv4lJ536MRc9lMPlh6JmXcTGRJ5gGSWgZWVvqzIKLZnJBhqyyJ60b6kTvs01PH0AQBBJA==
X-Received: by 2002:a63:e243:0:b0:381:6a51:145f with SMTP id y3-20020a63e243000000b003816a51145fmr1017814pgj.625.1647463433879; Wed, 16 Mar 2022 13:43:53 -0700 (PDT)
Received: from ?IPV6:2601:646:9300:607:a093:9940:7d76:a176? ([2601:646:9300:607:a093:9940:7d76:a176]) by smtp.gmail.com with ESMTPSA id k14-20020aa7972e000000b004f7b8b43d96sm3955674pfg.51.2022.03.16.13.43.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Mar 2022 13:43:53 -0700 (PDT)
Message-ID: <4d482f9a-21be-b389-688a-85cfe739371f@alumni.stanford.edu>
Date: Wed, 16 Mar 2022 13:43:53 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: RFC Errata System <rfc-editor@rfc-editor.org>, mbj@tail-f.com, warren@kumari.net, rwilton@cisco.com, kent+ietf@watsen.net, joelja@bogus.com, lberger@labn.net, kaja.mohideen@nokia.com, netmod@ietf.org
References: <20220316052112.9F47A20D6AD@rfc-editor.org> <20220316061327.ce7mtqwhrk772fjw@anna>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
In-Reply-To: <20220316061327.ce7mtqwhrk772fjw@anna>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/L42tAYQ8QgE3__br6qDHbktC-30>
Subject: Re: [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 20:43:59 -0000

Hi -

On 2022-03-15 11:13 PM, Jürgen Schönwälder wrote:
> YANG update rules expect clients to be lenient about values they
> received but did not expect. It is possible to debate that design
> choice but this surely is not an errata, hence this errata should
> be rejected.

I agree that the proposed erratum should be rejected.  The text
of RFC 7950 says what the working group clearly intended, and is
consistent with the approach taken in the SNMP SMI, for whatever
that might be worth.

Randy

> /js
> 
> On Tue, Mar 15, 2022 at 10:21:12PM -0700, RFC Errata System wrote:
>> 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 mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>