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