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

[Randy Presuhn <[e-mail]>]

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.")

Randy

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 <[e-mail]>
 >
 > 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
 > [e-mail]
 > https://www.ietf.org/mailman/listinfo/netmod