Re: [Netconf] Representing URLs
Ladislav Lhotka <lhotka@nic.cz> Wed, 04 December 2013 15:43 UTC
Return-Path: <lhotka@nic.cz>
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 8D4DE1AE2AC for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 07:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.652
X-Spam-Level:
X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-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 3x2XS61oIxmH for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 07:43:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 526D01AE2A8 for <netconf@ietf.org>; Wed, 4 Dec 2013 07:43:20 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9B62714015B; Wed, 4 Dec 2013 16:43:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386171796; bh=Qfg+E3jrhIqMKcQNdX5dI2FxLJNNmz0Lv9VsE53jRmg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qjwubikpYg2FKGL0OgFWKUv5iMIVZ6kf0oYnfjqFTnsM9zbZD1YxnlGvPL4u9/3ns s3sm5Kc5iF5iLYcOOzDFAOWmK0lfs9D7Gs0fhrVnKyyBQOjls8tpKDeobVF4xlFXjd MO0WF7jfDsD2VQMh1dCGSU0UwW4ZcwSlNom4R8Iw=
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <CAFFjW4iJVmPsoQLPMKJSJXWMbaAdpFcZvUcztqk2z+h0eFq0ww@mail.gmail.com>
Date: Wed, 04 Dec 2013 16:43:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9AEC841C-E765-4D0D-A1A6-928E6C90D225@nic.cz>
References: <CAFFjW4hXEZxTyhnaHLk-URST=6mNfX8kO1aFEVtEvTm8Z-qysw@mail.gmail.com> <CABCOCHS4rRJRy=TdXRTvM6mffG36u9uHRZWLOkm7a3rCne+Gwg@mail.gmail.com> <CAFFjW4iNX1rG7VnWqvHVz+c6-WdJ3d8aT1qiGbJGVOOA1Afz9A@mail.gmail.com> <B19C5C86-BCFE-4C81-9D86-4C9FD7BACE7C@nic.cz> <CAFFjW4h7ruX0ooKw4U-syLw-95McyOV2Rb1KRjU49vSpN3O7hg@mail.gmail.com> <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> <CAFFjW4gPQ+yOo+TZXb-Ho2_UzJG-SAh=68qh_scvpae9b8Yn4Q@mail.gmail.com> <E67E6E74-F554-4D5A-ABFE-0C567A9743B3@nic.cz> <CAFFjW4iJVmPsoQLPMKJSJXWMbaAdpFcZvUcztqk2z+h0eFq0ww@mail.gmail.com>
To: Wojciech Dec <wdec.ietf@gmail.com>
X-Mailer: Apple Mail (2.1822)
X-Virus-Scanned: clamav-milter 0.97.8 at mail
X-Virus-Status: Clean
Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Representing URLs
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: Wed, 04 Dec 2013 15:43:23 -0000
On 04 Dec 2013, at 15:57, Wojciech Dec <wdec.ietf@gmail.com> wrote: > On 4 December 2013 13:33, Ladislav Lhotka <lhotka@nic.cz> wrote: >> >> On 04 Dec 2013, at 11:10, Wojciech Dec <wdec.ietf@gmail.com> wrote: >> >>> On 3 December 2013 20:40, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>> >>>> On 03 Dec 2013, at 18:47, Wojciech Dec <wdec.ietf@gmail.com> wrote: >>>> >>>>> On 3 December 2013 16:58, Ladislav Lhotka <lhotka@nic.cz> wrote: >>>>>> >>>>>> On 03 Dec 2013, at 16:39, Wojciech Dec <wdec.ietf@gmail.com> wrote: >>>>>> >>>>>>> Following up some of my earlier questions... Inline... >>>>>>> >>>>>>> On 29 November 2013 16:59, Andy Bierman <andy@yumaworks.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote: >>>>>>>>> >>>>>>>>> Hello Restconf authors, >>>>>>>>> >>>>>>>>> I would like to ask a few questions and seek your thoughts on the topic of >>>>>>>>> URL representation in the API >>>>>>>>> Currently Yang allows two forms by which one could seek to have URI data >>>>>>>>> be represented in a model: >>>>>>>>> >>>>>>>>> A. >>>>>>>>> leaf someUri { >>>>>>>>> type instance-identifier; >>>>>>>>> //some Xpath expression to a node >>>>>>>>> } >>>>>>>>> >>>>>>>>> B. >>>>>>>>> leaf anotherUri { >>>>>>>>> type yang:uri; >>>>>>>>> default "/my_uri/is/here" >>>>>>>>> } >>>>>>>>> >>>>>>>>> Now, while the above is perhaps sufficient for some well known absolute >>>>>>>>> paths, there appear to be a couple of problems in terms of a Restful API: >>>>>>>>> >>>>>>>>> 1. Based on the current Restconf spec, both A and B above when faced with >>>>>>>>> a GET would appear to expose a URI, which the client would have to do some >>>>>>>>> manipulation magic on it before use. What a Restful API would be more likely >>>>>>>>> to expose instead is a URL, eg in JSON: >>>>>>>>> { >>>>>>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I do not understand the concern. >>>>>>>> One leaf is //restconf/config/someUri and the other is >>>>>>>> /restconf/config/anotherUri. >>>>>>>> What is the manipulation magic? Constructing /path/to/data/node based on >>>>>>>> YANG? >>>>>>>> That is the point of RESTCONF. There are already plenty of solutions for >>>>>>>> using >>>>>>>> REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF for >>>>>>>> clients that want to ignore YANG. There are already have plenty of choices >>>>>>>> for that. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It would appear to be sensible to add to the Restconf spec a URL >>>>>>>>> generation capability. I.e. have Restconf transform URIs into canonical >>>>>>>>> URLs. Thoughts? >>>>>>>> >>>>>>>> >>>>>>>> Can you describe the solution you have in mind? >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2. A URL to a data-model specific method >>>>>>>>> Suppose that the model was also defining an RPC, along the lines of the >>>>>>>>> "play" RPC in the Jukebox example. Now, as part of the song resource access >>>>>>>>> API, it would be natural to have such a method returned in a URL. That would >>>>>>>>> also be much more Resful than the currently implicit "/operations" resource >>>>>>>>> listing. >>>>>>>>> While it may be possible to use B. above to some degree, that is still >>>>>>>>> below par as it is not validated in the model. >>>>>>>>> Use of A. appears, to me at least, not possible since the RPC is not a >>>>>>>>> node. >>>>>>>>> Thus, is there a way to have Restconf return an RPC/services list for the >>>>>>>>> data? Eg: >>>>>>>>> >>>>>>>>> { >>>>>>>>> "songs": >>>>>>>>> [ >>>>>>>>> a list of songs, 1, 2, etc >>>>>>>>> ], >>>>>>>>> "rpc": >>>>>>>>> { >>>>>>>>> "play": [ "http://example.com/operations/example-jukebox:play"] >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>> >>>>>>>> The API already has /restconf/operations/<YANG-rpc-name>. >>>>>>>> >>>>>>>> YANG is not object-oriented, so /restconf/config/routing/<RPC-name> >>>>>>>> is not how the RPC is defined. You are describing a proprietary >>>>>>>> extension. >>>>>>>> >>>>>>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>>>>> >>>>>>>>> It would be useful to be able to use the "current()" function to construct >>>>>>>>> URIs/URLs returned in Restconf. The spec does not make it clear on whether >>>>>>>>> this would actually work in A or B above. Would it, or is there some other >>>>>>>>> way? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The URI is not an XPath expression. There are no predicates allowed, >>>>>>>> I don't think current() is allowed outside a predicate. >>>>>>> >>>>>>> Ok, so what is the way in Yang to have a predicate (e.g. current()) >>>>>>> based expression that ends up being represented as a URI in Restconf? >>>>>>> Use of the current() predicate in the instance-identifier appears not >>>>>>> to be supported (at least by pyang). >>>>>> >>>>>> Predicates in instance-identifiers can be used only for matching list keys against constant strings, see sec. 9.13 in RFC 6020. >>>>>> >>>>>> Can you give an example of an effect you would like to achieve? >>>>> >>>>> Starting with a basic example: In a data-model for interfaces/x/y, I >>>>> would like the ability to actually have a reference to another node in >>>>> the model, that in Restconf ends up shwoing up as a URI. Eg. getting >>>>> at the URI /interfaces/x/y, would return data which would also give me >>>>> a URI for "/line-cards/foo/serial-number". >>>>> >>>>> A hypothetical Yang data-model for this could be: >>>>> list interfaces { >>>>> key some; >>>>> leaf some { >>>>> type string; >>>>> } >>>>> list details; >>>>> key id; >>>>> leaf id { >>>>> type string; >>>>> } >>>>> Other stuff >>>>> leaf someUri { >>>>> type instance-identifier; >>>>> // Xpath expression to the line-cards/foo >>>>> } >>>>> } >>>>> } >>>> >>>> Assuming that line-cards also appear somewhere in the data tree, a leafref would be a more natural way of representing the reference - and then you can use current(), too. >>>> >>>> I have myself never used an instance-identifier in any data model yet, presumably they are mainly useful in notifications. >>> >>> So leafrefs are great, but if I interpret them correctly in rfc6020 >>> (http://tools.ietf.org/html/rfc6020#page-124), their usage in the >>> context of Restconf would result not in a URI for the leaf being >>> passed to a client (say after a GET), but rather the value of that >>> leaf. It also does not appear to be suited to referencing a data node >>> (eg container). >> >> In my view, the leafref value (such as a list key) can be passed in in a GET response and then it should be easy for the client-side application to construct the corresponding URI, XPath or whatever, because it has access to the data model. I know this goes against REST catechism but I am inclined to consider it a feature, not a bug. > > It would be better to call it a missing feature. > Leafref is fine as is, and does pass the value. The recipient though > has no idea how to access the resource of that value unless the whole > (sub) tree is conveyed. > Using the example from 6020: > > leaf mgmt-interface { > type leafref { > path "../interface/name"; > } > } > > An example of a corresponding XML snippet: > > <interface> > <name>eth0</name> > </interface> > <interface> > <name>lo</name> > </interface> > > <mgmt-interface>eth0</mgmt-interface> > > A client receiving eth0, has no idea about the URI of that resource. > Assuming that the client is coded to the data model, or is fully Yang > aware, and able to combine the "path ../interface/name" to make sense > of it all, is not just going against REST principles; it forces a > tight client-server coupling, even when one would not be required. I > expect a good number of client applications wishing to access he data > via Restconf, without necessarily having interest in the full > data-models, or even in altering configurations (eg reading a > topology). > As I wrote previously, having the option of Yang aware clients vs pure > REST would be a much stronger proposition. > What can we do to get the missing feature? RESTCONF is a protocol only by virtue of YANG data models that serve as a contract between the server and client. Other UIs, perhaps more RESTful or more suitable for human users, are certainly possible, but this is outside the scope of the WG - UI is a taboo word in the IETF in general. Lada > > I would still see the "instance-identifier" either molded into a URI, > or a new "instance-identifier" like data-type that allow that. > > Thoughts? > > -Wojciech. > >> >> Lada >> >>> >>> Regards, >>> Wojciech. >>>> >>>> Lada >>>> >>>>> >>>>> In the instance-identifier, having a leafref like current() >>>>> restriction/replacement would appear to be useful in cases where wants >>>>> to construct such a URI by using as a piece the context of the current >>>>> node. >>>>> >>>>> >>>>> Open to your suggestions. >>>>> >>>>> Thanks, >>>>> Wojciech. >>>>> >>>>>> >>>>>> Lada >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Wojciech. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Wojciech. >>>>>>>>> >>>>>>>> >>>>>>>> Andy >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Netconf mailing list >>>>>>> Netconf@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>>> >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>> >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C
- [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Juergen Schoenwaelder
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Wojciech Dec
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Ladislav Lhotka
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Andy Bierman
- Re: [Netconf] Representing URLs Martin Bjorklund
- Re: [Netconf] Representing URLs Andy Bierman