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

From: RFC Errata System <[email-masked]>
Date: Thu, 17 Feb 2022 10:50:35 -0800 (PST)

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 <[email-masked]>

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

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 17 Feb 2022 11:54:32 -0800

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 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.
 > _______________________________________________
 > netmod mailing list
 > [email-masked]
 > https://www.ietf.org/mailman/listinfo/netmod

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 17 Feb 2022 14:53:18 -0800

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 | [email-masked] 
> <mailto:[email-masked]>_
> 
> 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 <[email-masked]>
> *Date: *Thursday, February 17, 2022 at 2:55 PM
> *To: *RFC Errata System <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Cc: *as549r <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
> 
> Hi -
> 
> 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$> 
> 
> 
>  >
> 
>  > Reported by: Alexei Sadovnikov <[email-masked] <mailto:[email-masked]>>
> 
>  >
> 
>  > Section: GLOBAL
> 
>  >
> 
>  > Original Text
> 
>  > -------------
> 
>  >     output parameters, these subelements MUST be encoded in the same
> 
> order as
> 
>  >     input or output parameters, the subelements MUST be encoded in
> 
> the same
> 
>  >     Input parameters MUST be encoded as child XML elements to the rpc
> 
> node's
> 
>  >     in [RFC6241].  If output parameters are returned, they MUST be
> 
> encoded as
> 
>  >     the input parameters MUST be encoded as child XML elements, in
> 
> the same
> 
>  >     in [RFC6241].  If output parameters are returned, they MUST be
> 
> encoded as
> 
>  > [email-masked] <mailto:[email-masked]>
> 
>  > 
> 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$> 
> 
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Feb 2022 15:05:18 +0000

Move to close this Errata without accepting it.

Kent  // as co-chair

> On Feb 17, 2022, at 5:53 PM, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
>> 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”.
>> 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.
> 
>> 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?
> 
>> m  781.249.1516 |  o  781.249.1516 | [email-masked] <mailto:[email-masked]>_
>> 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.
>> *To: *RFC Errata System <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> > 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.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 22 Feb 2022 15:20:06 +0000

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://github.com/netmod-wg/yang-next/issues), and it will get evaluated when we get to revising YANG.

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]> 
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]>
Cc: SADOVNIKOV, ALEXEI <[email-masked]>; RFC Errata System <[email-masked]>; [email-masked]; [email-masked]; Joel Jaeggli <[email-masked]>; Lou Berger <[email-masked]>; Randy Presuhn <[email-masked]>; [email-masked]
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Feb 2022 12:11:41 -0800

> 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

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Thu, 17 Feb 2022 21:01:39 +0000

Randy,

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

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.
550 Cochituate Road, Framingham, MA 01701
m  781.249.1516 |  o  781.249.1516 |  [email-masked]<mailto:[email-masked]>

From: Randy Presuhn <[email-masked]>
Date: Thursday, February 17, 2022 at 2:55 PM
To: RFC Errata System <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: as549r <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Hi -

Randy

On 2022-02-17 10:50 AM, RFC Errata System wrote:
> 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$>
>
> Reported by: Alexei Sadovnikov <[email-masked]<mailto:[email-masked]>>
>
> Section: GLOBAL
>
> Original Text
> -------------
order as
the same
node's
encoded as
the same
encoded as
> [email-masked]<mailto:[email-masked]>
> 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$>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 17 Feb 2022 13:30:35 -0800

On Thu, Feb 17, 2022 at 1:14 PM SADOVNIKOV, ALEXEI <[email-masked]> 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

