[netmod] [Technical Errata Reported] RFC7950 (6855)

RFC Errata System <rfc-editor@rfc-editor.org> Thu, 17 February 2022 18:50 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 D61EC3A0F05 for <netmod@ietfa.amsl.com>; Thu, 17 Feb 2022 10:50:40 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=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 2GHbxySVcOFp for <netmod@ietfa.amsl.com>; Thu, 17 Feb 2022 10:50:36 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD32E3A0F41 for <netmod@ietf.org>; Thu, 17 Feb 2022 10:50:35 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 499) id 13A2F4C1D9; Thu, 17 Feb 2022 10:50:35 -0800 (PST)
To: mbj@tail-f.com, warren@kumari.net, rwilton@cisco.com, joelja@bogus.com, kent+ietf@watsen.net, lberger@labn.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: as549r@att.com, netmod@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220217185035.13A2F4C1D9@rfc-editor.org>
Date: Thu, 17 Feb 2022 10:50:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FrFftJKs2kdreFo5NeuewPlidmw>
Subject: [netmod] [Technical Errata Reported] RFC7950 (6855)
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 Feb 2022 18:50:41 -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/eid6855

--------------------------------------
Type: Technical
Reported by: Alexei Sadovnikov <as549r@att.com>

Section: GLOBAL

Original Text
-------------
7.5.  The "container" Statement
7.5.7.  XML Encoding Rules

   A container node is encoded as an XML element.  The element's local
   name is the container's identifier, and its namespace is the module's
   XML namespace (see Section 7.1.3).

   The container's child nodes are encoded as subelements to the
   container element.  If the container defines RPC or action input or
   output parameters, these subelements are encoded in the same order as
   they are defined within the "container" statement.  Otherwise, the
   subelements are encoded in any order.

7.8. The "list" Statement
7.8.5.  XML Encoding Rules

   The list's key nodes are encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC or action
   input or output parameters, the subelements are encoded in the same
   order as they are defined within the "list" statement.  Otherwise,
   the subelements are encoded in any order.
   . . . . .

7.14.  The "rpc" Statement
7.14.4.  NETCONF XML Encoding Rules

   . . . . .

   Input parameters are encoded as child XML elements to the rpc node's
   XML element, in the same order as they are defined within the "input"
   statement.

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they are encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.


7.15.  The "action" Statement
7.15.2.  NETCONF XML Encoding Rules

   . . . . .

   The <action> element contains a hierarchy of nodes that identifies
   the node in the datastore.  It MUST contain all containers and list
   nodes in the direct path from the top level down to the list or
   container containing the action.  For lists, all key leafs MUST also
   be included.  The innermost container or list contains an XML element
   that carries the name of the defined action.  Within this element,
   the input parameters are encoded as child XML elements, in the same
   order as they are defined within the "input" statement.

   . . . . .

   If the action operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they are encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.


Corrected Text
--------------
7.5.  The "container" Statement
7.5.7.  XML Encoding Rules

   . . . . .

   The container's child nodes are encoded as subelements to the
   container element.  If the container defines RPC or action input or
   output parameters, these subelements MUST be encoded in the same order as
   they are defined within the "container" statement.  Otherwise, the
   subelements are encoded in any order.

7.8. The "list" Statement
7.8.5.  XML Encoding Rules

   The list's key nodes MUST be encoded as subelements to the list's
   identifier element, in the same order as they are defined within the
   "key" statement.

   The rest of the list's child nodes are encoded as subelements to the
   list element, after the keys.  If the list defines RPC or action
   input or output parameters, the subelements MUST be encoded in the same
   order as they are defined within the "list" statement.  Otherwise,
   the subelements are encoded in any order.
   . . . . .

7.14.  The "rpc" Statement
7.14.4.  NETCONF XML Encoding Rules

   . . . . .

   Input parameters MUST be encoded as child XML elements to the rpc node's
   XML element, in the same order as they are defined within the "input"
   statement.

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they MUST be encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.


7.15.  The "action" Statement
7.15.2.  NETCONF XML Encoding Rules

   . . . . .

   The <action> element contains a hierarchy of nodes that identifies
   the node in the datastore.  It MUST contain all containers and list
   nodes in the direct path from the top level down to the list or
   container containing the action.  For lists, all key leafs MUST also
   be included.  The innermost container or list contains an XML element
   that carries the name of the defined action.  Within this element,
   the input parameters MUST be encoded as child XML elements, in the same
   order as they are defined within the "input" statement.

   . . . . .

   If the action operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].  If output parameters are returned, they MUST be encoded as
   child elements to the <rpc-reply> element defined in [RFC6241], in
   the same order as they are defined within the "output" statement.

Notes
-----
The RFC 2119 keywords are missing in description of ordering for XML encoding rules for RPC, actions and references thereto and in additional instance of list keys encoding.

Although the text of RFC suggests reading this as if "MUST" was present, without keyword it is open to interpretation if the sentences actually mean "MUST" or "SHOULD" or may be even "MAY".

In other places discussing ordering, for example 7.7.8., 7.8.5. and 7.9.5. the "MUST" is actually present, hence proposed errata would make ordering description usage of keywords consistent.

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