Re: [Netconf] Representing URLs
Martin Bjorklund <mbj@tail-f.com> Wed, 04 December 2013 15:13 UTC
Return-Path: <mbj@tail-f.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 641EE1AE2B0 for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 07:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.897
X-Spam-Level:
X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] 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 MlfYNE4OGB-G for <netconf@ietfa.amsl.com>; Wed, 4 Dec 2013 07:13:16 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 303DF1AE2A3 for <netconf@ietf.org>; Wed, 4 Dec 2013 07:12:55 -0800 (PST)
Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 12CF537C001; Wed, 4 Dec 2013 16:12:51 +0100 (CET)
Date: Wed, 04 Dec 2013 16:12:50 +0100
Message-Id: <20131204.161250.821204486523776419.mbj@tail-f.com>
To: wdec.ietf@gmail.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CAFFjW4iJVmPsoQLPMKJSJXWMbaAdpFcZvUcztqk2z+h0eFq0ww@mail.gmail.com>
References: <CAFFjW4gPQ+yOo+TZXb-Ho2_UzJG-SAh=68qh_scvpae9b8Yn4Q@mail.gmail.com> <E67E6E74-F554-4D5A-ABFE-0C567A9743B3@nic.cz> <CAFFjW4iJVmPsoQLPMKJSJXWMbaAdpFcZvUcztqk2z+h0eFq0ww@mail.gmail.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org, draft-bierman-netconf-restconf@tools.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:13:17 -0000
Wojciech Dec <wdec.ietf@gmail.com> wrote: > On 4 December 2013 13:33, Ladislav Lhotka <lhotka@nic.cz> wrote: > > 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? > > I would still see the "instance-identifier" either molded into a URI, > or a new "instance-identifier" like data-type that allow that. leafrefs are used when the "target" of the reference is defined in the data model instance-identifiers are used when the "target" of the reference can be any node in the data store. They are encoded in (NETCONF) XML as defined in 6020. They *could* be encoded differently for RESTCONF. But note that when you write a value to a leafref, it is not very elegant (or useful maybe) to write a complete URL. I strongly oppose encoding-specific references - how would a data model designer know which one to use? restconf-leafref or leafref or xxx-leafref? /martin
- [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