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

On Thu, Feb 17, 2022 at 11:54 AM Randy Presuhn <
randy_presuhn@alumni.stanford.edu> wrote:

> Hi -
>
> This seems like a remarkably pointless change, and arguably
> at odds with section 6 of RFC 2119. ("Imperatives of the type
> defined in this memo must be used with care and sparingly.")
>
>
+1

IMO RFC 2119 keywords MUST NOT be added, modified, or removed using an
Errata.
In this specific case, there is no ambiguity that needs to be corrected.

> Randy
>

Andy

>
> On 2022-02-17 10:50 AM, 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/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
>  >
>  > _______________________________________________
>  > netmod mailing list
>  > netmod@ietf.org
>  > https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>