Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-03.txt
Wojciech Dec <wdec.ietf@gmail.com> Fri, 10 January 2014 09:38 UTC
Return-Path: <wdec.ietf@gmail.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 8503F1A1F33 for <netconf@ietfa.amsl.com>; Fri, 10 Jan 2014 01:38:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 3uRClLv3enSU for <netconf@ietfa.amsl.com>; Fri, 10 Jan 2014 01:38:09 -0800 (PST)
Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 26A851A1F72 for <netconf@ietf.org>; Fri, 10 Jan 2014 01:38:09 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id y10so4365290pdj.37 for <netconf@ietf.org>; Fri, 10 Jan 2014 01:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bHUzjUGiw/YP/Ib09GXOPRpmuNC1+0FzdQJwGhyioEo=; b=xJqMDfSgs5zhUs6nrQ2jH3HmLUF2DzutJ08pQWIBRPgv+FMwMUOYb39CwXAAZugoFB 4juNDGrRXJbJNOB3k4SAEI764Li0wRUa6V42dXWbQE9t4ukGSmi5N8RtEn0CHlksWwl1 w4zfo741LLdV3NyhZE0sPZy2H+2bGfZ1iSs9TKwxwRpg8udgX+61zLjy8H5DjuXzICP/ llesIy4Mn+Sg+CvZ/hWu9K2nq6N/P5sB7EQVWCrrJm915GOVnAyYAlsarOarVOg4rYOR M6xV+truA5mIN1dVOmG8y3VH5gNUwQe1I81Re8JpaGNZMntXDfaQ6iozrbaqq3VdaLCb SBgw==
MIME-Version: 1.0
X-Received: by 10.66.149.231 with SMTP id ud7mr10244824pab.8.1389346679431; Fri, 10 Jan 2014 01:37:59 -0800 (PST)
Received: by 10.70.57.163 with HTTP; Fri, 10 Jan 2014 01:37:59 -0800 (PST)
In-Reply-To: <20140108.122939.2299520154335083466.mbj@tail-f.com>
References: <CAFFjW4iNBMamFFwEtbiXPjSJ2g4mi+Q_3jQ1oyFkgJd47bhcbg@mail.gmail.com> <CABCOCHQgnAQXBrgpAADk3SiOsZkg76M9Z7zeFT4UdCPdU_cXdQ@mail.gmail.com> <CAFFjW4g63nRp0yYrzW6W=UisEbH=OMHHsfV2U=xCeeq+ne0-xg@mail.gmail.com> <20140108.122939.2299520154335083466.mbj@tail-f.com>
Date: Fri, 10 Jan 2014 10:37:59 +0100
Message-ID: <CAFFjW4hdTCNtER2Aorn52JVC63vsuPZwvxJ=N-zKomVZ+-xstg@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: Martin Bjorklund <mbj@tail-f.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-03.txt
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, 10 Jan 2014 09:38:11 -0000
Hi Martin, On 8 January 2014 12:29, Martin Bjorklund <mbj@tail-f.com> wrote: > Wojciech Dec <wdec.ietf@gmail.com> wrote: >> On 6 January 2014 12:49, Andy Bierman <andy@yumaworks.com> wrote: >> > >> > >> > >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote: >> >> >> >> Hi Andy, all, >> >> >> >> are the issues leading to this draft documented somewhere? The IETF >> >> 88 minutes only talk about the yang patch aspect. >> >> >> >> Anyway, I took a read through the latest document and the change to >> >> have all Yang data-nodes be resources. Am I correct in interpreting it >> >> that now every leaf node effectively becomes a resource with a >> >> separate URI? Could the authors provide some more insight regarding >> >> this change? >> >> >> > >> > >> > >> > Since YANG Patch is now optional, there is no way to delete an optional leaf >> > or leaf-list otherwise, except to copy the entire resource, and then replace >> > the entire resource (minus the optional leaf). >> >> >> I am still not able to get the full rationale for the change. Can the >> authors or chairs provide that? >> >> Anyway, it now appears that every single data leaf is a resource, >> instead of an attribute > > Yes, every leaf is a subresource to its parent list or container. > This just means that you can GET/POST/DELETE the leaf directly, w/o > having to PATCH the parent. > >> and the spec doesn't specify a distinction >> between handling parent resources and its sub-resources, e.g. At the >> very least POST/PUT operations to sub resources need to be constrained >> by their parent resource, and leaving that up to the implementation is >> kind of a step backwards for the spec as a whole besides being IMO a >> major complication for client or server, and likely both e.g how >> should a change to a sub-resource that doesn't meet some condition of >> the parent be handled? For a single parent resource, how should >> multiple sub-resource changes be coordinated (the parent resource >> needs to be consistent)? Etc. > > I am afraid I do not understand your concern. Could you provide an > example (data model and requests) that you feel is problematic or > unclear? A simple example: container book { leaf price { type string; } leaf tax-amount { type string; } } Price and taxt are typically related. A (better) REST API design would seek to minimize transactional effects to the client while protecting the consistency/sanity of the data: To update the resource, a POST operation to foo/book would carry in the envelope both a new price and the tax amount. A (worse) REST API design would expose both price and tax-amount as separate resources, accept POST to both foo/book/price and foo/book/tax-amount and hope-for-the-best that the client succeeds and all. Several non trivial failuire scenarios come up here too. The key is that REST API design is very much about determining what is a resource, its representation by a URI, and what are the attributes of a resource. In draft -03, everything is now a resource, and everything is also attribute. This IMO ultimately complicates and bloats code (on client, server, and likely both), and will lead to brittle API and poor user experience. Another quick example: container book { list page { key page-nr; leaf page-nr {type string;} leaf text {type string;} } } The RESTConf URI for the above would <root stuff here>/book/page/{page-nr}/text In general with REST APIs it is important that we do NOT expose the dependent sub-resources directly thus allowing someone to create (POST or PUT) to <root stuff here>/book/page/{page-nr} without a book, or text without a page, or other cases that do not make sense, and in general requiring a feast of error cases. Requiring the text POST/PUT handler to also do book creation, validation, etc, is not a great design. It complicates code and creates ugly code dependencies, should the model change, etc. > >> If this current development was driven by questions/problems in the >> support of HTTP Patch operation (incl. JSON patch), the solution >> appears to be possibly worse than the supposed problem. That's why it >> would be good to understand the rationale some more. > > If the "yang patch" media type is opitonal, there is no other way to > delete optional leafs. If the optional leaf is a resource it can be > removed with DELETE. Yes, but the current "solution" is IMO a lot worse than a) mandating PATCH, and I mean plain JSON/XML PATCH or b) handling (specifying in the draft how-to do) updates via POST. Thus bringing in back the simple patch would be a good move. And the Yang patch is something that can go into another spec, I agree. Cheers, Wojciech. > > /martin
- [Netconf] Fwd: I-D Action: draft-bierman-netconf-… Andy Bierman
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Andy Bierman
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Martin Bjorklund
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Andy Bierman
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Martin Bjorklund
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Andy Bierman
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Martin Bjorklund
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Wojciech Dec
- Re: [Netconf] Fwd: I-D Action: draft-bierman-netc… Martin Bjorklund