Re: [Netconf] [netmod] Restconf - config and operational data sets
Andy Bierman <andy@yumaworks.com> Thu, 28 November 2013 00:16 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783A81AE048 for <netconf@ietfa.amsl.com>; Wed, 27 Nov 2013 16:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.778
X-Spam-Level:
X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FXxx1SaeACv for <netconf@ietfa.amsl.com>; Wed, 27 Nov 2013 16:16:47 -0800 (PST)
Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1257F1AE045 for <netconf@ietf.org>; Wed, 27 Nov 2013 16:16:45 -0800 (PST)
Received: by mail-qe0-f47.google.com with SMTP id t7so8432454qeb.34 for <netconf@ietf.org>; Wed, 27 Nov 2013 16:16:45 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CdMkHprx9cGZgj1nSkYUdSwIVJFinEs1ekegBEmLzDw=; b=TmQnOQCXLmlgRQYVALdlY3xpn+1xnXdqZ3WsfRS+hjMJVCD1M4SiW0/MDdSN/D9+rP 4+OiMzZOLmDIhGBgImmEi1Knx8DMSx92KXPG+HkJI23HEZawLadZGia5Xw9Dvm3TU1tg vEozs/ohn0XX8704ypbZKTrQgBq28KLbZdEGTS2tvfXlwrh3VLbGrdNMk4t5Fgtd29OH 7NQZR1rL/61CUwGDoJuudvPoCEqsJKfXa5TcGEZQnm/J85TJLS+cC4jJQM3ItejNsFCz 2aaqYbmWgBkQCKPA5sRE/4eeLXZURO5dxLnzb6ly+UDM7eFAYiogPNDpI2n5loZX/CBv QPmQ==
X-Gm-Message-State: ALoCoQlE6O1nOt3TmLbplE/N+JP1vRPwKwsi5izCkY6ronP7lcEUkElt7A9W4wGmNx3yf+gpao+K
MIME-Version: 1.0
X-Received: by 10.49.84.105 with SMTP id x9mr18993023qey.65.1385597805231; Wed, 27 Nov 2013 16:16:45 -0800 (PST)
Received: by 10.140.86.200 with HTTP; Wed, 27 Nov 2013 16:16:45 -0800 (PST)
In-Reply-To: <CAFFjW4iofOm=xRBNDD0E3DY_+bGdJy5UbOtkMnRfhyZD_UQaOg@mail.gmail.com>
References: <CAFFjW4j96ehWxFStgHWWLZkHAk3iPJjO1nMzVVOhsoLNy5bEpA@mail.gmail.com> <20131126140557.GA63168@elstar.local> <CABCOCHRZOQ2S83Zq1zOFoVRVDzfNC2uBoA0NEAP5ZiX-GmoV5A@mail.gmail.com> <CAFFjW4iofOm=xRBNDD0E3DY_+bGdJy5UbOtkMnRfhyZD_UQaOg@mail.gmail.com>
Date: Wed, 27 Nov 2013 16:16:45 -0800
Message-ID: <CABCOCHRK+zy6Gtt5i3qYYe0yLzoHowKw8sRaKhqks2V2TyG8Rg@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Wojciech Dec <wdec.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="047d7bdc0ef0fbb05304ec31a07b"
Cc: Netconf <netconf@ietf.org>, draft-bierman-netconf-restconf@tools.ietf.org
Subject: Re: [Netconf] [netmod] Restconf - config and operational data sets
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2013 00:16:49 -0000
On Wed, Nov 27, 2013 at 11:29 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote: > Hi Andy, > > thanks for the reply. Continued inline... > > > On 26 November 2013 17:43, Andy Bierman <andy@yumaworks.com> wrote: > >> >> >> >> 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. >> > > 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 > 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 >>> > 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 oper… Juergen Schoenwaelder
- Re: [Netconf] [netmod] Restconf - config and oper… Andy Bierman
- Re: [Netconf] [netmod] Restconf - config and oper… Wojciech Dec
- Re: [Netconf] [netmod] Restconf - config and oper… Andy Bierman
- Re: [Netconf] [netmod] Restconf - config and oper… Wojciech Dec