> m  781.249.1516 |  o  781.249.1516 |  [email-masked] <[email-masked]>*
>
>
>
> 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 <[email-masked]>
> *Date: *Thursday, February 17, 2022 at 3:12 PM
> *To: *Randy Presuhn <[email-masked]>
> *Cc: *RFC Errata System <[email-masked]>, Martin Bjorklund <
> [email-masked]>, Warren Kumari <[email-masked]>, Robert Wilton <
> [email-masked]>, Joel Jaeggli <[email-masked]>, Kent Watsen <
> [email-masked]>, Berger Lou <[email-masked]>, as549r <
> [email-masked]>, NetMod WG <[email-masked]>
> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-tBUYkKx$>
>  >
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>
>
>

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Thu, 17 Feb 2022 21:13:31 +0000

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

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?

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: Andy Bierman <[email-masked]>
Date: Thursday, February 17, 2022 at 3:12 PM
To: Randy Presuhn <[email-masked]>
Cc: RFC Errata System <[email-masked]>, Martin Bjorklund <[email-masked]>, Warren Kumari <[email-masked]>, Robert Wilton <[email-masked]>, Joel Jaeggli <[email-masked]>, Kent Watsen <[email-masked]>, Berger Lou <[email-masked]>, as549r <[email-masked]>, NetMod WG <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

On Thu, Feb 17, 2022 at 11:54 AM Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:
Hi -

+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:
 > https://www.rfc-editor.org/errata/eid6855<https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-tBUYkKx$>
 >
order as
the same
node's
encoded as
the same
encoded as
 > 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kg4Z09cDAiOCMC1v8w414i_onQ4uOiwReagIknKnigDUfb-j-wmKvnE0qxdFOS3uwmvd-jLkdqxS$>

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Tue, 22 Feb 2022 16:27:53 +0000

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tuesday, February 22, 2022 at 10:21 AM
To: Kent Watsen <[email-masked]>, as549r <[email-masked]>
Cc: RFC Errata System <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Joel Jaeggli <[email-masked]>, Lou Berger <[email-masked]>, Randy Presuhn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

Hi,

Alexi,

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 <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

On Feb 17, 2022, at 5:53 PM, Randy Presuhn <[email-masked]<mailto:[email-masked]>> wrote:

Hi -

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 | [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>_<mailto:[email-masked]%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 <[email-masked]<mailto:[email-masked]>>
*Date: *Thursday, February 17, 2022 at 2:55 PM
*To: *RFC Errata System <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
*Cc: *as549r <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
*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:
> 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$>  >
> Reported by: Alexei Sadovnikov <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]><mailto:[email-masked]%3e>>
>
> Section: GLOBAL
>
> Original Text
> -------------
order as
the same
node's
encoded as
the same
encoded as
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
> 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$>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Feb 2022 16:20:45 +0000

Hi all,

There is an interesting consequence of the wording for lists.

>     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 <[email-masked]> On Behalf Of SADOVNIKOV, ALEXEI
Sent: Tuesday, February 22, 2022 11:28 AM
To: Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; RFC Errata System <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 22, 2022 at 10:21 AM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>, as549r <[email-masked]<mailto:[email-masked]>>
Cc: RFC Errata System <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Joel Jaeggli <[email-masked]<mailto:[email-masked]>>, Lou Berger <[email-masked]<mailto:[email-masked]>>, Randy Presuhn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

---

