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

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Nov 2013 15:05:57 +0100

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?
> 
> 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
> 
> 
> (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?
> 
> 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.
> 
> Regards,
> Wojciech.

> _______________________________________________
> netmod mailing list
> [email-masked]
> 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/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Nov 2013 08:43:17 -0800

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

> >         |  +--rw song-count?     uint32

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

> > Which interpretation is correct?

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

> > there, it would be great to understand whether my interpretation is

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.

> > Wojciech.
Andy

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 27 Nov 2013 20:29:04 +0100

Hi Andy,

thanks for the reply. Continued inline...

> The operational data includes ancestor list+keys and containers.

Well, not sure I understand. The /config and /operational "resources" would
appear to be anything but conceptual. I.e. Any restconf API implementation
would expose these two top level resources, irrespective of the data-store
implementation used.  Any client following the Restconf API would use these
URIs as absolutes. What am I missing?

> The YANG example will be fixed.

Cool.

> descendant operational data nodes.

Well, the big downside of the current approach is that, for a client to get
a "complete view" of the state of some resource, it needs to do two API
calls to two rather distinct URIs.
Now, perhaps I should have explained better above, but the following would
still appear to offer the ETag and timestamps behaviour that you appear to
be indicating as a concern:
- the operational "tree" shows everything (config and run time state). No
one can assume that last-modified timestamps have to do with "last time
some config was changed"
- the config "tree" shows just the config  and there  one can assume that
last-modified timestamps have to do with "last time some config was
changed".

Clients could pick which one they want to use, or both.

Regards,
Wojciech.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Nov 2013 16:16:45 -0800

On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec <[email-masked]> wrote:

> Well, not sure I understand. The /config and /operational "resources"
> would appear to be anything but conceptual. I.e. Any restconf API
> implementation would expose these two top level resources, irrespective of
> the data-store implementation used.  Any client following the Restconf API
> would use these URIs as absolutes. What am I missing?
>

Yes they would use these APIs, but it doesn't mean the server maintains the
data in a way that resembles the API.  That's what I mean by conceptual.

> Well, the big downside of the current approach is that, for a client to
> get a "complete view" of the state of some resource, it needs to do two API

Yes -- I think that's what we discussed offline....

  /restconf/config  == config=true only
    config parameter ignored

  /restconf/data == operational data or all
    config=true ==> all
    config == false ==> operational data only

Andy

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 28 Nov 2013 11:43:52 +0100

On 28 November 2013 01:16, Andy Bierman <[email-masked]> wrote:

>
>
>
> On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec <[email-masked]>wrote:
>
>> Hi Andy,
>>
>> Now, perhaps I should have explained better above, but the following
>> would still appear to offer the ETag and timestamps behaviour that you
>> appear to be indicating as a concern:
Am I correct in assuming that this will be reflected in the next version of
the draft?

Thanks.