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

[Andy Bierman <[e-mail]>]

On Mon, Feb 28, 2022 at 10:53 AM Jürgen Schönwälder <
[e-mail]> wrote:

> RFC 7950 defines the ordering rules for the XML serialization of YANG
> data (and it does not really matter what other uses of XML require). A
> rough summary is that XML serializations of data trees are generally
> unordered except that elements representing lists have to follow the
> list ordering rules and that keys of list elements come first and in
> the order they keys are defined.
>
>
- ordered-by user
- rpc input
- rpc output
- action input
- action output


A lot of text in RFC 7950 about it.


/js
>
> On Mon, Feb 28, 2022 at 06:42:56PM +0000, Sterne, Jason (Nokia -
> CA/Ottawa) wrote:
> > Thx.  I probably went too far in my statement about XML documents being
> unordered. But isn't it true that for YANG modelled data, the order of the
> XML *shouldn't* matter ?  It should ideally be processed atomically (i.e.
> after being fully processed/loaded it should be non-ambiguous if you
> assumed every statement was applied at the same instant) ?
> >
> > Some examples:
> > - a YANG container shouldn't appear twice in a single edit-config (i.e.
> shouldn't re-enter a container in the same edit)
> > - a delete of a leaf, and a modification of a value of that leaf,
> shouldn't be in the same edit-config  (i.e. don't just rely on the order of
> the XML to resolve that ambiguity).
> >
> > Jason
> >
> > From: SADOVNIKOV, ALEXEI <[e-mail]>
> > Sent: Friday, February 25, 2022 4:15 PM
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>; Rob
> Wilton (rwilton) <[e-mail]>; Andy Bierman <[e-mail]>
> > Cc: Kent Watsen <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; RFC Errata System <
> [e-mail]>
> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
> >
> > Jason,
> >
> > XML is definitively ordered, e.g. elements flow in a document order, and
> two XML documents with different order of elements are not equivalent.  In
> contrast, same order does not exist in JSON.
> >
> > It is very different discussion if ordering of XML is helpful,
> especially in presence of non-ordered JSON.  IMO the ordering of XML was
> never helpful to begin with, except to internals of some implementations,
> and if implementation is extended to support JSON encoding, the XML
> ordering is an overhead exercise of RFC 7950 compliance, with not much of
> other benefit.
> >
> > 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: "Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]
> <mailto:[e-mail]>>
> > Date: Friday, February 25, 2022 at 1:30 PM
> > To: "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>>,
> Andy Bierman <[e-mail]<mailto:[e-mail]>>
> > Cc: as549r <[e-mail]<mailto:[e-mail]>>, Kent Watsen <
> [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]>>, RFC Errata System <
> [e-mail]<mailto:[e-mail]>>
> > Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)
> >
> > Thx for the note about JSON IETF.
> >
> > I had generally thought of XML documents as also being "fundamentally
> unordered collections of members" as well but I must admit I'm not an
> expert in the subtleties of XML.
> >
> > Jason
> >
> > From: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>
> > Sent: Friday, February 25, 2022 1:20 PM
> > To: Andy Bierman <[e-mail]<mailto:[e-mail]>>;
> Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]<mailto:
> [e-mail]>>
> > Cc: SADOVNIKOV, ALEXEI <[e-mail]<mailto:[e-mail]>>; Kent
> Watsen <[e-mail]<mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; RFC Errata System <
> [e-mail]<mailto:[e-mail]>>
> > Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)
> >
> > // As a contributor
> >
> > I agree with Andy, and personally, I’ve never found this text to be
> confusing.
> >
> > Note, if encoded as JSON, then as per RFC 7951 section 5.4, the list
> elements can be in any order, because JSON objects are unordered.
> Although, I would probably still return the keys first, even if the client
> is not allowed to rely on them being first/ordered.
> >
> > Rob
> >
> >
> >
> > From: Andy Bierman <[e-mail]<mailto:[e-mail]>>
> > Sent: 25 February 2022 16:39
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]<mailto:
> [e-mail]>>
> > Cc: SADOVNIKOV, ALEXEI <[e-mail]<mailto:[e-mail]>>; Rob
> Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; Kent
> Watsen <[e-mail]<mailto:[e-mail]>>; [e-mail]
> <mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; RFC Errata System <
> [e-mail]<mailto:[e-mail]>>
> > Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
> >
> >
> >
> > On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) <
> [e-mail]<mailto:[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]<mailto:[e-mail]>>
> On Behalf Of SADOVNIKOV, ALEXEI
> > Sent: Tuesday, February 22, 2022 11:28 AM
> > To: Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>;
> Kent Watsen <[e-mail]<mailto:[e-mail]>>
> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:
> [e-mail]>; [e-mail]<mailto:[e-mail]>; RFC Errata
> System <[e-mail]<mailto:[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$
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/netmod<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$
> >
>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
>
> --
> Jürgen Schönwälder              Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
>