From: Andy Bierman <[email-masked]>
Date: Fri, 25 Feb 2022 08:39:18 -0800

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

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

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 <[email-masked]> *On Behalf Of *SADOVNIKOV, ALEXEI
> *Sent:* Tuesday, February 22, 2022 11:28 AM
> *To:* Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <
> [email-masked]>
> *Cc:* [email-masked]; [email-masked]; [email-masked]; RFC Errata
> System <[email-masked]>
> *Subject:* Re: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
>
>
> Thank you, Rob.
>
>
>
> Best regards,
>
>
>
> *Alexei Sadovnikov*
>
> *From: *"Rob Wilton (rwilton)" <[email-masked]>
> *Date: *Tuesday, February 22, 2022 at 10:21 AM
> *To: *Kent Watsen <[email-masked]>, as549r <[email-masked]>
> *Cc: *RFC Errata System <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, Joel Jaeggli <
> [email-masked]>, Lou Berger <[email-masked]>, Randy Presuhn <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *RE: [netmod] [Technical Errata Reported] RFC7950 (6855)
>
>
>
> Hi,
>
>
>
> 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:
>
>
>
> 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
>
>
>
>
>
> Cc: SADOVNIKOV, ALEXEI <[email-masked]>; RFC Errata System <
> [email-masked]>; [email-masked]; [email-masked]; Joel
> Jaeggli <[email-masked]>; Lou Berger <[email-masked]>; Randy Presuhn <
> [email-masked]>; [email-masked]
>
> On Feb 17, 2022, at 5:53 PM, Randy Presuhn <
> 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.
>
>
>
> 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.
>
> m  781.249.1516 |  o  781.249.1516 | [email-masked] <
> mailto:[email-masked]>_ <[email-masked]%3e_>
>
> *To: *RFC Errata System <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
> <
> https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpDMmnMUI4$
> >  >
>
> > Reported by: Alexei Sadovnikov <[email-masked] <mailto:[email-masked]>
> <[email-masked]%3e>>
>
> >
>
> > Section: GLOBAL
>
> >
>
> > Original Text
>
> > -------------
>
> > [email-masked] <mailto:[email-masked] <[email-masked]>>
>
> >
> <
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$>
>
>
>
>
>

---

From: Martin Björklund <[email-masked]>
Date: Fri, 25 Feb 2022 17:41:06 +0100 (CET)

"Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]> wrote:
> 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).

IMO the first paragraph is very clear; it talks about the keys - all
keys are encoded in the order the are defined in the "key" statement.
There is no text that suggests that this encoding is optional.

IMO the second paragraph is also clear; it talks about the *rest* (non
keys) - it says that the rest of the child nodes are encoded *after
the keys*, and then defines the order in which they are encoded.

*If* the intention had been that all elements are always encoded in
any order, the first paragraph wouldn't have been there.

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

Yes.

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

Yes.

/martin

> 
> 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.
> 
> 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,
> From: "Rob Wilton (rwilton)"
> <[email-masked]<mailto:[email-masked]>>
> To: Kent Watsen <[email-masked]<mailto:[email-masked]>>,
> as549r <[email-masked]<mailto:[email-masked]>>
> Cc: RFC Errata System
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, Joel Jaeggli
> <[email-masked]<mailto:[email-masked]>>, Lou Berger
> <[email-masked]<mailto:[email-masked]>>, Randy Presuhn
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> 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:
> 
> 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$>
> Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC
> Errata System
> <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; Joel Jaeggli
> <[email-masked]<mailto:[email-masked]>>; Lou Berger
> <[email-masked]<mailto:[email-masked]>>; Randy Presuhn
> <[email-masked]<mailto:[email-masked]>>;
> On Feb 17, 2022, at 5:53 PM, Randy Presuhn
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> 
> Hi -
> 
> required for interoperation or to limit behavior which has potential
> for causing harm”.
> 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.
> 
> 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.
> 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?
> 
> m 781.249.1516 | o 781.249.1516 |
> [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]>_<mailto:[email-masked]%3e_>
> 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,
> *From: *Randy Presuhn
> *<[email-masked]<mailto:[email-masked]>>
> *To: *RFC Errata System
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>
> *Cc: *as549r <[email-masked]<mailto:[email-masked]>>,
> *"[email-masked]<mailto:[email-masked]>"
> *<[email-masked]<mailto:[email-masked]>>
> > Reported by: Alexei Sadovnikov <[email-masked]<mailto:[email-masked]>
> > <mailto:[email-masked]><mailto:[email-masked]%3e>>
> >
> > Section: GLOBAL
> >
> > Original Text
> > -------------

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 25 Feb 2022 18:19:35 +0000

// 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 <[email-masked]>
Sent: 25 February 2022 16:39
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: SADOVNIKOV, ALEXEI <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; RFC Errata System <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

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

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
}

