Re: [Netconf] Representing URLs
Ladislav Lhotka <lhotka@nic.cz> Wed, 04 December 2013 12:33 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 58AC61AE250 for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 04:33:57 -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 8FivqAPAHBXg for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 04:33:54 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 751721AE122 for <netconf@ietf.org>; Wed, 4 Dec 2013 04:33:54 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A75F713F7CB; Wed, 4 Dec 2013 13:33:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386160431; bh=V6KDO9tJZOMiz3ctnOUaIZONJIhB4s/1K1U+UM3eLHM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cdXfDZHvjW9/ndZBrocRsTsxGjhbBmwEY+CJ984D1DHepxQ1WKEb8SiC1JHxgWvOv 0IF1x6aB/Oz/h9h/Cw+SKOBYjXZ5lCG0R9UDApIt59Sr9i8BApFfR9/+XS8tixHfPT zOHNVgJW59HfD4uHg+dxbwfceQ7O0lypZ3jV+4UE=
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: <CAFFjW4gPQ+yOo+TZXb-Ho2_UzJG-SAh=68qh_scvpae9b8Yn4Q@mail.gmail.com>
Date: Wed, 04 Dec 2013 13:33:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E67E6E74-F554-4D5A-ABFE-0C567A9743B3@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>
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 12:33:57 -0000
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. 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
- [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