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

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

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

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]

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

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>…
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

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]<mailto:[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]<mailto:[e-mail]>>
Date: Tuesday, February 22, 2022 at 10:21 AM
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>, as549r <[e-mail]<mailto:[e-mail]>>
Cc: RFC Errata System <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Joel Jaeggli <[e-mail]<mailto:[e-mail]>>, Lou Berger <[e-mail]<mailto:[e-mail]>>, Randy Presuhn <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
Cc: SADOVNIKOV, ALEXEI <[e-mail]<mailto:[e-mail]>>; RFC Errata System <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Joel Jaeggli <[e-mail]<mailto:[e-mail]>>; Lou Berger <[e-mail]<mailto:[e-mail]>>; Randy Presuhn <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[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]> <mailto:[e-mail]>_<mailto:[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]<mailto:[e-mail]>>
*Date: *Thursday, February 17, 2022 at 2:55 PM
*To: *RFC Errata System <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
*Cc: *as549r <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]> <mailto:[e-mail]><mailto:[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]> <mailto:[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$>