yes

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

Jason

Andy

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of SADOVNIKOV, ALEXEI
Sent: Tuesday, February 22, 2022 11:28 AM
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 25 Feb 2022 18:29:35 +0000

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) <[email-masked]>
Sent: Friday, February 25, 2022 1:20 PM
To: Andy Bierman <[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: SADOVNIKOV, ALEXEI <[email-masked]>; Kent Watsen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; RFC Errata System <[email-masked]>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

// As a contributor

Rob

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 25 February 2022 16:39
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

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
}

yes

Jason

Andy

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Fri, 25 Feb 2022 19:56:52 +0000

I agree with Andy.  From editorial standpoint, this fragment could potentially be improved by providing prose which talks about scenario of keys not being first in the model, or an example of such encoding.  But the text as it stands is beyond interpretation doubts; hence improving this part of text was not even part of original errata report.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: Andy Bierman <[email-masked]>
Date: Friday, February 25, 2022 at 11:40 AM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Cc: as549r <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>, Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, RFC Errata System <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

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
}

yes

Jason

Andy

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!kAoNtzVDWy3YmMQrMV_Vz169sl-0ELn_G2-8sKG7U60ZGwWXBeORjJ7Ufm3xNzbhcHHxpqw4UjgB$>

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Fri, 25 Feb 2022 21:14:36 +0000

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

AT&T Services, Inc.

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Friday, February 25, 2022 at 1:30 PM
To: "Rob Wilton (rwilton)" <[email-masked]>, Andy Bierman <[email-masked]>
Cc: as549r <[email-masked]>, Kent Watsen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, RFC Errata System <[email-masked]>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

Jason

// As a contributor

Rob

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
}

yes

Jason

Andy

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 28 Feb 2022 18:42:56 +0000

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 <[email-masked]>
Sent: Friday, February 25, 2022 4:15 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Andy Bierman <[email-masked]>
Cc: Kent Watsen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; RFC Errata System <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Jason,

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 25, 2022 at 1:30 PM
To: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>, Andy Bierman <[email-masked]<mailto:[email-masked]>>
Cc: as549r <[email-masked]<mailto:[email-masked]>>, Kent Watsen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

Jason

From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 25, 2022 1:20 PM
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>
Subject: RE: [netmod] [Technical Errata Reported] RFC7950 (6855)

// As a contributor

Rob

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
}

yes

Jason

Andy

Thank you, Rob.

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

Hi,

Alexi,

Regards,
Rob

-----Original Message-----
From: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Sent: 22 February 2022 15:05
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>; Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

Kent  // as co-chair

Hi -

Randy

--------------------
Best regards,
*Alexei Sadovnikov*
order as
the same
node's
encoded as
the same
encoded as

---

From: Jürgen Schönwälder <[email-masked]>
Date: Mon, 28 Feb 2022 19:53:06 +0100

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.

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Feb 2022 11:05:40 -0800

