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

[Andy Bierman <[e-mail]>]

On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) <
[e-mail]> wrote:

> Hi all,
>
>
>
> There is an interesting consequence of the wording for lists.
>
>
>
> >     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.
>
>
>
> The first paragraph says the key nodes are encoded in the same order as
> the key statement.  But then the 2nd paragraph says the subelements are
> encoded in the order they are defined.  But it isn't super-clear if that
> entire second paragraph only applies to the "rest of the" nodes (i.e. not
> the keys). The last sentence seems to apply to the keys as well (outside of
> an RPC/action input/output).
>
>
>


It seems clear to me that the 2nd paragraph is about the rest of the list's
child nodes.



> I believe it is legal to define a YANG list that has a different order for
> the items in the "key" element than in the definition of the key leafs
> right ?  For example:
>
>
>
> list foo {
>
>     key "key-1 key-2 key-3"
>
>     leaf key-1 { … }
>
>     leaf key-3 { … }
>
>     leaf key-2 { … }
>
>     leaf some-other-leaf-a
>
>     leaf some-other-leaf-b
>
> }
>
> [not that I'd recommend modelling like that]
>
>
>

this is legal and sometimes used.



> Is it clear enough that the encoding order of the subelements matching the
> YANG-order only applies to the elements **besides** the keys ?
>
>
>

yes


> It is interesting that there is a small inconsistency here. Looking purely
> at the order of the leafs won't match the XML encoding for key leafs.
>
>
>
> i.e. maybe some implementations will order the XML this way (doesn't match
> the order of **all** leafs):
>
>                 <key-1>…
>
>                 <key-2>…
>
>                 <key-3>…
>
>                 <some-other-leaf-a>…
>
>                 <some-other-leaf-b>…
>


The text is clear that the keys go first in the order specified in the
key-stmt.



> and might some do this (matches the order of **all** leafs, but then
> contradicts the first paragraph):
>
>                 <key-1>…
>
>                 <key-3>…
>
>                 <key-2>…
>
>                 <some-other-leaf-a>…
>
>                 <some-other-leaf-b>…
>
>
>
> Jason
>
>
>


Andy



> *From:* netmod <[e-mail]> *On Behalf Of *SADOVNIKOV, ALEXEI
> *Sent:* Tuesday, February 22, 2022 11:28 AM
> *To:* Rob Wilton (rwilton) <[e-mail]>; Kent Watsen <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail]; [e-mail]; RFC Errata
> System <[e-mail]>
> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
>
>
> Thank you, Rob.
>
>
>
> 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 |  *[e-mail] <[e-mail]>*
>
>
>
> 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: *"Rob Wilton (rwilton)" <[e-mail]>
> *Date: *Tuesday, February 22, 2022 at 10:21 AM
> *To: *Kent Watsen <[e-mail]>, as549r <[e-mail]>
> *Cc: *RFC Errata System <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, Joel Jaeggli <
> [e-mail]>, Lou Berger <[e-mail]>, Randy Presuhn <
> [e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *RE: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
>
>
> Hi,
>
>
>
> I basically agree with Kent, Randy, Andy.
>
>
>
> Alexi,
>
>
>
> Thanks for flagging this, and the subsequent discussion.
>
>
>
> I can see your point of view that MUST is used in other similar places,
> and I'm sure that in hindsight it would be nice if the language was used
> consistently in equivalent places.
>
>
>
> However, I don't think that the lack of a MUST statement makes the other
> text any less normative, or ambiguous.  In particular, there is this
> paragraph of RFC 8174 that updates RFC 2119:
>
>
>
>    o  These words can be used as defined here, but using them is not
>
>       required.  Specifically, normative text does not require the use
>
>       of these key words.  They are used for clarity and consistency
>
>       when that is what's wanted, but a lot of normative text does not
>
>       use them and is still normative.
>
>
>
> Hence, I have rejected this errata.  If you find the current text to be
> confusing and think that it would be helpful to clarify this is a future
> version of this specification, then I would suggest that you open an issue
> here (
> https://urldefense.com/v3/__https://github.com/netmod-wg/yang-next/issues__;!!BhdT!nBhCe6YCJpOtCnmFwZ1oBRjxufTDTet131D2wG3sxyq6mSUshsyDWQzcIrvGvVlRg4l8NnqjPk8x$
> <https://urldefense.com/v3/__https:/github.com/netmod-wg/yang-next/issues__;!!BhdT!nBhCe6YCJpOtCnmFwZ1oBRjxufTDTet131D2wG3sxyq6mSUshsyDWQzcIrvGvVlRg4l8NnqjPk8x$>
> ), and it will get evaluated when we get to revising YANG.
>
>
>
> Regards,
>
> Rob
>
>
>
>
>
> -----Original Message-----
>
> From: Kent Watsen <[e-mail]>
>
> Sent: 22 February 2022 15:05
>
> To: Rob Wilton (rwilton) <[e-mail]>
>
> Cc: SADOVNIKOV, ALEXEI <[e-mail]>; RFC Errata System <
> [e-mail]>; [e-mail]; [e-mail]; Joel
> Jaeggli <[e-mail]>; Lou Berger <[e-mail]>; Randy Presuhn <
> [e-mail]>; [e-mail]
>
> Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
>
>
> Move to close this Errata without accepting it.
>
>
>
> Kent  // as co-chair
>
>
>
>
>
>
>
> On Feb 17, 2022, at 5:53 PM, Randy Presuhn <
> [e-mail]> wrote:
>
>
>
> Hi -
>
>
>
> On 2022-02-17 1:01 PM, SADOVNIKOV, ALEXEI wrote:
>
> Randy,
>
> I definitively see that point, and the line of sparing usage can be
> somewhat subjective.
>
> In this case, I think use of “MUST” is justified RFC 2119 “actually
> required for interoperation or to limit behavior which has potential for
> causing harm”.
>
> Missing “MUST” statement does leave it open for interpretation, and
>
>
>
> That is simply not true.  The existing text, e.g. "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"  leaves no room whatsoever for interpretation.
>
>
>
> misinterpretation will result in harm – XML payload which encapsulated
> without following these ordering rule can be rejected during decapsulation
> which does follow the rule.  The XML payload is exchanged between client
> and server, often different implementations, hence different interpretation
> by different developers will lead to communication failure.
>
>
>
> The existing text is unambiguous, and provides no options in ordering.
>
>
>
> As such, I do not see how proposed errata is at odds with sparing usage
> provision, when it meets the described reason for usage.
>
> In other sections of this RFC (7.7.8., 7.8.5. and 7.9.5) “MUST” already
> used for same purpose; it is difficult to see how it is any more important
> in where ‘MUST’ is used vs to where it is not.
>
> Having said all that, the suggested errata can be reduced to exclude
> section 7.5.7 and second paragraph of 7.8.5 – in both of this cases the
> exact meaning can be referred from section 7.14.4 (as long as “MUST” is
> present in there).  Would that resolve your concern of sparing usage?
>
>
>
> Such text-diddling seems utterly pointless to me.
>
>
>
> Randy
>
>
>
> --------------------
>
> 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 | [e-mail] <
> mailto:[e-mail]>_ <[e-mail]%3e_>
>
> 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: *Randy Presuhn <[e-mail]>
>
> *Date: *Thursday, February 17, 2022 at 2:55 PM
>
> *To: *RFC Errata System <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>
>
> *Cc: *as549r <[e-mail]>, "[e-mail]" <[e-mail]>
>
> *Subject: *Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
> 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://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6855__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpDMmnMUI4$
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpDMmnMUI4$>
> <
> https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpDMmnMUI4$
> >  >
>
> > --------------------------------------
>
> > Type: Technical
>
> > Reported by: Alexei Sadovnikov <[e-mail] <mailto:[e-mail]>
> <[e-mail]%3e>>
>
> >
>
> > 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] <mailto:[e-mail] <[e-mail]>>
>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$>
> <
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>