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

Martin Bjorklund <mbj@tail-f.com> Mon, 09 September 2019 07:38 UTC

Return-Path: <mbj@tail-f.com>
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 E506D1200CD for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 00:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 N7ewaCfEhwxV for <netmod@ietfa.amsl.com>; Mon, 9 Sep 2019 00:38:26 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 551A3120121 for <netmod@ietf.org>; Mon, 9 Sep 2019 00:38:26 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 436651AE0118; Mon, 9 Sep 2019 09:38:25 +0200 (CEST)
Date: Mon, 09 Sep 2019 09:38:01 +0200
Message-Id: <20190909.093801.653761409423593292.mbj@tail-f.com>
To: warren@kumari.net
Cc: ibagdona@gmail.com, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net, jernej.tuljak@mg-soft.si, netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CAHw9_iKvbmpEM8KGgnGtwG02c5vuCSbF2-JvBvD5XKqGWXRuPA@mail.gmail.com>
References: <20190813112613.82CE8B80E16@rfc-editor.org> <CAHw9_iKvbmpEM8KGgnGtwG02c5vuCSbF2-JvBvD5XKqGWXRuPA@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/dOhzRjBlDtQk84VN1WPlcAZer6Y>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5807)
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: Mon, 09 Sep 2019 07:38:29 -0000

Warren Kumari <warren@kumari.net> wrote:
> [ - RFC Ed (for clutter), + Benoit (who verified
> https://www.rfc-editor.org/errata/eid4794) ]
> 
> I'm trying to go through and clean up the outstanding Ops and
> Management Errata. I'm completely, 100% not a YANG / netmod person (I
> cannot even spell YANG!), but I *think* that this Errata should be
> verified, yes? This isn't changing what was decided when the WG
> published this, it is simply correcting / clarifying the text.

Yes I agree it should be verified.


/martin


> 
> The Errata criteria are here:
> https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> One of the big ones is that we only use Errata to fix actual errors,
> not change anything that was WG consensus at the time:
> "Changes that modify the working of a protocol to something that might
> be different from the intended consensus when the document was
> approved should be either Hold for Document Update or Rejected.
> Deciding between these two depends on judgment. Changes that are
> clearly modifications to the intended consensus, or involve large
> textual changes, should be Rejected. In unclear situations, small
> changes can be Hold for Document Update."
> 
> Again, I'm not a NetMod person, so looking for clear advice here...
> 
> W
> 
> On Tue, Aug 13, 2019 at 7:26 AM RFC Errata System
> <rfc-editor@rfc-editor.org> 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/eid5807
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Jernej Tuljak <jernej.tuljak@mg-soft.si>
> >
> > Section: 7.21.5.
> >
> > Original Text
> > -------------
> >    o  If the "when" statement is a child of a "uses", "choice", or
> >       "case" statement, then the context node is the closest ancestor
> >       node to the node with the "when" statement that is also a data
> >       node.  If no such node exists, the context node is the root node.
> >       The accessible tree is tentatively altered during the processing
> >       of the XPath expression by removing all instances (if any) of the
> >       nodes added by the "uses", "choice", or "case" statement.
> >
> > Corrected Text
> > --------------
> >    o  If the "when" statement is a child of a "uses", "choice", or
> >       "case" statement, then the context node is the closest ancestor
> >       node to the node with the "when" statement that is also a data
> >       node, rpc, action or notification.  If no such node exists, the
> >       context node is the root node. The accessible tree is tentatively
> >       altered during the processing of the XPath expression by removing
> >       all instances (if any) of the nodes added by the "uses",
> >       "choice", or "case" statement.
> >
> > Notes
> > -----
> > Similar to verified errata 4794 (https://www.rfc-editor.org/errata/eid4794) but covers the "uses", "choice" and "case" corner case (instead of "augment"). If the node for which the "when" statement is defined is within an rpc, action or notification, the context node also needs to be inside that rpc, action or notification. There are published IETF modules, which rely on this to be true, such as "ietf-netconf-nmda@2019-01-07" in RFC8526 (https://tools.ietf.org/html/rfc8526) at schema node id "/ncds:get-data/ncds:input/ncds:origin-filters". Original text assigns the context node to the root node, if no data node ancestor is found. "rpc", "action" and "notification" are not data nodes and are represented by nodes that are descendants of the root node, as described in Section 6.4.1.
> >
> > 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
> 
> 
> 
> -- 
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>