Subject: [netmod] list keys out of order

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Jun 2016 05:45:44 -0700

Hi,

YANG 1.1, sec. 7.8.4 says:

   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.

Where does is say the server MUST reject list keys provided by the client
that are out of order?  Where does is say what error-tag is returned?

thanks,
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 21 Jun 2016 14:50:06 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> that are out of order?

Nowhere.  This text is unchnaged from 6020 (7.8.5).  If you follow the
Postel principle you would probably accept out-of-order keys.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Jun 2016 06:00:38 -0700

> Postel principle you would probably accept out-of-order keys.
So some servers can reject the request and others can accept it?
It would be nice if the client knew what to expect.
Why is this text even in YANG 1.1 if it is not required.

Andy

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 21 Jun 2016 10:55:06 -0400

> that are out of order?  Where does is say what error-tag is returned?

Maybe this is due to my inexperience, but I read the text of 7.8.4, "A
list is encoded ..." as "When translating an abstract data structue into
XML, you encode ...".  That is, these are the rules for how a server
*writes* XML.

What this leaves unspecified, or only implied, are the rules for
*reading* XML.

The correct solution, IMO, is that the text should explicitly address
writing and reading seperately, or state that they are identical.
(Generally, programming language specs describe input and output
operations seperately.)

Dale

---

From: "Xiang Li" <[email-masked]>
Date: Tue, 21 Jun 2016 10:24:37 -0500

>    identifier element, in the same order as they are defined within the

I read as the sentence above already implies that an out of order key is an not ok, 

Otherwise why bother to specify it?

When talking about encoding other leaf nodes, the spec says explicitly:

“ …Otherwise, the

   subelements are encoded in any order.”

If  out of order keys is ok then what about encoding keys mixed with other leaf nodes?

IMO Perhaps it is better if 6020bis can explicitly say: 

The list's key nodes must be encoded as subelements to the list's

"key" statement.

-Xiang

From: netmod [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Tuesday, June 21, 2016 8:01 AM
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [netmod] list keys out of order

On Tue, Jun 21, 2016 at 5:50 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]> > wrote:

/martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 22 Jun 2016 13:46:38 +0200

> Postel principle you would probably accept out-of-order keys.

I agree. Note that in JSON encoding the order of keys isn't enforced
(because it can't be).

Lada

>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: "Xiang Li" <[email-masked]>
Date: Wed, 22 Jun 2016 10:26:11 -0500

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Ladislav
> Lhotka
> Sent: Wednesday, June 22, 2016 6:47 AM
> To: Martin Bjorklund <[email-masked]>; [email-masked]
> Cc: [email-masked]
> >> Where does is say the server MUST reject list keys provided by the
> >> client that are out of order?
> >
(because
> it can't be).

Currently  the text in spec  says:
----------------------------------------------------------------------------
-----
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.

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

Clearly the texts above means the order of keys (and rpc input) is
significant 
and required, while the order of none-key leafs is not. 

However, in
https://tools.ietf.org/html/draft-ietf-netmod-yang-json-06#page-8
----------------------------------------------------------------------------
The ordering of array elements follows the same rules as the ordering
   of XML elements representing list entries in the XML encoding.
   Specifically, the "ordered-by" properties (sec. 7.7.7 in
   [I-D.ietf-netmod-rfc6020bis]) MUST be observed.

   Unlike the XML encoding, where list keys are required to precede any
   other siblings within a list entry, and appear in the order specified
   by the data model, the order of members in a JSON-encoded list entry
   is arbitrary because JSON objects are fundamentally unordered
   collections of members.

----------------------------------------------------------------------------
-----

I think this inconsistency in XML and JSON encoding is just confusing.

My question is that is the order requirement of keys and RPC input
parameters
 in XML is really needed? If not, IMO we should just remove it. 

-Xiang

---

From: Andy Bierman <[email-masked]>
Date: Wed, 22 Jun 2016 08:47:05 -0700

> > I agree. Note that in JSON encoding the order of keys isn't enforced

I checked our server and it accepts any node out of order, including keys,
so I agree out-of-order keys SHOULD be accepted.

Andy