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

[Wojciech Dec <[e-mail]>]

Hi Andy,

thanks for the reply. Continued inline...


On 26 November 2013 17:43, Andy Bierman <[e-mail]> wrote:

>
>
>
> On Tue, Nov 26, 2013 at 6:05 AM, Juergen Schoenwaelder <
> [e-mail]> 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.
>

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?

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

Cool.

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

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 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>
>