IETF Logo Mail Archive

Re: [Netconf] Representing URLs

Martin Bjorklund <mbj@tail-f.com> Fri, 06 December 2013 21:27 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 D03B21AE09C for <netconf@ietfa.amsl.com>; Fri, 6 Dec 2013 13:27:32 -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 P3hqKVpQcCKw for <netconf@ietfa.amsl.com>; Fri, 6 Dec 2013 13:27:32 -0800 (PST)
Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E44C31AE043 for <netconf@ietf.org>; Fri, 6 Dec 2013 13:27:31 -0800 (PST)
Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 56CB037C006; Fri, 6 Dec 2013 22:27:21 +0100 (CET)
Date: Fri, 06 Dec 2013 22:27:20 +0100
Message-Id: <20131206.222720.369437985.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRHYggkrm8jYa1wjWCY7zJG-QcVjbDguQGdK8xDduOvMQ@mail.gmail.com>
References: <E67E6E74-F554-4D5A-ABFE-0C567A9743B3@nic.cz> <CAFFjW4iJVmPsoQLPMKJSJXWMbaAdpFcZvUcztqk2z+h0eFq0ww@mail.gmail.com> <CABCOCHRHYggkrm8jYa1wjWCY7zJG-QcVjbDguQGdK8xDduOvMQ@mail.gmail.com>
X-Mailer: Mew version 6.5 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: Fri, 06 Dec 2013 21:27:33 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> You have raised an important RESTCONF issue, which is the
> client processing of server resource URIs.  I think the
> client should be able to use the Location header URI for
> all CRUD access to the data resource.
> 
> That's why the /restconf/config and /restconf/operational split
> is broken. In order to retrieve operational data, the client
> has to parse the URI and change it -- not too REST-ful ;-)

RESTCONF's uri scheme is already not too REST-ful.  The uri's are
deterministic and known by both client and server.  The Location
header only works when the client has created a resource, but it
cannot be used to discover uris on the server.

The split into config and operational does not change this.


/martin

v2.23.0 | Report a Bug | By Email