Re: [Netconf] [netmod] Restconf

On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> I think the current home for restconf discussions is the NETCONF WG
> mailing list and not the NETMOD WG mailing list.
>
> /js
>
> On Tue, Nov 26, 2013 at 03:02:07PM +0100, Wojciech Dec wrote:
> > Hello Restconf authors,
> >
> > (retrying)
> >
> > got a question regarding your latest Restconf draft. This features the
> split
> > between /config and /operational URIs .
> >
> > The text in section 5.1.1 and 5.1.2 indicates that the data in these URIs
> > use
> > data-stores that are effectively dis-joint sets, i.e. Rw data is in
> /config
> > and
> > ro data is in /operational.
> > Is that the intent, correct interpretation?
> >
>

This is a conceptual API so the split is an implementation detail.
The operational data includes ancestor list+keys and containers.

> > If so, then the following example also in the draft indicates something
> > else:
> >
> > The jukebox data model is:
> >
> >          |  +--ro artist-count?   uint32
> >         |  +--ro album-count?    uint32
> >         |  +--rw song-count?     uint32
> >
>

Thanks for finding this bug (song-count is supposed to be config false
in the example-jukebox YANG module.

> >
> > (p102)
> >
> > While on p52 we see the following returned from the operational store:
> >
> > GET /restconf/operational/example-jukebox:jukebox/library
> >         HTTP/1.1
> >      Host: example.com <http://example.com/>
> >      Accept: application/yang.data+json
> >
> >   The server might respond:
> >
> >      HTTP/1.1 200 OK
> >      Date: Mon, 23 Apr 2012 17:01:30 GMT
> >      Server: example-server
> >      Cache-Control: no-cache
> >      Pragma: no-cache
> >      Content-Type: application/yang.data+json
> >
> >      {
> >        "example-jukebox:library" : {
> >           "artist-count" : 42,
> >           "album-count" : 59,
> >           "song-count" : 374
> >        }
> >      }
> >
> > Which interpretation is correct?
> >
>

The retrieval is correct.
The YANG example will be fixed.

> > That said, personally I find this URI "fork" undesirable, and not
> > something a Rest-like interface ought to provide. If anything, the
> > example, even if it turns out to be due to a typo, offers a better
> > alternative; ie have a resource that provides "all" info, config and
> > operational, and another that delivers an oper or config only set. Some
> > better even better options can also be thought of. Anyway, before going
> > there, it would be great to understand whether my interpretation is
> > correct.
> >
>

I thought about this idea some more and it doesn't really work
because the entity tags and last-modified timestamps for
config=true data nodes would be affected by changes to
descendant operational data nodes.

>From and HTTP caching POV, the ETag and Last-Modified headers
need to be updated if the resource changes at all. From a RESTCONF POV,
only the configuration data nodes can affect these headers or else they
are useless for If-Match testing for editing operations.

> Regards,
> > Wojciech.
>
>
Andy

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

Re: [Netconf] [netmod] Restconf - config and operational data sets