Subject: Re: [Netconf] RESTCONF JSON list questions / restconf confusing text

From: Nick Weeds <[email-masked]>
Date: Mon, 26 Sep 2016 14:34:31 +0000

> Nick Weeds <[email-masked]> writes:
>
> > Hi Mahesh,
> >
> > The answer to question (2) is that list entries should always be encoded as JSON lists even when there is only one entry.  This is fixed in the latest restconf draft.
> >
> > I didn't really get an answer to question (1) other than "check the WG 
> > mailing list". However, a subsequent discussion on the WG mailing list
>
> Yes, and also, for example,
>
> https://www.ietf.org/mail-archive/web/netconf/current/msg11049.html
>
> > with subject "restconf confusing text" raised the same issue.  I think 
> > the official view is that restconf does not support querying a list 
> > because a list is not a single "data node", and that a future restconf
>
> In YANG, a list *is* a single data node:
>
>    o  data node: A node in the schema tree that can be instantiated in a
>       data tree.  One of container, leaf, leaf-list, list, anydata, and
>       anyxml.

You are correct, I probably meant "data resource" rather than "data node" (since "data resources" are in the data tree rather than the schema tree).
In draft-ietf-netconf-restconf-16 section we have:

    3.5.  Data Resource

       A data resource represents a YANG data node that is a descendant node
       of a datastore resource.  Each YANG-defined data node can be uniquely
       targeted by the request-line of an HTTP method.  Containers, leafs,
       leaf-list entries, list entries, anydata and anyxml nodes are data
       resources.

Interestingly the 3rd sentence omits Yang lists (rather than Yang list entries) as data resources, even though as you point out Yang lists are Yang-defined data nodes (2nd sentence).

The "restconf confusing text" discussion seems to have continued, but unfortunately does not seem to have reached a clear conclusion (although XML limitations do appear to be a factor).

	Nick.

> > collections draft would provide this kind of function.  I don't think
>
> I believe it has to do with limitations of XML that doesn't have (unlike YANG and JSON) the concept of a list, just a sequence of elements with the same tag.
>
> Lada
>
> > Dale Worley agrees with that position and/or my summary of it.  Also 
> > note that it is possible to query a list by using a parent container 
> > as the target together with a "fields" query parameter to select the 
> > list, so it is possible to query a list using restconf but in a more 
> > fiddly way.
> >
> >                Nick.
> >

---

From: Kent Watsen <[email-masked]>
Date: Mon, 26 Sep 2016 16:27:34 +0000

>    Interestingly the 3rd sentence omits Yang lists (rather 
> than Yang list entries) as data resources, even though as 
> you point out Yang lists are Yang-defined data nodes.

But it does include leaf-list, and the same issue is with both list and leaf-list.  That said, the 3rd sentence is just exemplary.  The 2nd sentence is more normative.  I like the 2nd sentence as it is, but the draft doesn’t currently provide a solution for list and leaf-leaf.  Technically speaking, the 2nd sentence isn’t wrong as it is; a client can target leaf/leaf-list nodes, but they’ll get an error back until this issue is fixed.  

>    The "restconf confusing text" discussion seems to have continued,
> but unfortunately does not seem to have reached a clear conclusion
> (although XML limitations do appear to be a factor).

Andy appears to be trying shut down that thread now ;)   I was hoping that his email might spur some more comments and breathe life into it again.  

Kent

---

From: Nick Weeds <[email-masked]>
Date: Mon, 26 Sep 2016 16:43:21 +0000

Thanks Kent.

I do hope that the draft will either make it clear whether or not it is valid for a GET request URI to target a Yang list rather than a Yang list entry, or else state clearly that the question is outside the scope of the specification.  Currently I don't think that's clear, so different people can pick apart the wording and reach different conclusions (with the 2nd and 3rd sentences discussed below being one example).

	Nick.

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]] 
Sent: 26 September 2016 17:28
To: Nick Weeds; Ladislav Lhotka; Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: [Netconf] RESTCONF JSON list questions / restconf confusing text

>    Interestingly the 3rd sentence omits Yang lists (rather than Yang 
> list entries) as data resources, even though as you point out Yang 
> lists are Yang-defined data nodes.

Kent

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 26 Sep 2016 16:44:57 +0000

+1

Michael

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Nick Weeds
Sent: Monday, September 26, 2016 6:43 PM
To: Kent Watsen
Cc: [email-masked]
Subject: Re: [Netconf] RESTCONF JSON list questions / restconf confusing text

Thanks Kent.

	Nick.

-----Original Message-----
From: Kent Watsen [mailto:[email-masked]]
Sent: 26 September 2016 17:28
To: Nick Weeds; Ladislav Lhotka; Mahesh Jethanandani
Cc: [email-masked]
Subject: Re: [Netconf] RESTCONF JSON list questions / restconf confusing text

Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Sep 2016 09:47:27 -0700

On Mon, Sep 26, 2016 at 9:27 AM, Kent Watsen <[email-masked]> wrote:

> But it does include leaf-list, and the same issue is with both list and
> leaf-list.  That said, the 3rd sentence is just exemplary.  The 2nd
> sentence is more normative.  I like the 2nd sentence as it is, but the
> draft doesn’t currently provide a solution for list and leaf-leaf.
> Technically speaking, the 2nd sentence isn’t wrong as it is; a client can
> target leaf/leaf-list nodes, but they’ll get an error back until this issue
> is fixed.
>
>
>
YANG has no concept of accessing all instances of a list or leaf-list as 1
entity.
This is a protocol issue.

> Andy appears to be trying shut down that thread now ;)   I was hoping that
> his email might spur some more comments and breathe life into it again.
>
>
The issue has not changed.
Still exactly the same problem that YANG-API fixed 6 years ago.
Still no agreement on the details or even if a wrapper container is even
desirable.
I see no reason to block RESTCONF. The WG already decided "no wrapper
container".

> Kent

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 26 Sep 2016 09:49:11 -0700

On Mon, Sep 26, 2016 at 9:44 AM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> I do hope that the draft will either make it clear whether or not it is
> valid for a GET request URI to target a Yang list rather than a Yang list
> entry, or else state clearly that the question is outside the scope of the
> specification.  Currently I don't think that's clear, so different people
> can pick apart the wording and reach different conclusions (with the 2nd
> and 3rd sentences discussed below being one example).
>
>
The draft is not going to make XML and JSON have the same feature set.
I see no reason at all why a server should be prohibited from using JSON
correctly,
especially if the RESTCONF server is JSON-only with no XML support at all.

Andy