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

[Wojciech Dec <[e-mail]>]

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

>
>
>
> On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec <[e-mail]>wrote:
>
>> 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?
>>
>
>
> 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.
>
>
>>
>>>
>>>> > 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.
>>
>>
>
> 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
>
>
>
Am I correct in assuming that this will be reflected in the next version of
the draft?

Thanks.


>
>
>> Regards,
>> Wojciech.
>>
>
>
> Andy
>
>
>
>>
>>
>>>
>>> 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/>
>>>>
>>>
>>>
>>
>