> 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
> > 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
> >
> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Rob
> Wilton (rwilton) <[email-masked]>; Andy Bierman <[email-masked]>
> > Cc: Kent Watsen <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; RFC Errata System <
> [email-masked]>
> > 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
> > To: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>,
> Andy Bierman <[email-masked]<mailto:[email-masked]>>
> > Cc: as549r <[email-masked]<mailto:[email-masked]>>, Kent Watsen <
> [email-masked]<mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, RFC Errata System <
> [email-masked]<mailto:[email-masked]>>
> > 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
> >
> > To: Andy Bierman <[email-masked]<mailto:[email-masked]>>;
> Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:
> [email-masked]>>
> > Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; Kent
> Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; RFC Errata System <
> [email-masked]<mailto:[email-masked]>>
> > 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
> >
> >
> >
> > Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>; Rob
> Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Kent
> Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]
> <mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; RFC Errata System <
> [email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>> wrote:
> > Hi all,
> >
> 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
> > }
> purely at the order of the leafs won't match the XML encoding for key leafs.
> >
> > To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>;
> Kent Watsen <[email-masked]<mailto:[email-masked]>>
> > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:
> [email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata
> System <[email-masked]<mailto:[email-masked]>>
> > From: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]
> >>
> > Cc: RFC Errata System <[email-masked]<mailto:
> [email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:
> [email-masked]>" <[email-masked]<mailto:[email-masked]>>, Joel
> Jaeggli <[email-masked]<mailto:[email-masked]>>, Lou Berger <
> [email-masked]<mailto:[email-masked]>>, Randy Presuhn <
> [email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>
> https://urldefense.com/v3/__https:/github.com/netmod-wg/yang-next/issues__;!!BhdT!nBhCe6YCJpOtCnmFwZ1oBRjxufTDTet131D2wG3sxyq6mSUshsyDWQzcIrvGvVlRg4l8NnqjPk8x$>
> Errata System <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:
> [email-masked]>; Joel Jaeggli <[email-masked]<mailto:[email-masked]>>;
> Lou Berger <[email-masked]<mailto:[email-masked]>>; Randy Presuhn <
> [email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>>
> wrote:
> >
> > Hi -
> >
> > m  781.249.1516 |  o  781.249.1516 | [email-masked]<mailto:_
> [email-masked]> <mailto:[email-masked]>_<mailto:[email-masked]%3e_>
> > *To: *RFC Errata System <[email-masked]<mailto:
> [email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:
> [email-masked]>" <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:
> [email-masked]>" <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>
> > *Cc: *as549r <[email-masked]<mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> 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.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$
> >
> >
> >
> > https://www.ietf.org/mailman/listinfo/netmod<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$
> >
>

---

From: "SADOVNIKOV, ALEXEI" <[email-masked]>
Date: Mon, 28 Feb 2022 22:14:36 +0000

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

In addition to what Andy said (which I agree with)…

Ordered-by-user, is a special case – this is where the order is significant.  For completeness it would be significant even in JSON encapsulation (arrays are ordered).  Unlike other XML ordering cases, the order in ordered-by-user is simply significant by itself.

In other scenarios of ordering of XML document as described in RFC 7950 there are two different aspects (and sticking with your terminology):

  1.  The way RFC 7950 stands, the order of XML does matter.  Consequently, and XML document which is ordered differently does not have to be “processed/ordered”; it is totally legitimate for such XML document to be rejected.

This could also allow parser of XML document to be more efficient in processing data taking an account model order.

For example, in your earlier example of <key-1>,<key-2>,<key-3> vs to <key-1>,<key-3>,<key-2>, one is correct ordering and will be “processed” correctly; the other one is wrong ordering and may result in processing failure.

  1.  The second aspect, which I think you talking about, is the significance of such ordering required by RFC.  I do agree with you, there is nothing which prevents correct “processed/ordered” to be done.  In other words, the processor knows what the keys are and which order the keys are in, and he can get them from XML document.  Further, if payload comes as JSON, the ordering is not there, so if processor can consume both JSON and XML he is already implementing order independent processing for JSON.

Another point relevant to this conversation hides in section 6.4<https://datatracker.ietf.org/doc/html/rfc7950#section-6.4>.  XPath Evaluations, which states

   The data tree has no concept of document order.  An implementation
   needs to choose some document order, but how it is done is an
   implementation decision.  This means that XPath expressions in YANG
   modules SHOULD NOT rely on any specific document order.

Couple point to note here:

  *   The XPATH has document order axes, e.g. ‘preceding-sibling’ hence it can interrogate document order
  *   RFC says that this is implementation specific (e.g. it does not need to follow the order of XML encapsulation described elsewhere).
Consequently, in your keys example, it is implementation dependent which is preceding-sibling key-2, and it can be different from what it is in XML document encoding the data.

Not being an original contributor of this RFC, I really cannot tell why ordering requirements (other than ordered-by-user) are in RFC, nor what good do such requirements do.

I can say though that this ordering is not a discussion of RFC 7950, which sets the requirements, nor a discussion of this errata, which was about wording used to set requirements.  It could be part of YANG NEXT discussion :)

Best regards,

Alexei Sadovnikov

AT&T Services, Inc.

From: Andy Bierman <[email-masked]>
Date: Monday, February 28, 2022 at 2:06 PM
To: Jürgen Schönwälder <[email-masked]>, "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>, as549r <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>, Andy Bierman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, RFC Errata System <[email-masked]>
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (6855)

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

- ordered-by user
- rpc input
- rpc output
- action input
- action output

/js

On Mon, Feb 28, 2022 at 06:42:56PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> From: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]>>
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; Andy Bierman <[email-masked]<mailto:[email-masked]>>
> Cc: Kent Watsen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; RFC Errata System <[email-masked]<mailto:[email-masked]>>
> m  781.249.1516 |  o  781.249.1516 |  [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
> From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Andy Bierman <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: as549r <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: Andy Bierman <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> From: Andy Bierman <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Hi all,
>
> From: netmod <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> On Behalf Of SADOVNIKOV, ALEXEI
> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> m  781.249.1516 |  o  781.249.1516 |  [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>
> From: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, as549r <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Joel Jaeggli <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Lou Berger <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Randy Presuhn <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> 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$><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
>
>
> From: Kent Watsen <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> Cc: SADOVNIKOV, ALEXEI <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>; Joel Jaeggli <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Lou Berger <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; Randy Presuhn <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> On Feb 17, 2022, at 5:53 PM, Randy Presuhn <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
> Hi -
>
> m  781.249.1516 |  o  781.249.1516 | [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>_<mailto:[email-masked]<mailto:[email-masked]>%3e_>
> *From: *Randy Presuhn <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> *To: *RFC Errata System <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> *Cc: *as549r <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
> > 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$> <https://urldefense.com/v3/__https:/www.rfc-editor.org/errata/eid6855__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpDMmnMUI4$>  >
> > Reported by: Alexei Sadovnikov <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>><mailto:[email-masked]<mailto:[email-masked]>%3e>>
> >
> > Section: GLOBAL
> >
> > Original Text
> > -------------
> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>> <mailto:[email-masked]<mailto:[email-masked]>>
> > 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$> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!gZbsQDBeTveBJPSYBpHQOJS8wjZSUsguzZ6KwXq4NAiJ1cAOZgcko9_3wb4pLOxeGCFKcQFoi9XajHOG-NeqWtpD91awGhs$>
>
>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkBcjX3J0$><https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$>

> https://www.ietf.org/mailman/listinfo/netmod<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkBcjX3J0$>

--
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/<https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkNtNyKSv$>>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Feb 2022 23:28:02 +0000

Folks,

Please add items to the YANG Next tracker as they arise lest we forget them later   ;)

	https://github.com/netmod-wg/yang-next/issues

Thanks!
Kent

> On Feb 28, 2022, at 5:14 PM, SADOVNIKOV, ALEXEI <[email-masked]> wrote:
> 
> The way RFC 7950 stands, the order of XML does matter.  Consequently, and XML document which is ordered differently does not have to be “processed/ordered”; it is totally legitimate for such XML document to be rejected.
> The second aspect, which I think you talking about, is the significance of such ordering required by RFC.  I do agree with you, there is nothing which prevents correct “processed/ordered” to be done.  In other words, the processor knows what the keys are and which order the keys are in, and he can get them from XML document.  Further, if payload comes as JSON, the ordering is not there, so if processor can consume both JSON and XML he is already implementing order independent processing for JSON.
>  
> Another point relevant to this conversation hides in section 6.4 <https://datatracker.ietf.org/doc/html/rfc7950#section-6.4>.  XPath Evaluations, which states
>  
> The XPATH has document order axes, e.g. ‘preceding-sibling’ hence it can interrogate document order
> RFC says that this is implementation specific (e.g. it does not need to follow the order of XML encapsulation described elsewhere).
> m  781.249.1516 |  o  781.249.1516 |  [email-masked] <mailto:[email-masked]>
>  
> On Mon, Feb 28, 2022 at 10:53 AM Jürgen Schönwälder <[email-masked] <mailto:[email-masked]>> wrote:
>> > From: SADOVNIKOV, ALEXEI <[email-masked] <mailto:[email-masked]>>
>> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]>>; Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]>>; Andy Bierman <[email-masked] <mailto:[email-masked]>>
>> > Cc: Kent Watsen <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>; RFC Errata System <[email-masked] <mailto:[email-masked]>>
>> > m  781.249.1516 |  o  781.249.1516 |  [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> > 
>> > From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > To: "Rob Wilton (rwilton)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Andy Bierman <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: as549r <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > From: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > To: Andy Bierman <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: SADOVNIKOV, ALEXEI <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > From: Andy Bierman <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: SADOVNIKOV, ALEXEI <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > On Fri, Feb 25, 2022 at 8:21 AM Sterne, Jason (Nokia - CA/Ottawa) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> > Hi all,
>> > 
>> > From: netmod <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> On Behalf Of SADOVNIKOV, ALEXEI
>> > To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > m  781.249.1516 |  o  781.249.1516 |  [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> > 
>> > From: "Rob Wilton (rwilton)" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > To: Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, as549r <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Joel Jaeggli <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Lou Berger <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Randy Presuhn <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > 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$><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
>> > 
>> > 
>> > From: Kent Watsen <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > To: Rob Wilton (rwilton) <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > Cc: SADOVNIKOV, ALEXEI <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>; Joel Jaeggli <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Lou Berger <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; Randy Presuhn <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> > On Feb 17, 2022, at 5:53 PM, Randy Presuhn <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> > 
>> > Hi -
>> > 
>> > m  781.249.1516 |  o  781.249.1516 | [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>_<mailto:[email-masked] <mailto:[email-masked]>%3e_>
>> > *From: *Randy Presuhn <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > *To: *RFC Errata System <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > *Cc: *as549r <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>
>> > > 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$ <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$>>  >
>> > > Reported by: Alexei Sadovnikov <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>><mailto:[email-masked] <mailto:[email-masked]>%3e>>
>> > >
>> > > Section: GLOBAL
>> > >
>> > > Original Text
>> > > -------------
>> > > [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] <mailto:[email-masked]>>
>> > >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$ <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$>>
>> > 
>> > 
>> > [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>
>> >https://www.ietf.org/mailman/listinfo/netmod <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkBcjX3J0$><https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!mg1laEAxyhmBddjWVYRImubHWsCFHW2ba3Z-Q60UtvXousUUp8h1zSQ-WE9JMsWNZBDxIq7HL9z0W_rMKUI$>>
>> 
>> > https://www.ietf.org/mailman/listinfo/netmod <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/netmod__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkBcjX3J0$>
>> 
>> 
>> -- 
>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/ <https://urldefense.com/v3/__https:/www.jacobs-university.de/__;!!BhdT!g7SDpS9yQfVKdk2T0pTop0WrxCjpbEWsFuJ6ej42V6SkpxOFDyTA8ubwV8If1OPdjQDqkNtNyKSv$>>

---

From: Martin Björklund <[email-masked]>
Date: Tue, 01 Mar 2022 08:34:51 +0100 (CET)

Hi,

The main reason that keys are encoded first is that it allows for
efficient streaming parsing.  The reciever can act on an instance as
soon as the keys are received, w/o having to buffer the entire
document.  For example, in the implementation that I used to work
with, a copy-config a get-config's result used more or less a constant
amount of memory, regardless of the size of the config.

This optimization is not possible if JSON is used.

/martin