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

On Thu, Feb 17, 2022 at 1:14 PM SADOVNIKOV, ALEXEI <AS549R@att.com> wrote:

> Andy,
>
>
>
> The errata form specifically describes submission of RFC 2119 keywords:
>
>
>
> > *Technical* – error in the technical content (Note that changes in the
> usage of RFC 2119 keywords are considered technical.)
>
>
>
> So, it is definitively something which is appropriate to raise errata to.
>
>
>
> I have already replied to Randy’s point of sparing usage.
>
>
>
> I continue to see ambiguity in how strong the requirement of ordering of
> XML payload.  However, it sounds like what you saying that there is no
> ambiguity, and the language is strong enough already to be read as if
> “MUST” was in there; did I get it right?  And if I did what is the harm of
> accepting errata?
>
>
>

Yes. The text is unambiguous wrt/ child node ordering options.
Errata should be used when actual errors are found in an RFC.
That is not the case here.

Andy

> Best regards,
>
>
>
> *Alexei Sadovnikov*
>
> Principal System Architect
>
> Business Solutions
>
> AT&T Business
>
>
>
> *AT&T Services, Inc.*
>
> 550 Cochituate Road, Framingham, MA 01701
>
> m  781.249.1516 |  o  781.249.1516 |  *as549r@att.com <as549r@att.com>*
>
>
>
> This e-mail and any files transmitted with it are AT&T property, are
> confidential, and are intended solely for the use of the individual or
> entity to whom this e-mail is addressed. If you are not one of the named
> recipient(s),  or otherwise have reason to believe that you have received
> this message in error, please notify the sender and delete this message
> immediately from your computer. Any other use, retention, dissemination,
> forwarding, printing, or copying of this e-mail is strictly prohibited.
>
>
>
>
>
>
>
> *From: *Andy Bierman <andy@yumaworks.com>
> *Date: *Thursday, February 17, 2022 at 3:12 PM
> *To: *Randy Presuhn <randy_presuhn@alumni.stanford.edu>
> *Cc: *RFC Errata System <rfc-editor@rfc-editor.org>, Martin Bjorklund <
> mbj@tail-f.com>, Warren Kumari <warren@kumari.net>, Robert Wilton <
> rwilton@cisco.com>, Joel Jaeggli <joelja@bogus.com>, Kent Watsen <
> kent+ietf@watsen.net>, Berger Lou <lberger@labn.net>, as549r <
> AS549R@att.com>, NetMod WG <netmod@ietf.org>
> *Subject: *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
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-tBUYkKx$>
>  >
>  > --------------------------------------
>  > 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>
>
>