Subject: [Netconf] restconf retrieval of a whole module

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jun 2017 16:08:35 +0200

Hi,

assume that I have a YANG module A with two top-level containers A:a
and A:b. Is there a way to retrieve the entire module A with a single
RECTCONF request? It seems that I need a separate request for each
top-level node. Is this observation correct? If so, is this something
that has shown to be problematic in practice and worth fixing?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Jun 2017 14:44:55 +0000

https://tools.ietf.org/html/rfc8040#section-3.5.3.1:

   api-path = root *("/" (api-identifier / list-instance))
   root = string  ;; replacement string for {+restconf}
   api-identifier = [module-name ":"] identifier
   module-name = identifier
   list-instance = api-identifier "=" key-value *("," key-value)
   key-value = string  ;; constrained chars are percent-encoded
   string = <an unquoted string>
   identifier = (ALPHA / "_")
                *(ALPHA / DIGIT / "_" / "-" / ".")

Looks like 'api-identifier' MUST return 'identifier', so there's no way to, for instance, GET /data/A:  [to return the entire module 'A']

I don't think 'list-instance' can be used here, because these are top-level module containers (not lists) that you are describing.

This problem seems familiar to the collections problem in RESTCONF - getting a 'list' node has to generate a fake parent-container in JSON...

Kent

--

Hi,

/js

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jun 2017 08:01:52 -0700

hI,

Why can't you just use the "select" query parameter?

Andy

On Wed, Jun 7, 2017 at 7:44 AM, Kent Watsen <[email-masked]> wrote:

> Looks like 'api-identifier' MUST return 'identifier', so there's no way
> to, for instance, GET /data/A:  [to return the entire module 'A']
>
> I don't think 'list-instance' can be used here, because these are
> top-level module containers (not lists) that you are describing.
>
> This problem seems familiar to the collections problem in RESTCONF -
> getting a 'list' node has to generate a fake parent-container in JSON...
>
> Kent
>
>
> --
>
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jun 2017 08:03:01 -0700

oops -- we renamed select to be called "fields"

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jun 2017 17:27:03 +0200

But for the path again needs an identifier, no? Can you show me the
concrete example how I retrieve A:a and A:b from A? Or even better
everything from A?

/js

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jun 2017 08:39:41 -0700

> concrete example how I retrieve A:a and A:b from A? Or even better
Our server accepts fields on the datastore root:

GET http://localhost/restconf/data?fields=int8.1;int32.1

data xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf">
<int32.1 xmlns="http://netconfcentral.org/ns/test">100</int32.1>
<int8.1 xmlns="http://netconfcentral.org/ns/test">1</int8.1>
</data>

If the RFC says this is not allowed, then it should be corrected.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jun 2017 17:49:12 +0200

> If the RFC says this is not allowed, then it should be corrected.

Just to make sure I got this right, I would do

  {+restconf}/data?fields=A:a;A:b

in my example and the client has to construct a query with all
toplevel fields (since there is no wildcard).

The RFC says:

    fields-expr = path "(" fields-expr ")" / path ";" fields-expr / path
    path = api-identifier [ "/" path ]

This looks OK since fields-expr defines the value of the fields query
parameters. Since the "fields" query parameter is a "capability", can
it be that a server does not allow me to do this? I guess so. Hm.

/js

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Jun 2017 16:01:09 +0000

Why weren't the fields prefixed?  - since two modules could define the same
top-level fields.  Shouldn't it have been something like:

    GET /restconf/data?fields=ex-nc-test:int8.1;ex-nc-test:int32.1

Still, having to resort to a query parameter to do this seems weird.  I think modules
might be better to always define a single TLC (top-level container) for everything to
go under...

K.

On 6/7/17, 11:39 AM, "Andy Bierman" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 7, 2017 at 8:27 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
But for the path again needs an identifier, no? Can you show me the
concrete example how I retrieve A:a and A:b from A? Or even better
everything from A?

/js

Andy

On Wed, Jun 07, 2017 at 08:03:01AM -0700, Andy Bierman wrote:
> On Wed, Jun 7, 2017 at 8:01 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
>
> > hI,
> >
> > On Wed, Jun 7, 2017 at 7:44 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >> [email-masked]<mailto:[email-masked]>
> >> [email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Jun 2017 18:13:46 +0200

On Wed, Jun 07, 2017 at 04:01:09PM +0000, Kent Watsen wrote:
 
> Still, having to resort to a query parameter to do this seems weird.
> I think modules might be better to always define a single TLC
> (top-level container) for everything to go under...

NO! Please not! Lets not start to design data models to work around
any protocol limitations. If a protocol has a problem (not sure yet
whether this is true here), then fix the protocol.

/js