From dew@tx.technion.ac.il Thu Jan 2 07:56:42 2014 Return-Path: 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 789E41AE604 for ; Thu, 2 Jan 2014 07:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 oJkvbVabIEvF for ; Thu, 2 Jan 2014 07:56:39 -0800 (PST) Received: from mailgw12.technion.ac.il (mailgw12.technion.ac.il [132.68.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 43CBB1ADF83 for ; Thu, 2 Jan 2014 07:56:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwCAFCLxVKERAEijGdsb2JhbABYg0NVgn+uRIg3Fg4BAQEnPIJPFXYCJgIuiEgNmUaPD5VWhGqBKY4RgliBSASUM4NjgTGPD4UE X-IPAS-Result: AvwCAFCLxVKERAEijGdsb2JhbABYg0NVgn+uRIg3Fg4BAQEnPIJPFXYCJgIuiEgNmUaPD5VWhGqBKY4RgliBSASUM4NjgTGPD4UE X-IronPort-AV: E=Sophos;i="4.95,591,1384293600"; d="scan'208";a="87366657" Received: from webmail.technion.ac.il ([132.68.1.34]) by mailgw12.technion.ac.il with ESMTP; 02 Jan 2014 17:56:30 +0200 Received: by webmail.technion.ac.il (Postfix, from userid 48) id BD975100136; Thu, 2 Jan 2014 17:56:30 +0200 (IST) Received: from galiil.marvell.com (galiil.marvell.com [199.203.130.254]) by webmail.technion.ac.il (Horde Framework) with HTTP; Thu, 02 Jan 2014 17:56:30 +0200 Date: Thu, 02 Jan 2014 17:56:30 +0200 Message-ID: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> From: Tal Mizrahi To: netconf@ietf.org User-Agent: Internet Messaging Program (IMP) H5 (6.1.3) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Netconf] Updated draft-mm-netconf-time-capability-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jan 2014 15:56:42 -0000 Hi, We have posted an updated draft: http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 Thanks to all the people who reviewed and sent comments about draft 00. Here is a summary of the changes compared to draft 00: - We have added discussion about the scheduling tolerance: an upper bound on how far into the future/past an RPC can be scheduled. - The scheduled time now refers to the *start* time of the operation, rather than to its completion. - The time format has been changed to date-and-time. There is a key issue that we would like to raise. There is a well-known distinction between *hard* real-time and *soft* real-time scheduling; hard-real time implies that if one of the servers does not perform the scheduled operations on time the system may fail, whereas soft real-time means that the system will perform better if all the servers invoke the operations on time, but nothing breaks even if they don=E2=80=99t. We received quite a bit of comments and questions, that we believe are more relevant to the *hard* real-time case, for example: what happens if a server is unable to schedule the RPC to the scheduled time? is there a way to remove pending scheduled operations? What if the NACM rules change while the operation is pending? What if the server reboots while operations are pending? We believe the current draft allows soft real-time scheduling, i.e., it provides the tools to schedule an RPC without strict guarantees. An implicit assumption here is that RPCs are scheduled to near-future deadlines (e.g., on the order of seconds in the future), which allows a long enough time for the NETCONF message to be delivered to the server, but not enough time for (or a very low probability of) significant changes in the server, such as NACM rule changes, or server restart. At this point, draft 01 is soft-real-time-oriented. We are interested to hear feedback about whether there is an interest in the working group to develop the hard real-time functionality as well. Regards, Tal Mizrahi. From mehmet.ersue@nsn.com Sat Jan 4 04:37:05 2014 Return-Path: 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 72ADD1ADF77 for ; Sat, 4 Jan 2014 04:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 kITyz4JURqox for ; Sat, 4 Jan 2014 04:37:02 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B94021ADE8A for ; Sat, 4 Jan 2014 04:37:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s04Caox5000374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Jan 2014 13:36:50 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s04CaoRE018742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 4 Jan 2014 13:36:50 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 4 Jan 2014 13:36:49 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Sat, 4 Jan 2014 13:36:49 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Benoit Claise Thread-Topic: Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8A== Date: Sat, 4 Jan 2014 12:36:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8248A33DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 21152 X-purgate-ID: 151667::1388839010-000025D0-10CC30A0/0-0/0-0 Cc: Netconf Subject: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jan 2014 12:37:05 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8248A33DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, hope you had restful holidays. Below is the charter proposal we prepared following the consensus calls and= review of the draft charter text, basically adding to the WG item list poi= nt 3. for the joint server configuration data model and point 4. for RESTCO= NF. We would like to ask you to initiate the re-chartering and the approval by = the IESG. Thank you. Bert & Mehmet --------------- Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Benoit Claise Joel Jaeggli Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol has the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting- related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimiz= e configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS = is an optional transport. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring th= e Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol is data modeling language independent, but YANG is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. 3. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate YANG module. 4. Develop a RESTful interface (RESTCONF) for accessing YANG data using the datastores defined in NETCONF. The YANG patch operation will be prepa= red in a separate draft. Goals and Milestones: Jan 2014 - Submit initial WG drafts for RESTCONF as WG item Apr 2014 - WGLC for RFC5539bis Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for NETCONF server configuration data model May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed St= andard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Sta= ndard Jun 2014 - WGLC for RESTCONF drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Stand= ard --_000_E4DE949E6CE3E34993A2FF8AE79131F8248A33DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Benoit,
 
hope you had restful holidays.
 
Below is the charter proposal we prepared following the consensus call= s and review of the draft charter text, basically adding to the WG item lis= t point 3. for the joint server configuration data model and point 4. for R= ESTCONF.
 
We would like to ask you to initiate the re-chartering and the approva= l by the IESG. Thank you.
 
Bert & Mehmet
 
 
--------------- 
 
= Network Configuration (netconf)
= -------------------------------
=  
= Charter
=  
= Current Status: Active
=  
= Chairs:
=      Bert Wijnen <bertietf@bwijnen.net>
=      Mehmet Ersue <mehmet.ersue@nsn.com>
=  
= Operations and Management Area Directors:
=      Benoit Claise <bclaise@cisco.com>
=      Joel Jaeggli <joelja@bogus.com>
=  
= Operations and Management Area Advisor:
=      Benoit Claise <bclaise@cisco.com>
=  
= Mailing Lists:
=      General Discussion: netconf@ietf.org=
=      To Subscribe:       https://www.ietf.= org/mailman/listinfo/netconf
=      Archive:       =      http://www.ietf.o= rg/mail-archive/web/netconf/
=  
= Description of Working Group:
=  
=   Configuration of networks of devices has become a critical requireme= nt
=   for operators in today's highly interconnected networks. Large and s= mall
=   operators alike have developed their own mechanisms or have used ven= dor
=   specific mechanisms to transfer configuration data to and from a dev= ice
=   and to examine device state information which may impact the<= /font>
=   configuration. Each of these mechanisms may be different in various<= /span>
=   aspects, such as session establishment, user authentication,<= /font>
=   configuration data exchange, and error responses.
=  
=   The NETCONF protocol has the following characteristics:
=  
=     - Provides retrieval mechanisms which can differentiate = between
=     configuration data and non-configuration data
=     - Is extensible enough so that vendors can provide acces= s to all
=     configuration data on the device using a single protocol=
=     - Has a programmatic interface (avoids screen scraping a= nd formatting-
=     related changes between releases)
=     - Uses an XML-based data representation, that can be eas= ily manipulated
=     using non-specialized XML manipulation tools.
=     - Supports integration with existing user authentication= methods
=     - Supports integration with existing configuration datab= ase systems
=     - Supports multiple (e.g. candidate and running) data-st= ores to optimize
=     configuration preparation and activation
=     - Supports network wide configuration transactions (with= features such
=     as locking and rollback capability)
=    - Runs over a secure transport; SSH is mandatory to implement = while TLS is an optional transport.
=     - Provides support for asynchronous notifications.
=     - Supports an Access Control Model and a YANG module for= configuring the
=     Access Control parameters.
=     - Supports a YANG module for System Notifications=
=  
=  
=   The NETCONF protocol is data modeling language independent, but YANG= is
=   the recommended NETCONF modeling language, which introduces advanced=
=   language features for configuration management.
=  
=   Based on the implementation, deployment experience and interoperabil= ity
=   testing, the WG aims to produce a NETCONF status report in a later s= tage.
=   The result may be clarifications for RFC6241 and RFC6242 and address= ing
=   any reported errata.
=  
=   In the current phase of NETCONF's incremental development the workgr= oup
=   will focus on following items:
=  
=   1. Develop the call home mechanism for the mandatory SSH binding (Re= verse
=   SSH) providing a server-initiated session establishment.
=  
=   2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., up= date
=   RFC 5539) and add the call home mechanism to provide a server-initia= ted
=   session establishment.
=  
=   3. Combine the server configuration data models from Reverse SSH and=
=   RFC5539bis drafts in a separate YANG module.
=  
=   4. Develop a RESTful interface (RESTCONF) for accessing YANG data us= ing
=   the datastores defined in NETCONF. The YANG patch operation will be = prepared
=   in a separate draft.
=  
=  
= Goals and Milestones:
=   Jan 2014 - Submit initial WG drafts for RESTCONF as WG item <= /font>
=   Apr 2014 - WGLC for RFC5539bis
=   Apr 2014 - WGLC for Reverse SSH
=   Apr 2014 - WGLC for NETCONF server configuration data model <= /font>
=   May 2014 - Submit Reverse SSH to AD/IESG for consideration as Propos= ed Standard
=   May 2014 - Submit RFC5539bis to AD/IESG for consideration as Propose= d Standard
=   Jun 2014 - WGLC for RESTCONF drafts
=   Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed = Standard 
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8248A33DEMUMBX005nsnintr_-- From wdec.ietf@gmail.com Mon Jan 6 03:33:22 2014 Return-Path: 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 982251AE00C for ; Mon, 6 Jan 2014 03:33:22 -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 nm1dJq9AWzo0 for ; Mon, 6 Jan 2014 03:33:20 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 320F21ADFFE for ; Mon, 6 Jan 2014 03:33:20 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so18507547pbb.3 for ; Mon, 06 Jan 2014 03:33:12 -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=DyFkmfr6DzkyBldgKzW2HI7cTirabxjo7BcIzZJmfxs=; b=pZVve0utMfOMB6rAYzSvD4sC7QaF3CyWwn3iQzWvt6poqy+Qqma3v0W7zC5jfnyEKO XWL7XvOIJytZ3/WOrpdk5Vf4MUbyYDupSKONsjwR1xBVj+4awvCw5VgQDuQ680XUQ9GH NK+sREAZzAbz1A+ruK/LKym5LVSnWWR0nW6FHbLV0ZdKVsW9Y06zmLfGnvHkn/NrkpU5 fxdxVjquptQJ6JpGoqAAiCJH70Juk/Ol0syA4NgbXp0ssNw34f56zWvdfWkqKeNV0RM9 WJLpWy6g+rMaajNyavkh9gNP6PX6OxxuoUAdk+0Okf4pfePlCYnp+iTpmnA1eIRMXk61 oAgg== MIME-Version: 1.0 X-Received: by 10.68.252.5 with SMTP id zo5mr126549565pbc.10.1389007991797; Mon, 06 Jan 2014 03:33:11 -0800 (PST) Received: by 10.70.57.163 with HTTP; Mon, 6 Jan 2014 03:33:11 -0800 (PST) In-Reply-To: References: <20131221202305.29593.70148.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 12:33:11 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:33:22 -0000 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? An unfortunate characteristic, introduced in -02, that still persists in -03 is the configuration and operational split. But we discussed that on a separate thread.... Regards, Wojciech. On 21 December 2013 21:26, Andy Bierman wrote: > FYI, > > This version of RESTCONF addresses many of the issues raised at the last > IETF. > See the change log for details. > > > Andy > > > ---------- Forwarded message ---------- > From: > Date: Sat, Dec 21, 2013 at 12:23 PM > Subject: I-D Action: draft-bierman-netconf-restconf-03.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : RESTCONF Protocol > Authors : Andy Bierman > Martin Bjorklund > Kent Watsen > Rex Fernando > Filename : draft-bierman-netconf-restconf-03.txt > Pages : 95 > Date : 2013-12-21 > > Abstract: > This document describes a RESTful protocol that provides a > programmatic interface over HTTP for accessing data defined in YANG, > using the datastores defined in NETCONF. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-bierman-netconf-restconf-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Mon Jan 6 03:50:00 2014 Return-Path: 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 6B2761A1F78 for ; Mon, 6 Jan 2014 03:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CtfSa3Q3sGOF for ; Mon, 6 Jan 2014 03:49:58 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE91A1F74 for ; Mon, 6 Jan 2014 03:49:58 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id w7so17449129qcr.11 for ; Mon, 06 Jan 2014 03:49:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Sfqoqk6QjNhQoPfRFxWKKC+5I3dTWukwQONyD0jlBIM=; b=l5H2ynVSnxNtydeWhKDGf3ee5AhnfPzU52a4GKT9iRglWSSoQVJ4PzPAJfKztKzh5v uvbRgQkcLOXUFNqvnFbqkxK/qTjjoE3pm1ZSxUYa9JphjLJ3JPd7s8JECXfkMtC+tHtm KwAxE/NYaIGN1G8eI/gVBVmGBRFOTR701tTVN6cRDql6CO+DjrqMFnnVNDoxGit950os VRqrlXGgdaoXnYxvpnkQ0S8lVWKB95kfSSE2OOYAzGWdQSRTrhc5rPaK1jqB1kJabHnr hYfa21h3Z3aihTdTjzL+uOmxYwJI3MPPcn89ojYeYy8fTAa3yPBsyPOVX/ZMqOmcoxTK eeGA== X-Gm-Message-State: ALoCoQlgXfoNJHQFhttF5hjSNBS35FmzcUm8gGmBwLVxneVBwVUW0l/AAZ1gwHB9U66+URAx+Q+8 MIME-Version: 1.0 X-Received: by 10.49.76.66 with SMTP id i2mr187411187qew.35.1389008989560; Mon, 06 Jan 2014 03:49:49 -0800 (PST) Received: by 10.140.48.75 with HTTP; Mon, 6 Jan 2014 03:49:49 -0800 (PST) In-Reply-To: References: <20131221202305.29593.70148.idtracker@ietfa.amsl.com> Date: Mon, 6 Jan 2014 03:49:49 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bea3f4c69bebd04ef4bdb35 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 11:50:00 -0000 --047d7bea3f4c69bebd04ef4bdb35 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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). > > An unfortunate characteristic, introduced in -02, that still persists > in -03 is the configuration and operational split. But we discussed > that on a separate thread.... > The split is removed. The content query parameter is used to pick config, non-config or both. > > Regards, > Wojciech. > Andy > > On 21 December 2013 21:26, Andy Bierman wrote: > > FYI, > > > > This version of RESTCONF addresses many of the issues raised at the last > > IETF. > > See the change log for details. > > > > > > Andy > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Sat, Dec 21, 2013 at 12:23 PM > > Subject: I-D Action: draft-bierman-netconf-restconf-03.txt > > To: i-d-announce@ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : RESTCONF Protocol > > Authors : Andy Bierman > > Martin Bjorklund > > Kent Watsen > > Rex Fernando > > Filename : draft-bierman-netconf-restconf-03.txt > > Pages : 95 > > Date : 2013-12-21 > > > > Abstract: > > This document describes a RESTful protocol that provides a > > programmatic interface over HTTP for accessing data defined in YANG, > > using the datastores defined in NETCONF. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-bierman-netconf-restconf-03 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-03 > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > --047d7bea3f4c69bebd04ef4bdb35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec <= wdec.ietf@gmail.co= m> wrote:
Hi Andy, all,

are the issues leading to this draft =A0documented 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 =A0every leaf node =A0effectively becomes a resource with a
separate URI? Could the authors provide some more insight regarding
this change?
=A0


Since YA= NG Patch is now optional, there is no way to delete an optional leaf
<= div>or leaf-list otherwise, except to copy the entire resource, and then re= place
the entire resource (minus the optional leaf).


=A0

An unfortunate characteristic, introduced in -02, that still persists
in -03 is the configuration and operational split. But we discussed
that on a separate thread....

The split= is removed. The content query parameter is used to pick
config, = non-config or both.

=A0

Regards,
Wojciech.

Andy
=A0

On 21 December 2013 21:26, Andy Bierman <andy@yumaworks.com> wrote:
> FYI,
>
> This version of RESTCONF addresses many of the issues raised at the la= st
> IETF.
> See the change log for details.
>
>
> Andy
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@= ietf.org>
> Date: Sat, Dec 21, 2013 at 12:23 PM
> Subject: I-D Action: draft-bierman-netconf-restconf-03.txt
> To: i-d-announce@ietf.org=
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Andy Bierman
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
> =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restco= nf-03.txt
> =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 95
> =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-21
>
> Abstract:
> =A0 =A0This document describes a RESTful protocol that provides a
> =A0 =A0programmatic interface over HTTP for accessing data defined in = YANG,
> =A0 =A0using the datastores defined in NETCONF.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bierman-net= conf-restconf/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bierman-netconf-restc= onf-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-bierm= an-netconf-restconf-03
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--047d7bea3f4c69bebd04ef4bdb35-- From wdec.ietf@gmail.com Wed Jan 8 02:35:28 2014 Return-Path: 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 DBB6F1AE223 for ; Wed, 8 Jan 2014 02:35:28 -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 X6LtxXhZmRBH for ; Wed, 8 Jan 2014 02:35:27 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E7E781AE1D2 for ; Wed, 8 Jan 2014 02:35:26 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so1405518pbc.15 for ; Wed, 08 Jan 2014 02:35:18 -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=UTv9fFFCm8asreU+UN8HJx1KPhv6YVyhJgWGQRS/tg0=; b=J4AenxrfbBACSeU1zKOl+JeEbgNrK/TZ4NrkNoQJZbkpFhVqDrDLnMMzKjXMy4v0jM YvnOJnSW9tjELSR5lgfbmYZoLRI60F4VbfifPyE0qUvnZQQgFt8FEcov7zX4OIw38mM2 hGzNGv6U7L45GRFAQiuepbV0k45M1i7IRiC1lPc/inz4HI+to94VFafnZMzwOjR6rUUz fzE9eGQaD3CoCHvARVt+dR87lJp++J8ui1F+pA3+e59g+bcfWxc2AT5UdvEbsLTKvJt9 izuLzSh99QeZ21u+dgvrreMk80TGk3ObLTUp5zEVRY8JoFt/sAgXgeDd4+xxrIB5QzJr Zt7A== MIME-Version: 1.0 X-Received: by 10.66.26.179 with SMTP id m19mr8474082pag.15.1389177317927; Wed, 08 Jan 2014 02:35:17 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 8 Jan 2014 02:35:17 -0800 (PST) In-Reply-To: References: <20131221202305.29593.70148.idtracker@ietfa.amsl.com> Date: Wed, 8 Jan 2014 11:35:17 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 10:35:29 -0000 On 6 January 2014 12:49, Andy Bierman wrote: > > > > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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, 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. 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. > > >> >> >> >> An unfortunate characteristic, introduced in -02, that still persists >> in -03 is the configuration and operational split. But we discussed >> that on a separate thread.... > > > The split is removed. The content query parameter is used to pick > config, non-config or both. > > Ah, yes, see that now. Glad that email discussion helped. Thanks. >> >> >> Regards, >> Wojciech. > > > Andy > >> >> >> On 21 December 2013 21:26, Andy Bierman wrote: >> > FYI, >> > >> > This version of RESTCONF addresses many of the issues raised at the last >> > IETF. >> > See the change log for details. >> > >> > >> > Andy >> > >> > >> > ---------- Forwarded message ---------- >> > From: >> > Date: Sat, Dec 21, 2013 at 12:23 PM >> > Subject: I-D Action: draft-bierman-netconf-restconf-03.txt >> > To: i-d-announce@ietf.org >> > >> > >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories. >> > >> > >> > Title : RESTCONF Protocol >> > Authors : Andy Bierman >> > Martin Bjorklund >> > Kent Watsen >> > Rex Fernando >> > Filename : draft-bierman-netconf-restconf-03.txt >> > Pages : 95 >> > Date : 2013-12-21 >> > >> > Abstract: >> > This document describes a RESTful protocol that provides a >> > programmatic interface over HTTP for accessing data defined in YANG, >> > using the datastores defined in NETCONF. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-bierman-netconf-restconf-03 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-03 >> > >> > >> > Please note that it may take a couple of minutes from the time of >> > submission >> > until the htmlized version and diff are available at tools.ietf.org. >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > I-D-Announce mailing list >> > I-D-Announce@ietf.org >> > https://www.ietf.org/mailman/listinfo/i-d-announce >> > Internet-Draft directories: http://www.ietf.org/shadow.html >> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> > > > From mbj@tail-f.com Wed Jan 8 03:29:52 2014 Return-Path: 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 22D921AE247 for ; Wed, 8 Jan 2014 03:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 eWAJTPaO6HDr for ; Wed, 8 Jan 2014 03:29:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 478241AE1D7 for ; Wed, 8 Jan 2014 03:29:50 -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 A2EE6240C20B; Wed, 8 Jan 2014 12:29:39 +0100 (CET) Date: Wed, 08 Jan 2014 12:29:39 +0100 (CET) Message-Id: <20140108.122939.2299520154335083466.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 11:29:52 -0000 Wojciech Dec wrote: > On 6 January 2014 12:49, Andy Bierman wrote: > > > > > > > > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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? > 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. /martin From wdec.ietf@gmail.com Fri Jan 10 01:38:11 2014 Return-Path: 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 ; 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 ; 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 ; Fri, 10 Jan 2014 01:38:09 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y10so4365290pdj.37 for ; 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: <20140108.122939.2299520154335083466.mbj@tail-f.com> Date: Fri, 10 Jan 2014 10:37:59 +0100 Message-ID: From: Wojciech Dec To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 09:38:11 -0000 Hi Martin, On 8 January 2014 12:29, Martin Bjorklund wrote: > Wojciech Dec wrote: >> On 6 January 2014 12:49, Andy Bierman wrote: >> > >> > >> > >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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 /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 /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 From andy@yumaworks.com Fri Jan 10 02:38:10 2014 Return-Path: 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 D0AAE1A8033 for ; Fri, 10 Jan 2014 02:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZVzq56yKseih for ; Fri, 10 Jan 2014 02:38:05 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id C67D71AC7F1 for ; Fri, 10 Jan 2014 02:38:04 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id i13so3907243qae.35 for ; Fri, 10 Jan 2014 02:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h3E+ZVFEHPdpBmEGtxBmNo8RxNmlCbbhllBEkqHUemA=; b=b+Ha4lQWDTZCSMBkI2yPcZDQB7G5RaiFXkedUkorzecyGt3YSY4CKVvi9S859f2qAa EtO2kI2LL7EiuzxNmPme+Mox0U7ii0Vz6sAX/c2o47gp3YeGm01v/PTxcn+cbwpauhaQ naqHGcvKOge4N/mGVx0R8lLGJn7mLoPrdYiEUduUJiPMgATsTNapjz5dqWOGgTcneB0y M2qA17D9u6sLv13KIbGAhcT/OIhCObJ/rf/Ihj8Gnx3uV/soAUV3/xYxpExaeiPe8YMG 3Mk7jiH/7MIVAB0+2+g5fMehREunr8hIuBjrRRt0jynTjgqDkHiYDFle3dyCfs3idUYG nChg== X-Gm-Message-State: ALoCoQmp4ohdJ2Vv9Ua3keKRhiZ7DM5Z/OoxH/aBr8RDb2xSk+GZc1LfDCos1vWWGAkylnqx/VRt MIME-Version: 1.0 X-Received: by 10.49.2.170 with SMTP id 10mr5826758qev.24.1389350274674; Fri, 10 Jan 2014 02:37:54 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 10 Jan 2014 02:37:54 -0800 (PST) In-Reply-To: References: <20140108.122939.2299520154335083466.mbj@tail-f.com> Date: Fri, 10 Jan 2014 02:37:54 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7b6da3d49747de04ef9b5108 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 10:38:11 -0000 --047d7b6da3d49747de04ef9b5108 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec wrote: > Hi Martin, > > On 8 January 2014 12:29, Martin Bjorklund wrote: > > Wojciech Dec wrote: > >> On 6 January 2014 12:49, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > 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 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 /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. > > Plain PATCH does not allow an optional leaf to be deleted. JSON patch does not work well with named data like YANG. Ignoring YANG naming and using integer indices that renumber every time a list is changed is a non-starter. The only way to delete an optional leaf is to GET the entire parent resource, edit it offline (remove the leaf) and PUT the parent resource. This is operationally disruptive and expensive to implement in the server. Optional leafs make up most configuration data, so a CM solution that doesn't work well for optional leafs is a bad idea. > Cheers, > Wojciech. > Andy > > > > /martin > --047d7b6da3d49747de04ef9b5108 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
Hi Martin,

On 8 January 2014 12:29, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmai= l.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 =A0documented somewh= ere? 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 in= terpreting it
>> >> that now =A0every leaf node =A0effectively becomes a reso= urce 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 a= n optional leaf
>> > or leaf-list otherwise, except to copy the entire resource, a= nd then replace
>> > the entire resource (minus the optional leaf).
>>
>>
>> I am still not able to get the full rationale for the change. =A0C= an the
>> authors or chairs provide that?
>>
>> Anyway, it now appears that every single data leaf is a resource,<= br> >> 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 t= he
>> very least POST/PUT operations to sub resources need to be constra= ined
>> by their parent resource, and leaving that up to the implementatio= n 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 condi= tion of
>> the parent be handled? For a single parent resource, how should >> multiple sub-resource changes be coordinated (the parent resource<= br> >> needs to be consistent)? Etc.
>
> I am afraid I do not understand your concern. =A0Could you provide an<= br> > example (data model and requests) that you feel is problematic or
> unclear?


A simple example:

=A0 =A0 container book {

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf price {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf tax-amount {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

=A0 =A0 =A0}

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, =A0its 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:


=A0 =A0 container book {

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list page {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key page-nr;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf page-nr {type string;}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf text {type string;}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0}

The RESTConf URI for the above would <root stuff here>/book/page/{pag= e-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} =A0without a book, o= r
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 =A0handler 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 th= e
>> 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 othe= r way to
> delete optional leafs. =A0If the optional leaf is a resource it can be=
> removed with DELETE.

Yes, but the current "solution" is IMO a lot worse than a) mandat= ing
PATCH, and I mean plain JSON/XML PATCH =A0or 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.



Plain PATCH does not al= low an optional leaf to be deleted.
JSON patch does not work well= with named data like YANG.
Ignoring YANG naming and using intege= r indices that renumber
every time a list is changed is a non-starter. =A0The only way to
delete an optional leaf is to GET the entire parent resource,
edit it offline (remove the leaf) and PUT the parent resource.
This is operationally disruptive and expensive to implement
in th= e server. =A0Optional leafs make up most configuration data,
so a= CM solution that doesn't work well for optional leafs is a bad idea.

=A0
Cheers,
Wojciech.


Andy
=A0
>
> /martin

--047d7b6da3d49747de04ef9b5108-- From wwwrun@rfc-editor.org Fri Jan 10 05:32:45 2014 Return-Path: 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 1606E1ADE72 for ; Fri, 10 Jan 2014 05:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 qXg4aoByEZvA for ; Fri, 10 Jan 2014 05:32:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 684091ADBFF for ; Fri, 10 Jan 2014 05:32:43 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 926097FC394; Fri, 10 Jan 2014 05:32:33 -0800 (PST) To: andy@yumaworks.com, mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20140110133233.926097FC394@rfc-editor.org> Date: Fri, 10 Jan 2014 05:32:33 -0800 (PST) Cc: netconf@ietf.org, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC6536 (3862) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:32:45 -0000 The following errata report has been submitted for RFC6536, "Network Configuration Protocol (NETCONF) Access Control Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3862 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 3.5.2. Original Text ------------- typedef matchall-string-type { type string { pattern "\*"; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } Corrected Text -------------- typedef matchall-string-type { type string { pattern '\*'; } description "The string containing a single asterisk '*' is used to conceptually represent all possible values for the particular leaf using this data type."; } Notes ----- As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6536 (draft-ietf-netconf-access-control-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Access Control Model Publication Date : March 2012 Author(s) : A. Bierman, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Fri Jan 10 05:32:50 2014 Return-Path: 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 C03231ADFC8 for ; Fri, 10 Jan 2014 05:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 Mf9buMD4okdb for ; Fri, 10 Jan 2014 05:32:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id EAE931ADFBC for ; Fri, 10 Jan 2014 05:32:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2CB797FC398; Fri, 10 Jan 2014 05:32:39 -0800 (PST) To: andy@yumaworks.com, mbj@tail-f.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20140110133239.2CB797FC398@rfc-editor.org> Date: Fri, 10 Jan 2014 05:32:39 -0800 (PST) Cc: netconf@ietf.org, jernej.tuljak@mg-soft.com, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] RFC6536 (3863) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:32:51 -0000 The following errata report has been submitted for RFC6536, "Network Configuration Protocol (NETCONF) Access Control Model". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3863 -------------------------------------- Type: Technical Reported by: Jernej Tuljak Section: 3.5.2. Original Text ------------- typedef group-name-type { type string { length "1..max"; pattern "[^\*].*"; } description "Name of administrative group to which users can be assigned."; } Corrected Text -------------- typedef group-name-type { type string { length "1..max"; pattern '[^\*].*'; } description "Name of administrative group to which users can be assigned."; } Notes ----- As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6536 (draft-ietf-netconf-access-control-07) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Access Control Model Publication Date : March 2012 Author(s) : A. Bierman, M. Bjorklund Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From wdec.ietf@gmail.com Fri Jan 10 05:39:29 2014 Return-Path: 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 7AD7F1ADFB4 for ; Fri, 10 Jan 2014 05:39:29 -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 Uwphl9jDrMM1 for ; Fri, 10 Jan 2014 05:39:27 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 121411ADE72 for ; Fri, 10 Jan 2014 05:39:27 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id kx10so909137pab.39 for ; Fri, 10 Jan 2014 05:39:17 -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=51+c7Z1qOHjQg5/ER5Zbzxa3ZcHa0qHax5iPv5dpUxE=; b=UxmXxucS7f4pqQtvGoZDvkbedyIfyqX4m7/8U+FCqL73ERE1C4KBZlgtvW/mwYhiOa QNZCxvVWpYF34DC0740pkl5X1Xr4ngFhzGYIIYyK3ngpa6MwPOtOEjD6d5BLR2LDII4s S266psGfG3WIZW2/US2Hm3Z0G0zuVzS4qCfLd7fE3KwcNe97KlkVryFNK0iMSB3x0/wE Tep5XPcaCyhHzyMmM1CJQCzIAI0ZIBrumV9rPXXDqpvUxfMWOYBnJAWCkjAM4zq/SgBE a22KoYS6X1gk4vuHlB47l/GHe0pYC+4Q6iNFanDa7rMkIH0GGKI9tWDrfYg4n2pvUsqC HWxw== MIME-Version: 1.0 X-Received: by 10.68.247.6 with SMTP id ya6mr11341845pbc.45.1389361156710; Fri, 10 Jan 2014 05:39:16 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 10 Jan 2014 05:39:16 -0800 (PST) In-Reply-To: References: <20140108.122939.2299520154335083466.mbj@tail-f.com> Date: Fri, 10 Jan 2014 14:39:16 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:39:29 -0000 On 10 January 2014 11:37, Andy Bierman wrote: > > > > On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec wrote: >> >> Hi Martin, >> >> On 8 January 2014 12:29, Martin Bjorklund wrote: >> > Wojciech Dec wrote: >> >> On 6 January 2014 12:49, Andy Bierman wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >> >> > 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 > 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 /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. >> > > > Plain PATCH does not allow an optional leaf to be deleted. > JSON patch does not work well with named data like YANG. > Ignoring YANG naming and using integer indices that renumber > every time a list is changed is a non-starter. The only way to > delete an optional leaf is to GET the entire parent resource, > edit it offline (remove the leaf) and PUT the parent resource. > This is operationally disruptive and expensive to implement > in the server. Optional leafs make up most configuration data, > so a CM solution that doesn't work well for optional leafs is a bad idea. I should have been clearer: Media Type discussion aside, I meant JSON patch as in "json patch for json reresented yang data", ie likely a subset of pure 'application/json-patch+json', with yang-patch being in some other doc. . The fact that JSON patch does not work for xml is, for me at least, not an issue. A simple answer can thus be that the patch is for json only. In general, I don't quite follow why you say that json patch doesn't allow for leaf deletion; the "remove" op seems to be pretty much intended for that. Gee, the json (yang) patch could even be just limited to just this task. That said, a solution to the " how to delete an optional leaf" problem that ends up treating every data item in the system to a resource, with no way for the designer to override, appears also as a bad idea. Given that we have a full API spec here, even adding a custom parameterized operation to the URI may be a better solution. Also, evidence from the REST API world out there also indicates that for better or worse, GET and PUT do actually work at scale. I would still see this still as easier to deal with and implement than having every single (sub-resource) data item as a resource.... So, in summary, "conservative" options, all leading to getting the spec back from resource extremes as I see can be: 1. Stay with GET and PUT (I suspect that this is what will get most use anyway). 2. Introduce JSON patching, in the form of say "application/yang-json-patch" to the spec (happy to work up some text) 3. Get back the "full" yang patch from draft -02 4. Introduce a new action/operation invoked via a parameter. Thoughts? Cheers. > > >> >> Cheers, >> Wojciech. > > > > Andy > >> >> > >> > /martin > > From mbj@tail-f.com Fri Jan 10 05:40:50 2014 Return-Path: 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 A615B1AE012 for ; Fri, 10 Jan 2014 05:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 FgfW1NZXgzeW for ; Fri, 10 Jan 2014 05:40:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id EF6D61ADE72 for ; Fri, 10 Jan 2014 05:40:48 -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 4C476240C11A; Fri, 10 Jan 2014 14:40:38 +0100 (CET) Date: Fri, 10 Jan 2014 14:40:38 +0100 (CET) Message-Id: <20140110.144038.1958728126349068530.mbj@tail-f.com> To: rfc-editor@rfc-editor.org From: Martin Bjorklund In-Reply-To: <20140110133233.926097FC394@rfc-editor.org> References: <20140110133233.926097FC394@rfc-editor.org> 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: joelja@bogus.com, netconf@ietf.org, jernej.tuljak@mg-soft.com Subject: Re: [Netconf] [Technical Errata Reported] RFC6536 (3862) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:40:50 -0000 Hi, This errata should be rejected. "\*" is equvalent to '\*'. \* in a double quoted string is not an escape sequence, which means that the characters are interpreted literally, i.e. the two characters \ followed by *. The same goes for errata 3863. /martin RFC Errata System wrote: > The following errata report has been submitted for RFC6536, > "Network Configuration Protocol (NETCONF) Access Control Model". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3862 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 3.5.2. > > Original Text > ------------- > typedef matchall-string-type { > type string { > pattern "\*"; > } > description > "The string containing a single asterisk '*' is used > to conceptually represent all possible values > for the particular leaf using this data type."; > } > > Corrected Text > -------------- > typedef matchall-string-type { > type string { > pattern '\*'; > } > description > "The string containing a single asterisk '*' is used > to conceptually represent all possible values > for the particular leaf using this data type."; > } > > Notes > ----- > As per RFC6020, Section 6.1.3., a backslash within a double-quoted > string introduces a special character. The only valid escape sequences > inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not > a valid escape sequence, a single quoted string should be used to > specify the offending pattern statement's argument. The quotes could > also be omitted. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6536 (draft-ietf-netconf-access-control-07) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) Access Control Model > Publication Date : March 2012 > Author(s) : A. Bierman, M. Bjorklund > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From jernej.tuljak@mg-soft.si Fri Jan 10 05:59:31 2014 Return-Path: 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 301801AE064 for ; Fri, 10 Jan 2014 05:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 VgQvSCNSbwxf for ; Fri, 10 Jan 2014 05:59:28 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 62E9E1AE062 for ; Fri, 10 Jan 2014 05:59:28 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id s0ADwCrx009171; Fri, 10 Jan 2014 14:58:12 +0100 Message-ID: <52CFFC73.3010002@mg-soft.com> Date: Fri, 10 Jan 2014 14:58:11 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Martin Bjorklund References: <20140110133233.926097FC394@rfc-editor.org> <20140110.144038.1958728126349068530.mbj@tail-f.com> In-Reply-To: <20140110.144038.1958728126349068530.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: joelja@bogus.com, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6536 (3862) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 13:59:31 -0000 If this is true, then it is RFC6020 that needs a clarification on this. Namely, that the "special character" which follows a backslash need not be special and that it does not represent an escape sequence in such a case. Within a double-quoted string (enclosed within " "), a backslash character introduces a special character, which depends on the character that immediately follows the backslash: \n new line \t a tab character \" a double quote \\ a single backslash My reading is that a backslash starts a YANG escape sequence and may therefore be removed during string dequoting. A "\*" ends up as *, which is not equivalent to '\*'. Please move this discussion over to NETMOD it that's the case. Jernej Dne 10.1.2014 14:40, piše Martin Bjorklund: > Hi, > > This errata should be rejected. "\*" is equvalent to '\*'. \* in a > double quoted string is not an escape sequence, which means that the > characters are interpreted literally, i.e. the two characters \ > followed by *. > > The same goes for errata 3863. > > /martin > > RFC Errata System wrote: >> The following errata report has been submitted for RFC6536, >> "Network Configuration Protocol (NETCONF) Access Control Model". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3862 >> >> -------------------------------------- >> Type: Technical >> Reported by: Jernej Tuljak >> >> Section: 3.5.2. >> >> Original Text >> ------------- >> typedef matchall-string-type { >> type string { >> pattern "\*"; >> } >> description >> "The string containing a single asterisk '*' is used >> to conceptually represent all possible values >> for the particular leaf using this data type."; >> } >> >> Corrected Text >> -------------- >> typedef matchall-string-type { >> type string { >> pattern '\*'; >> } >> description >> "The string containing a single asterisk '*' is used >> to conceptually represent all possible values >> for the particular leaf using this data type."; >> } >> >> Notes >> ----- >> As per RFC6020, Section 6.1.3., a backslash within a double-quoted >> string introduces a special character. The only valid escape sequences >> inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not >> a valid escape sequence, a single quoted string should be used to >> specify the offending pattern statement's argument. The quotes could >> also be omitted. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6536 (draft-ietf-netconf-access-control-07) >> -------------------------------------- >> Title : Network Configuration Protocol (NETCONF) Access Control Model >> Publication Date : March 2012 >> Author(s) : A. Bierman, M. Bjorklund >> Category : PROPOSED STANDARD >> Source : Network Configuration >> Area : Operations and Management >> Stream : IETF >> Verifying Party : IESG >> From wdec.ietf@gmail.com Fri Jan 10 07:13:17 2014 Return-Path: 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 718701AE089 for ; Fri, 10 Jan 2014 07:13:17 -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 kzI_3o9Pt7rz for ; Fri, 10 Jan 2014 07:13:14 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6311AE06F for ; Fri, 10 Jan 2014 07:13:14 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id md12so4541842pbc.19 for ; Fri, 10 Jan 2014 07:13:04 -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=JjLq2LGx9dqm8wx8qe/KKPozle9G1jV9Qy4mjgLVQGo=; b=Bb7TVGBxhP4CSgHtOqahw+yOyCmL4if30OUmyQZxjcyyBumZ29vwlkH6+0LfeIpKg/ BgjG2UoTItMO26d5rtBIrZyoYE+qMgB5Vsc1c3yvSKdKpVqlGa8ydGRuDlAhBEQeteN/ q2N9itjqzx2oOpc50w8mveyG49I2/T1MOHiqvOVcA9wGPlXxa90YWnAu3zY7PRz5keY7 enIllkPJnKGzAmior9H0GqVsBeqiFRoZ6dV3WHr5M4LzyEwZeaefOcL4ppnaUf5ysyct i/8gyk8LU0oXYGtwVaCiDE+u9/H3U7bFEGHM0XzDrTUz65bUcAnE+fnAFUlt0rsxouix 6O+g== MIME-Version: 1.0 X-Received: by 10.68.29.72 with SMTP id i8mr12245448pbh.116.1389366784837; Fri, 10 Jan 2014 07:13:04 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 10 Jan 2014 07:13:04 -0800 (PST) In-Reply-To: References: <20140108.122939.2299520154335083466.mbj@tail-f.com> Date: Fri, 10 Jan 2014 16:13:04 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:13:17 -0000 On 10 January 2014 14:39, Wojciech Dec wrote: > On 10 January 2014 11:37, Andy Bierman wrote: >> >> >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec wrote: >>> >>> Hi Martin, >>> >>> On 8 January 2014 12:29, Martin Bjorklund wrote: >>> > Wojciech Dec wrote: >>> >> On 6 January 2014 12:49, Andy Bierman wrote: >>> >> > >>> >> > >>> >> > >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >>> >> > 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 >> 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 /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. >>> >> >> >> Plain PATCH does not allow an optional leaf to be deleted. >> JSON patch does not work well with named data like YANG. >> Ignoring YANG naming and using integer indices that renumber >> every time a list is changed is a non-starter. The only way to >> delete an optional leaf is to GET the entire parent resource, >> edit it offline (remove the leaf) and PUT the parent resource. >> This is operationally disruptive and expensive to implement >> in the server. Optional leafs make up most configuration data, >> so a CM solution that doesn't work well for optional leafs is a bad idea. > > I should have been clearer: Media Type discussion aside, I meant JSON > patch as in "json patch for json reresented yang data", ie likely a > subset of pure 'application/json-patch+json', with yang-patch being in > some other doc. . The fact that JSON patch does not work for xml is, > for me at least, not an issue. A simple answer can thus be that the > patch is for json only. > In general, I don't quite follow why you say that json patch doesn't > allow for leaf deletion; the "remove" op seems to be pretty much > intended for that. Gee, the json (yang) patch could even be just > limited to just this task. > > That said, a solution to the " how to delete an optional leaf" problem > that ends up treating every data item in the system to a resource, > with no way for the designer to override, appears also as a bad idea. > Given that we have a full API spec here, even adding a custom > parameterized operation to the URI may be a better solution. Also, > evidence from the REST API world out there also indicates that for > better or worse, GET and PUT do actually work at scale. I would still > see this still as easier to deal with and implement than having every > single (sub-resource) data item as a resource.... > > So, in summary, "conservative" options, all leading to getting the > spec back from resource extremes as I see can be: > 1. Stay with GET and PUT (I suspect that this is what will get most use anyway). > 2. Introduce JSON patching, in the form of say > "application/yang-json-patch" to the spec (happy to work up some text) > 3. Get back the "full" yang patch from draft -02 > 4. Introduce a new action/operation invoked via a parameter. Forgot to add one more: 5. Introduce meta-data to handle the partial update. > > Thoughts? > > Cheers. >> >> >>> >>> Cheers, >>> Wojciech. >> >> >> >> Andy >> >>> >>> > >>> > /martin >> >> From mbj@tail-f.com Fri Jan 10 07:25:44 2014 Return-Path: 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 4A6701AE06F for ; Fri, 10 Jan 2014 07:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 cvnr5nKnFUMn for ; Fri, 10 Jan 2014 07:25:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AD2F01AE0B0 for ; Fri, 10 Jan 2014 07:25:40 -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 EB171240C149; Fri, 10 Jan 2014 16:25:29 +0100 (CET) Date: Fri, 10 Jan 2014 16:25:29 +0100 (CET) Message-Id: <20140110.162529.2123651992583401736.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: <20140108.122939.2299520154335083466.mbj@tail-f.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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 15:25:44 -0000 Wojciech Dec wrote: > Hi Martin, > > On 8 January 2014 12:29, Martin Bjorklund wrote: > > Wojciech Dec wrote: > >> On 6 January 2014 12:49, Andy Bierman wrote: > >> > > >> > > >> > > >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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. Note that with the current design, you get both, and the client can choose to use the resource that fits his needs best. Specifically, book is still a resource, so if the client wants to update both leafs in one transaction, it would POST to the book resource. > 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) In our server we actually had special code to handle the case that leafs were not resources. So in our case the code is now simpler. On the client side I do not know. But again note that the client can choose to treat all leafs as attributes if it wants to. > 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 /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 /book/page/{page-nr} without a book, or > text without a page, or other cases that do not make sense Without a book doesn't work since a page is defined under the book. In general, such constraints should be expressed in the data model (with proper containment and/or must / unique / mandatory etc constraints). This separates the semantic correctness of the instance data from the specific API details used to change the underyling data. This is especially true of we want to support multiple protocols (which is what we're doing with RESTCONF). > , 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. Agreed, but that is not the intention. > 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. I agree that we should have some mandatory way of patching that also can remove optional leafs. It is important that we can make arbitrary changes in one transaction. /martin From andy@yumaworks.com Fri Jan 10 08:31:05 2014 Return-Path: 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 CA2331AE0D8 for ; Fri, 10 Jan 2014 08:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 PVcwh3e5Jy_h for ; Fri, 10 Jan 2014 08:31:01 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id A605A1AD627 for ; Fri, 10 Jan 2014 08:31:01 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id jt11so4645074pbb.14 for ; Fri, 10 Jan 2014 08:30:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cGIM7qDE1fW2zUHM3ul7219L3v9z1bnKeckDt7G6pI8=; b=jTLfxKnbzRq623FdYEZdyxLsotlDXhBXl/YEJ0AqNG+DecmX5dz2fthv5+ui3zPZ0A 4cN4g6/lBjv2pHblrxFJFn/59gdJ6M22UHTFTIzRfKhM4AzkQvJtrS4wCBwRh8AmcK2D g90Qm4oDytAQgndOCodb6txpe5wIRn1kjQjvPKt+OpHQNCiU/tK07jqdIzS5T7v1Hk/x E4VXehSN1wVdl9aJnkblDKxSJ9fa+lbTKHnRYrAQl75sVTSNjvh6cAlnTvHZJz6mX9Tw IIdbpqexjBPcUUhKcrNdK1tL9yc5OcZz8+4TB/FNF3E3EjnAcUnCrCQ0QB2XAV0IHZCn ysNQ== X-Gm-Message-State: ALoCoQk9zIOtNRU0vOtKKvsd99AV3ODJzp3Ds46Fk/1A9sG5FNZF97lrE4WWdr8+LqtjVm55Iewu MIME-Version: 1.0 X-Received: by 10.68.59.202 with SMTP id b10mr12582309pbr.78.1389371450937; Fri, 10 Jan 2014 08:30:50 -0800 (PST) Received: by 10.70.130.142 with HTTP; Fri, 10 Jan 2014 08:30:50 -0800 (PST) In-Reply-To: References: <20140108.122939.2299520154335083466.mbj@tail-f.com> Date: Fri, 10 Jan 2014 08:30:50 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=bcaec53af2a4cb6bc204efa03f9d Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 16:31:06 -0000 --bcaec53af2a4cb6bc204efa03f9d Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 10, 2014 at 5:39 AM, Wojciech Dec wrote: > On 10 January 2014 11:37, Andy Bierman wrote: > > > > > > > > On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec > wrote: > >> > >> Hi Martin, > >> > >> On 8 January 2014 12:29, Martin Bjorklund wrote: > >> > Wojciech Dec wrote: > >> >> On 6 January 2014 12:49, Andy Bierman wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > >> >> > 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 >> 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 /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. > >> > > > > > > Plain PATCH does not allow an optional leaf to be deleted. > > JSON patch does not work well with named data like YANG. > > Ignoring YANG naming and using integer indices that renumber > > every time a list is changed is a non-starter. The only way to > > delete an optional leaf is to GET the entire parent resource, > > edit it offline (remove the leaf) and PUT the parent resource. > > This is operationally disruptive and expensive to implement > > in the server. Optional leafs make up most configuration data, > > so a CM solution that doesn't work well for optional leafs is a bad idea. > > I should have been clearer: Media Type discussion aside, I meant JSON > patch as in "json patch for json reresented yang data", ie likely a > subset of pure 'application/json-patch+json', with yang-patch being in > some other doc. . The fact that JSON patch does not work for xml is, > for me at least, not an issue. A simple answer can thus be that the > patch is for json only. > In general, I don't quite follow why you say that json patch doesn't > allow for leaf deletion; the "remove" op seems to be pretty much > intended for that. Gee, the json (yang) patch could even be just > limited to just this task. > > JSON Patch does not work for NETCONF datastores very well because they contain data named with YANG list keys. It has nothing to do with XML. It has to do with the problems related to editing foo[i] instead of foo[test1][row2][step3], where "i" is constantly changing for a given resource. That said, a solution to the " how to delete an optional leaf" problem > that ends up treating every data item in the system to a resource, > with no way for the designer to override, appears also as a bad idea. > Given that we have a full API spec here, even adding a custom > parameterized operation to the URI may be a better solution. Also, > evidence from the REST API world out there also indicates that for > better or worse, GET and PUT do actually work at scale. I would still > see this still as easier to deal with and implement than having every > single (sub-resource) data item as a resource.... > > As Martin pointed out, your app can choose not to treat leafs as resources and everything still works. What will break in your application code if you choose to treat leafs as attributes instead of resources? IMO, an optional leaf or leaf-list is a sub-resource because it can be created and deleted after the parent resource is created. > So, in summary, "conservative" options, all leading to getting the > spec back from resource extremes as I see can be: > 1. Stay with GET and PUT (I suspect that this is what will get most use > anyway). > 2. Introduce JSON patching, in the form of say > "application/yang-json-patch" to the spec (happy to work up some text) > 3. Get back the "full" yang patch from draft -02 > 4. Introduce a new action/operation invoked via a parameter. > > I don't understand this list, especially 2 & 3. > Thoughts? > > Cheers. > > > > > >> > >> Cheers, > >> Wojciech. > > > > > > > > Andy > > > >> > >> > > >> > /martin > > > > > Andy --bcaec53af2a4cb6bc204efa03f9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 10, 2014 at 5:39 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 10 January 2014 11:37, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com> wrote:
>
>
>
> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>>
>> 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 =A0document= ed somewhere? The IETF
>> >> >> 88 minutes only talk about the yang patch aspect= .
>> >> >>
>> >> >> Anyway, I took a read through the latest documen= t and the change to
>> >> >> have all Yang data-nodes be resources. Am I corr= ect in interpreting
>> >> >> it
>> >> >> that now =A0every leaf node =A0effectively becom= es a resource with a
>> >> >> separate URI? Could the authors provide some mor= e 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 re= source, and then
>> >> > replace
>> >> > the entire resource (minus the optional leaf).
>> >>
>> >>
>> >> I am still not able to get the full rationale for the cha= nge. =A0Can the
>> >> authors or chairs provide that?
>> >>
>> >> Anyway, it now appears that every single data leaf is a r= esource,
>> >> instead of an attribute
>> >
>> > Yes, every leaf is a subresource to its parent list or contai= ner.
>> > This just means that you can GET/POST/DELETE the leaf directl= y, 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 b= e constrained
>> >> by their parent resource, and leaving that up to the impl= ementation 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 s= ome 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. =A0Could you pr= ovide an
>> > example (data model and requests) that you feel is problemati= c or
>> > unclear?
>>
>>
>> A simple example:
>>
>> =A0 =A0 container book {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf price {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf tax-amount {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>>
>> =A0 =A0 =A0}
>>
>> 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 t= he
>> data: To update the resource, a POST operation to foo/book would c= arry
>> in the envelope both a new price and the tax amount. A (worse) RES= T
>> API design would expose both price and tax-amount as separate
>> resources, accept POST to both foo/book/price and foo/book/tax-amo= unt
>> and hope-for-the-best that the client succeeds and all. Several no= n
>> trivial failuire scenarios come up here too.
>>
>> The key is that REST API design is very much about determining wha= t is
>> a resource, =A0its representation by a URI, and what are the attri= butes
>> of a resource. In draft -03, everything is now a resource, and
>> everything is also attribute. This IMO ultimately complicates and<= br> >> bloats code (on client, server, and likely both), and will lead to=
>> brittle API and poor user experience.
>>
>> Another quick example:
>>
>>
>> =A0 =A0 container book {
>>
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list page {
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key page-nr;
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf page-nr {type string;= }
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf text {type string;} >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>> =A0 =A0 =A0}
>>
>> 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 th= e
>> dependent sub-resources directly thus allowing someone to create (= POST
>> or PUT) to <root stuff here>/book/page/{page-nr} =A0without = 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 =A0handler 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/probl= ems in the
>> >> support of HTTP Patch operation (incl. JSON patch), the s= olution
>> >> appears to be possibly worse than the supposed problem. T= hat's why it
>> >> would be good to understand the rationale some more.
>> >
>> > If the "yang patch" media type is opitonal, there i= s no other way to
>> > delete optional leafs. =A0If 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 =A0or b) handling (specifyi= ng 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.
>>
>
>
> Plain PATCH does not allow an optional leaf to be deleted.
> JSON patch does not work well with named data like YANG.
> Ignoring YANG naming and using integer indices that renumber
> every time a list is changed is a non-starter. =A0The only way to
> delete an optional leaf is to GET the entire parent resource,
> edit it offline (remove the leaf) and PUT the parent resource.
> This is operationally disruptive and expensive to implement
> in the server. =A0Optional leafs make up most configuration data,
> so a CM solution that doesn't work well for optional leafs is a ba= d idea.

I should have been clearer: Media Type discussion aside, I meant JSON
patch as in "json patch for json reresented yang data", ie likely= a
subset of pure 'application/json-patch+json', with yang-patch being= in
some other doc. . The fact that JSON patch does not work for xml is,
for me at least, not an issue. A simple answer can thus be that the
patch is for json only.
In general, I don't quite follow why you say that json patch doesn'= t
allow for leaf deletion; the "remove" op seems to be pretty much<= br> intended for that. Gee, the json (yang) patch could even be just
limited to just this task.


JSON Patch does not work for NETCONF d= atastores very well
because they contain data named with YANG lis= t keys. =A0It has
nothing to do with XML. =A0It has to do with th= e problems related
to editing foo[i] instead of foo[test1][row2][step3], where "i&qu= ot; is
constantly changing for a given resource.


That said, a solution to the " how to delete an optional leaf" pr= oblem
that ends up treating every data item in the system to a resource,
with no way for the designer to override, appears also as a bad idea.
Given that we have a full API spec here, even adding a custom
parameterized operation to the URI may be a better solution. Also,
evidence from the REST API world out there also indicates that for
better or worse, GET and PUT do actually work at scale. I would still
see this still as easier to deal with and implement than having every
single (sub-resource) data item as a resource....


As Martin pointed out, your app can ch= oose not to treat leafs as
resources and everything still works. = =A0What will break in your
application code if you choose to trea= t leafs as attributes instead
of resources?

IMO, an optional leaf or leaf-l= ist is a sub-resource because it can be created
and deleted after= the parent resource is created.

=A0
So, in summary, "conservative" options, all leading to getting th= e
spec back from resource extremes as I see can be:
1. Stay with GET and PUT (I suspect that this is what will get most use any= way).
2. Introduce JSON patching, in the form of say
"application/yang-json-patch" to the spec (happy to work up some = text)
3. Get back the "full" yang patch from draft -02
4. Introduce a new action/operation invoked via a parameter.


I don't understand this list, espe= cially 2 & 3.
=A0
Thoughts?

Cheers.
>
>
>>
>> Cheers,
>> Wojciech.
>
>
>
> Andy
>
>>
>> >
>> > /martin
>
>


Andy

--bcaec53af2a4cb6bc204efa03f9d-- From andy@yumaworks.com Fri Jan 10 10:03:47 2014 Return-Path: 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 DF9AC1AE11F for ; Fri, 10 Jan 2014 10:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hVr2oBKrI9Ke for ; Fri, 10 Jan 2014 10:03:44 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id E85CC1AE0D4 for ; Fri, 10 Jan 2014 10:03:43 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so3034476qab.37 for ; Fri, 10 Jan 2014 10:03:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=HESEYanzxKYV4sk1VAOZgiXCAhoyE1YHEf14COEOrtk=; b=UNjaCZCM95NrMR/XxiVmmLcqRMilpVLxcmqvsUu9aQrFNgYohQhlWPfqgfz6m2MK2E BLfbbabEItYpSonBMjw4o5i3cvc4mjExBzi8HXzcZ2OGZ7fR/P8yxleig+W4Rnnkc+6W dp0DPh5LfTxehWx17NPwy+XLjQJP1tD9AI+Jye4Gxt/TPPeANNYQAYYwafuG9JfmrPHx LSoW0IazncYWYMxO5s+G/MbtYpZI5f2xT7zoOuAfOnfvpsDMAM5kp/GPNd6ethEoNWFG nVSWFNIx2HhtI0lWrNJGGrsNXtsmbTDHb3cfpgtmDLNLnKjw9JPgnLU83CqvH6OZSfoK d5Rg== X-Gm-Message-State: ALoCoQmm1+/89wetFboRDXmR7MflTlcBRzDlliC0QGcpfl+idrODT2tg8f2A0Xif/7hiy3RlzqBA MIME-Version: 1.0 X-Received: by 10.224.123.15 with SMTP id n15mr9895147qar.78.1389377013479; Fri, 10 Jan 2014 10:03:33 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 10 Jan 2014 10:03:33 -0800 (PST) Date: Fri, 10 Jan 2014 10:03:33 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=089e0149cf8059210704efa18b4b Cc: Netconf Subject: [Netconf] RESTCONF Resource Model (was Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:03:48 -0000 --089e0149cf8059210704efa18b4b Content-Type: text/plain; charset=ISO-8859-1 Hi, The resource management model is a fairly important part of the RESTCONF architecture. Perhaps all attempts so far have been too simplistic. The YANG node type seems to be irrelevant to answering the question "what is a sub-resource?" The set of mandatory[1] descendant nodes are not sub-resources of a given parent. They must exist and cannot be created and deleted independently of the parent resource. So a sub-resource is really any descendant sub-tree that can be created and deleted independent of the parent resource. IMO there should not be a complex set of rules for restricting URIs and HTTP methods, based on mandatory vs. optional nodes. This is a conceptual distinction which does not need to be enforced somehow in the protocol. It seems arbitrary to say that a resource target URI can point at a container/list but not a leaf/leaf-list. The server is going to use the YANG validation rules to determine if an operation is allowed. DELETE will fail for a mandatory container, same as a leaf. [1] mandatory can be complex: static: mandatory, min-elements dynamic: if-feature, when + Andy On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec wrote: > On 10 January 2014 14:39, Wojciech Dec wrote: > > On 10 January 2014 11:37, Andy Bierman wrote: > >> > >> > >> > >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec > wrote: > >>> > >>> Hi Martin, > >>> > >>> On 8 January 2014 12:29, Martin Bjorklund wrote: > >>> > Wojciech Dec wrote: > >>> >> On 6 January 2014 12:49, Andy Bierman wrote: > >>> >> > > >>> >> > > >>> >> > > >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > > >>> >> > 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 >>> 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 /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. > >>> > >> > >> > >> Plain PATCH does not allow an optional leaf to be deleted. > >> JSON patch does not work well with named data like YANG. > >> Ignoring YANG naming and using integer indices that renumber > >> every time a list is changed is a non-starter. The only way to > >> delete an optional leaf is to GET the entire parent resource, > >> edit it offline (remove the leaf) and PUT the parent resource. > >> This is operationally disruptive and expensive to implement > >> in the server. Optional leafs make up most configuration data, > >> so a CM solution that doesn't work well for optional leafs is a bad > idea. > > > > I should have been clearer: Media Type discussion aside, I meant JSON > > patch as in "json patch for json reresented yang data", ie likely a > > subset of pure 'application/json-patch+json', with yang-patch being in > > some other doc. . The fact that JSON patch does not work for xml is, > > for me at least, not an issue. A simple answer can thus be that the > > patch is for json only. > > In general, I don't quite follow why you say that json patch doesn't > > allow for leaf deletion; the "remove" op seems to be pretty much > > intended for that. Gee, the json (yang) patch could even be just > > limited to just this task. > > > > That said, a solution to the " how to delete an optional leaf" problem > > that ends up treating every data item in the system to a resource, > > with no way for the designer to override, appears also as a bad idea. > > Given that we have a full API spec here, even adding a custom > > parameterized operation to the URI may be a better solution. Also, > > evidence from the REST API world out there also indicates that for > > better or worse, GET and PUT do actually work at scale. I would still > > see this still as easier to deal with and implement than having every > > single (sub-resource) data item as a resource.... > > > > So, in summary, "conservative" options, all leading to getting the > > spec back from resource extremes as I see can be: > > 1. Stay with GET and PUT (I suspect that this is what will get most use > anyway). > > 2. Introduce JSON patching, in the form of say > > "application/yang-json-patch" to the spec (happy to work up some text) > > 3. Get back the "full" yang patch from draft -02 > > 4. Introduce a new action/operation invoked via a parameter. > > Forgot to add one more: > 5. Introduce meta-data to handle the partial update. > > > > > Thoughts? > > > > Cheers. > >> > >> > >>> > >>> Cheers, > >>> Wojciech. > >> > >> > >> > >> Andy > >> > >>> > >>> > > >>> > /martin > >> > >> > --089e0149cf8059210704efa18b4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The resource management model is a = fairly important part of
the RESTCONF architecture. =A0Perhaps al= l attempts so far have
been too simplistic.

<= div> The YANG node type seems to be irrelevant to answering
the questi= on "what is a sub-resource?" =A0The set of mandatory[1]
descendant nodes are not sub-resources of a given parent.
They m= ust exist and cannot be created and deleted
independently of the parent resource. So a sub-resource
is r= eally any descendant sub-tree that can be created and
deleted ind= ependent of the parent resource.

IMO ther= e should not be a complex set of rules for restricting URIs
and HTTP methods, based on mandatory vs. optiona= l nodes.
This is a conceptual distinction w= hich does not need to be
enforced somehow i= n the protocol.

It seems ar= bitrary to say that a resource target URI can point
at a container/list but not a leaf/leaf-list. =A0The server is goi= ng
to use the YANG validation rules to determine if= an operation
is allowed. =A0DELETE will fa= il for a mandatory container, same
as a lea= f.

[1] mandato= ry can be complex:
=A0 =A0static: mandatory= , min-elements
=A0 =A0dynamic: if-feature, = when + <static>


<= div class=3D"gmail_extra">Andy


On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec <wdec.ietf@gmail.com&g= t; wrote:
On 10 January 2014 14:39, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> On 10 January 2014 11:37, Andy Bierman <andy@yumaworks.com> wrote:
>>
>>
>>
>> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>>>
>>> Hi Martin,
>>>
>>> On 8 January 2014 12:29, Martin Bjorklund <mbj@tail-f.com> wrote:
>>> > Wojciech Dec <w= dec.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 =A0docu= mented somewhere? The IETF
>>> >> >> 88 minutes only talk about the yang patch as= pect.
>>> >> >>
>>> >> >> Anyway, I took a read through the latest doc= ument and the change to
>>> >> >> have all Yang data-nodes be resources. Am I = correct in interpreting
>>> >> >> it
>>> >> >> that now =A0every leaf node =A0effectively b= ecomes 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 wa= y to delete an
>>> >> > optional leaf
>>> >> > or leaf-list otherwise, except to copy the entir= e resource, and then
>>> >> > replace
>>> >> > the entire resource (minus the optional leaf). >>> >>
>>> >>
>>> >> I am still not able to get the full rationale for the= change. =A0Can 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 co= ntainer.
>>> > This just means that you can GET/POST/DELETE the leaf dir= ectly, w/o
>>> > having to PATCH the parent.
>>> >
>>> >> and the spec doesn't specify a distinction
>>> >> between handling parent resources and its sub-resourc= es, 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 besi= des being IMO a
>>> >> major complication for client or server, and likely b= oth e.g how
>>> >> should a change to a sub-resource that doesn't me= et some condition of
>>> >> the parent be handled? For a single parent resource, = how should
>>> >> multiple sub-resource changes be coordinated (the par= ent resource
>>> >> needs to be consistent)? Etc.
>>> >
>>> > I am afraid I do not understand your concern. =A0Could yo= u provide an
>>> > example (data model and requests) that you feel is proble= matic or
>>> > unclear?
>>>
>>>
>>> A simple example:
>>>
>>> =A0 =A0 container book {
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf price {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf tax-amount {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type string;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>>>
>>> =A0 =A0 =A0}
>>>
>>> Price and taxt are typically related.
>>> A (better) REST API design would seek to minimize transactiona= l
>>> effects to the client while protecting the consistency/sanity = of the
>>> data: To update the resource, a POST operation to foo/book wou= ld 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<= br> >>> resources, accept POST to both foo/book/price and foo/book/tax= -amount
>>> and hope-for-the-best that the client succeeds and all. Severa= l non
>>> trivial failuire scenarios come up here too.
>>>
>>> The key is that REST API design is very much about determining= what is
>>> a resource, =A0its representation by a URI, and what are the a= ttributes
>>> 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 lea= d to
>>> brittle API and poor user experience.
>>>
>>> Another quick example:
>>>
>>>
>>> =A0 =A0 container book {
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list page {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key page-nr;
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf page-nr {type str= ing;}
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf text {type string= ;}
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>>> =A0 =A0 =A0}
>>>
>>> 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 expos= e the
>>> dependent sub-resources directly thus allowing someone to crea= te (POST
>>> or PUT) to <root stuff here>/book/page/{page-nr} =A0with= out a book, or
>>> text without a page, or other cases that do not make sense, an= d in
>>> general requiring a feast of error cases.
>>> Requiring the text POST/PUT =A0handler to also do book creatio= n,
>>> validation, etc, is not a great design. It complicates code an= d
>>> creates ugly code dependencies, should the model change, etc.<= br> >>>
>>>
>>> >
>>> >> If this current development was driven by questions/p= roblems in the
>>> >> support of HTTP Patch operation (incl. JSON patch), t= he solution
>>> >> appears to be possibly worse than the supposed proble= m. That's why it
>>> >> would be good to understand the rationale some more.<= br> >>> >
>>> > If the "yang patch" media type is opitonal, the= re is no other way to
>>> > delete optional leafs. =A0If the optional leaf is a resou= rce it can be
>>> > removed with DELETE.
>>>
>>> Yes, but the current "solution" is IMO a lot worse t= han a) mandating
>>> PATCH, and I mean plain JSON/XML PATCH =A0or b) handling (spec= ifying in
>>> the draft how-to do) updates via POST. Thus bringing in back t= he
>>> simple patch would be a good move. And the Yang patch is somet= hing
>>> that can go into another spec, I agree.
>>>
>>
>>
>> Plain PATCH does not allow an optional leaf to be deleted.
>> JSON patch does not work well with named data like YANG.
>> Ignoring YANG naming and using integer indices that renumber
>> every time a list is changed is a non-starter. =A0The only way to<= br> >> delete an optional leaf is to GET the entire parent resource,
>> edit it offline (remove the leaf) and PUT the parent resource.
>> This is operationally disruptive and expensive to implement
>> in the server. =A0Optional leafs make up most configuration data,<= br> >> so a CM solution that doesn't work well for optional leafs is = a bad idea.
>
> I should have been clearer: Media Type discussion aside, I meant JSON<= br> > patch as in "json patch for json reresented yang data", ie l= ikely a
> subset of pure 'application/json-patch+json', with yang-patch = being in
> some other doc. . The fact that JSON patch does not work for xml is, > for me at least, not an issue. A simple answer can thus be that the > patch is for json only.
> In general, I don't quite follow why you say that json patch doesn= 't
> allow for leaf deletion; the "remove" op seems to be pretty = much
> intended for that. Gee, the json (yang) patch could even be just
> limited to just this task.
>
> That said, a solution to the " how to delete an optional leaf&quo= t; problem
> that ends up treating every data item in the system to a resource,
> with no way for the designer to override, appears also as a bad idea.<= br> > Given that we have a full API spec here, even adding a custom
> parameterized operation to the URI may be a better solution. Also,
> evidence from the REST API world out there also indicates that for
> better or worse, GET and PUT do actually work at scale. I would still<= br> > see this still as easier to deal with and implement than having every<= br> > single (sub-resource) data item as a resource....
>
> So, in summary, "conservative" options, all leading to getti= ng the
> spec back from resource extremes as I see can be:
> 1. Stay with GET and PUT (I suspect that this is what will get most us= e anyway).
> 2. Introduce JSON patching, in the form of say
> "application/yang-json-patch" to the spec (happy to work up = some text)
> 3. Get back the "full" yang patch from draft -02
> 4. Introduce a new action/operation invoked via a parameter.

Forgot to add one more:
5. Introduce meta-data to handle the partial update.

>
> Thoughts?
>
> Cheers.
>>
>>
>>>
>>> Cheers,
>>> Wojciech.
>>
>>
>>
>> Andy
>>
>>>
>>> >
>>> > /martin
>>
>>

--089e0149cf8059210704efa18b4b-- From wdec.ietf@gmail.com Fri Jan 10 10:42:13 2014 Return-Path: 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 3E78F1AE19A for ; Fri, 10 Jan 2014 10:42:13 -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 BtLLmw0b6dIV for ; Fri, 10 Jan 2014 10:42:10 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 371AC1AE17F for ; Fri, 10 Jan 2014 10:42:10 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id r10so937275pdi.6 for ; Fri, 10 Jan 2014 10:42:00 -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=TjwZvmVOInMEMpnlKumjuI2riLDVRF308zEid9OEzYg=; b=E3RbDcoadk9pj/kva9hkCxuq1wyny31a/aMVKVHA6ABXPCnSV0KjdT87QxOU4TpcGn k0U9SmJEFfWvc7mmx0kPLx0SqwMgCVKl3LwMwsVwAQp9LdZuz9tBbU1ykN0dhIyn/p57 BX+cBbjBxiYyBBlXBA6YLZ0kRltDDRsIpYWnBqrQV6n45c23Br2YEWeESOA6pCALNk3A rtA7CseMXxPJeFrlwLvC3a0mVdZuLtIoTsIulTyeOu2VvC1kxF6KTgplfD+tg0Z1IhYX VPIIN9FGnpCCqCR7NzmXan2Fe9U+nSxmApriG8WheYAn2KMl1jEM6NqEy+plmKJzjI+o u3Ug== MIME-Version: 1.0 X-Received: by 10.67.5.233 with SMTP id cp9mr13047175pad.147.1389379320421; Fri, 10 Jan 2014 10:42:00 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 10 Jan 2014 10:42:00 -0800 (PST) In-Reply-To: <20140110.162529.2123651992583401736.mbj@tail-f.com> References: <20140108.122939.2299520154335083466.mbj@tail-f.com> <20140110.162529.2123651992583401736.mbj@tail-f.com> Date: Fri, 10 Jan 2014 19:42:00 +0100 Message-ID: From: Wojciech Dec To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:42:13 -0000 Hi Martin, On 10 January 2014 16:25, Martin Bjorklund wrote: > Wojciech Dec wrote: >> Hi Martin, >> >> On 8 January 2014 12:29, Martin Bjorklund wrote: >> > Wojciech Dec wrote: >> >> On 6 January 2014 12:49, Andy Bierman wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec 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. > > Note that with the current design, you get both, and the client can > choose to use the resource that fits his needs best. Specifically, > book is still a resource, so if the client wants to update both leafs > in one transaction, it would POST to the book resource. Well, ok, but how can the server assume what he client chooses to do, other than supporting every possibility. Or alternatively, how can we tell the client: "Although RESTCONF spec + YANG model might indicate otherwise, leafs are not resources in our implementation"? > >> 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) > > In our server we actually had special code to handle the case that > leafs were not resources. So in our case the code is now simpler. > > On the client side I do not know. But again note that the client can > choose to treat all leafs as attributes if it wants to. > >> 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 /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 /book/page/{page-nr} without a book, or >> text without a page, or other cases that do not make sense > > Without a book doesn't work since a page is defined under the book. > In general, such constraints should be expressed in the data model > (with proper containment and/or must / unique / mandatory etc > constraints). This separates the semantic correctness of the instance > data from the specific API details used to change the underyling > data. This is especially true of we want to support multiple > protocols (which is what we're doing with RESTCONF). Yeah, but how would one do that... > >> , 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. > > Agreed, but that is not the intention. ... without ending up with the above, or assuming a very very specific data store ? Or perhaps, that's the thing I'm not understanding: what is the responsibility of RESTconf layer and what is the responsibility of the data store in terms of the yang schema? Cheers, Wojciech. > >> 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. > > I agree that we should have some mandatory way of patching that also > can remove optional leafs. It is important that we can make arbitrary > changes in one transaction. > > > /martin From mbj@tail-f.com Fri Jan 10 10:48:32 2014 Return-Path: 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 9D8B01ADFF3 for ; Fri, 10 Jan 2014 10:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 16AoMCo2a5d0 for ; Fri, 10 Jan 2014 10:48:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F71AE04C for ; Fri, 10 Jan 2014 10:48:29 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B986240C11A; Fri, 10 Jan 2014 19:48:19 +0100 (CET) Date: Fri, 10 Jan 2014 19:48:18 +0100 (CET) Message-Id: <20140110.194818.364466126.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: <20140110.162529.2123651992583401736.mbj@tail-f.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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 18:48:32 -0000 Wojciech Dec wrote: > Hi Martin, > > On 10 January 2014 16:25, Martin Bjorklund wrote: > > Wojciech Dec wrote: > >> Hi Martin, > >> > >> On 8 January 2014 12:29, Martin Bjorklund wrote: > >> > Wojciech Dec wrote: > >> >> On 6 January 2014 12:49, Andy Bierman wrote: > >> >> > > >> >> > > >> >> > > >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > >> >> > 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. > > > > Note that with the current design, you get both, and the client can > > choose to use the resource that fits his needs best. Specifically, > > book is still a resource, so if the client wants to update both leafs > > in one transaction, it would POST to the book resource. > > Well, ok, but how can the server assume what he client chooses to do, > other than supporting every possibility. Or alternatively, how can we > tell the client: "Although RESTCONF spec + YANG model might indicate > otherwise, leafs are not resources in our implementation"? The server still has to support the relevant operations on the leaf resources, but the client can choose to not use them if it wants to. See also below. > >> 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) > > > > In our server we actually had special code to handle the case that > > leafs were not resources. So in our case the code is now simpler. > > > > On the client side I do not know. But again note that the client can > > choose to treat all leafs as attributes if it wants to. > > > >> 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 >> 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 /book/page/{page-nr} without a book, or > >> text without a page, or other cases that do not make sense > > > > Without a book doesn't work since a page is defined under the book. > > In general, such constraints should be expressed in the data model > > (with proper containment and/or must / unique / mandatory etc > > constraints). This separates the semantic correctness of the instance > > data from the specific API details used to change the underyling > > data. This is especially true of we want to support multiple > > protocols (which is what we're doing with RESTCONF). > > Yeah, but how would one do that... > > > > >> , 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. > > > > Agreed, but that is not the intention. > > ... without ending up with the above, or assuming a very very specific > data store ? Or perhaps, that's the thing I'm not understanding: what > is the responsibility of RESTconf layer and what is the responsibility > of the data store in terms of the yang schema? If the server gets a request from a client to set the title of a book: PUT /.../book/{book-name}/page/{page-nr}/text and the book doesn't exist, the server signal an error. It will not automatically create the book. (this example made the book a list, not a container) /martin From wdec.ietf@gmail.com Sat Jan 11 04:03:59 2014 Return-Path: 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 D6F931ADF64 for ; Sat, 11 Jan 2014 04:03:59 -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 nXEAVpDtSo7Z for ; Sat, 11 Jan 2014 04:03:57 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id C26B51AD738 for ; Sat, 11 Jan 2014 04:03:57 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id q10so5650790pdj.39 for ; Sat, 11 Jan 2014 04:03:47 -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=+Qs89ye9jhXLOt0XSzp3CA/lkxW+rOVSNKmdEgDxuhg=; b=oUQj0QagrcjOuatC1B5A+TP5m160DvgHl6nfKfqZjUczIBeyLyt/CPDzT72zqHHVJH ZhqA5g/GkJ1h2wsQczWRbDAHUE/wE71gaK6OCxGZHpWXQgnaknszd4bmZn0M4rAB+JXK KHcIP3Hb++zbX6TPfomObbQXxD0eJHzg3y+vY4EIyMiDiGYw9iFvcr21ss2byM8k7RW1 LnJXVq2z59IrXgXVY8y1oLrDvqrsO6UdrKqDnZ6+JExhk3l6dm0g4oIG8bsKKvDCCtol y/kVKihPiQNzJf50t+L5ouGShdDxoYEp6eWNRHrjf3MoJmv3honHvIX+0n66HVAMBGdL Sy5Q== MIME-Version: 1.0 X-Received: by 10.68.221.68 with SMTP id qc4mr17805156pbc.29.1389441827572; Sat, 11 Jan 2014 04:03:47 -0800 (PST) Received: by 10.70.57.163 with HTTP; Sat, 11 Jan 2014 04:03:47 -0800 (PST) In-Reply-To: <20140110.194818.364466126.mbj@tail-f.com> References: <20140110.162529.2123651992583401736.mbj@tail-f.com> <20140110.194818.364466126.mbj@tail-f.com> Date: Sat, 11 Jan 2014 13:03:47 +0100 Message-ID: From: Wojciech Dec To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 12:04:00 -0000 On 10 January 2014 19:48, Martin Bjorklund wrote: > Wojciech Dec wrote: >> Hi Martin, >> >> On 10 January 2014 16:25, Martin Bjorklund wrote: >> > Wojciech Dec wrote: >> >> Hi Martin, >> >> >> >> On 8 January 2014 12:29, Martin Bjorklund wrote: >> >> > Wojciech Dec wrote: >> >> >> On 6 January 2014 12:49, Andy Bierman wrote: >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >> >> >> > 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. >> > >> > Note that with the current design, you get both, and the client can >> > choose to use the resource that fits his needs best. Specifically, >> > book is still a resource, so if the client wants to update both leafs >> > in one transaction, it would POST to the book resource. >> >> Well, ok, but how can the server assume what he client chooses to do, >> other than supporting every possibility. Or alternatively, how can we >> tell the client: "Although RESTCONF spec + YANG model might indicate >> otherwise, leafs are not resources in our implementation"? > > The server still has to support the relevant operations on the leaf > resources, but the client can choose to not use them if it wants to. > > See also below. > > >> >> 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) >> > >> > In our server we actually had special code to handle the case that >> > leafs were not resources. So in our case the code is now simpler. >> > >> > On the client side I do not know. But again note that the client can >> > choose to treat all leafs as attributes if it wants to. >> > >> >> 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 > >> 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 /book/page/{page-nr} without a book, or >> >> text without a page, or other cases that do not make sense >> > >> > Without a book doesn't work since a page is defined under the book. >> > In general, such constraints should be expressed in the data model >> > (with proper containment and/or must / unique / mandatory etc >> > constraints). This separates the semantic correctness of the instance >> > data from the specific API details used to change the underyling >> > data. This is especially true of we want to support multiple >> > protocols (which is what we're doing with RESTCONF). >> >> Yeah, but how would one do that... >> >> > >> >> , 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. >> > >> > Agreed, but that is not the intention. >> >> ... without ending up with the above, or assuming a very very specific >> data store ? Or perhaps, that's the thing I'm not understanding: what >> is the responsibility of RESTconf layer and what is the responsibility >> of the data store in terms of the yang schema? > > If the server gets a request from a client to set the title of a book: > > PUT /.../book/{book-name}/page/{page-nr}/text > > and the book doesn't exist, the server signal an error. It will not > automatically create the book. Sure, I know that this should happen, but what is the responsibility of RESTconf layer and what is the responsibility of the data store in terms of the yang schema? Currently it appears that Restconf assumes that the whole resource containment (model enforcement) is assumed to be done by the data store. /Wojciech. > > (this example made the book a list, not a container) > > > /martin From mbj@tail-f.com Sat Jan 11 04:09:49 2014 Return-Path: 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 B71E71ADF9F for ; Sat, 11 Jan 2014 04:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 qqWBn3oHfvDk for ; Sat, 11 Jan 2014 04:09:47 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4721ACC82 for ; Sat, 11 Jan 2014 04:09:46 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id B9A1A240C187; Sat, 11 Jan 2014 13:09:35 +0100 (CET) Date: Sat, 11 Jan 2014 13:09:35 +0100 (CET) Message-Id: <20140111.130935.29100484.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: <20140110.194818.364466126.mbj@tail-f.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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 12:09:49 -0000 Wojciech Dec wrote: > On 10 January 2014 19:48, Martin Bjorklund wrote: > > Wojciech Dec wrote: > >> Hi Martin, > >> > >> On 10 January 2014 16:25, Martin Bjorklund wrote: > >> > Wojciech Dec wrote: > >> >> Hi Martin, > >> >> > >> >> On 8 January 2014 12:29, Martin Bjorklund wrote: > >> >> > Wojciech Dec wrote: > >> >> >> On 6 January 2014 12:49, Andy Bierman wrote: > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > >> >> >> > 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. > >> > > >> > Note that with the current design, you get both, and the client can > >> > choose to use the resource that fits his needs best. Specifically, > >> > book is still a resource, so if the client wants to update both leafs > >> > in one transaction, it would POST to the book resource. > >> > >> Well, ok, but how can the server assume what he client chooses to do, > >> other than supporting every possibility. Or alternatively, how can we > >> tell the client: "Although RESTCONF spec + YANG model might indicate > >> otherwise, leafs are not resources in our implementation"? > > > > The server still has to support the relevant operations on the leaf > > resources, but the client can choose to not use them if it wants to. > > > > See also below. > > > > > >> >> 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) > >> > > >> > In our server we actually had special code to handle the case that > >> > leafs were not resources. So in our case the code is now simpler. > >> > > >> > On the client side I do not know. But again note that the client can > >> > choose to treat all leafs as attributes if it wants to. > >> > > >> >> 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 >> >> 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 /book/page/{page-nr} without a book, or > >> >> text without a page, or other cases that do not make sense > >> > > >> > Without a book doesn't work since a page is defined under the book. > >> > In general, such constraints should be expressed in the data model > >> > (with proper containment and/or must / unique / mandatory etc > >> > constraints). This separates the semantic correctness of the instance > >> > data from the specific API details used to change the underyling > >> > data. This is especially true of we want to support multiple > >> > protocols (which is what we're doing with RESTCONF). > >> > >> Yeah, but how would one do that... > >> > >> > > >> >> , 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. > >> > > >> > Agreed, but that is not the intention. > >> > >> ... without ending up with the above, or assuming a very very specific > >> data store ? Or perhaps, that's the thing I'm not understanding: what > >> is the responsibility of RESTconf layer and what is the responsibility > >> of the data store in terms of the yang schema? > > > > If the server gets a request from a client to set the title of a book: > > > > PUT /.../book/{book-name}/page/{page-nr}/text > > > > and the book doesn't exist, the server signal an error. It will not > > automatically create the book. > > Sure, I know that this should happen, but what is the responsibility > of RESTconf layer and what is the responsibility > of the data store in terms of the yang schema? > Currently it appears that Restconf assumes that the whole resource > containment (model enforcement) is assumed to be done by the data > store. This is up to the implementation. In a multi-protocol implementation one might think that the underlying datastore takes care of the "model enforcement", but nothing prevents you from doing everything in the RESTCONF layer. /martin From bclaise@cisco.com Mon Jan 13 05:12:57 2014 Return-Path: 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 6897C1ADFA2 for ; Mon, 13 Jan 2014 05:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 MwYwhhI3zNUw for ; Mon, 13 Jan 2014 05:12:54 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48C1ADEDC for ; Mon, 13 Jan 2014 05:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29610; q=dns/txt; s=iport; t=1389618762; x=1390828362; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=soIEffa/qMXKALpg+enXNjnEeG9xP61VwDadHxv4V/c=; b=JY4ghbVcXOHD+fDqOtJDINwZFYTMRGzSVGU0jP6JbR8ygwy3u71sX9u+ LcXHoREcSfNiBq9GeaRKBAN/j+lP7ZgFwWO+ABzqxFZ+ljEGirZ8w8r5x 7gr3dghFXRzk/jnGgdWho8pfYl7ubYXxIvHW1qQ8H/fUk2yS1DLTpS2kq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFAAHl01KQ/khR/2dsb2JhbABagkdEOLl0T4EPFnSCJQEBAQMBAQEBKkEGBAEFCwshAxMBAQ0JAwIBAgEVMAYKAwEFAgEBBRKHYQgNxG4XjhsKEAIBTweENwSYF4EwhRWLUIMuO4E1 X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208,217";a="3562664" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 13 Jan 2014 13:12:41 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0DDCe1Y026853; Mon, 13 Jan 2014 13:12:40 GMT Message-ID: <52D3E647.9070000@cisco.com> Date: Mon, 13 Jan 2014 14:12:39 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000108030202040003050906" Cc: Pete Resnick , 'Barry Leiba' , Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:12:57 -0000 This is a multi-part message in MIME format. --------------000108030202040003050906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Sorry for the delay in getting back to you. Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and we made a few modifications. You can follow up the temp charter text at http://datatracker.ietf.org/doc/charter-ietf-netconf/ Under the history tab, there is a very useful diff tool. The version 15, dated May 31st is the current official charter The version 15-06, dated Jan 10th, is the charter as proposed below in this email The version 15-11, dated today, is the charter after our discussion today. As you can see from the diffs: - we added the zero touch configuration document - we tried to justify why the YANG patch document is needed - we updated the milestones - we added an important sentence regarding the RESTCONF/NETCONF alignment: RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented. - minor edits Feedback? I have two more points: 1. A question to which I've been receiving different answers from different persons: I understand that RESTCONF is an additional simplified interface that follows RESTful principles and is compatible with a resource-oriented device abstraction, but will RESTCONF be in line with the RFC 3535 section 3 requirements. I understand that those requirements are for the communication between the NMS and the managed device. Hence my question during the last meeting opendaylight presentation: will RESTCONF be used as north bound interface only protocol, or also as a south bound interface. The answer was both: So we might have different (competing) solutions to managed devices. 2. HTTP2.0 is developed in the HTTPbis WG. I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it still work with HTTP2.0? Or is this completely orthogonal? I've not been been following the HTTP2.0 developments, so I don't even know if this is a valid question, but I'm wondering if we should say something about the HTTP 2.0 compatibility in the charter? Regards, Benoit > Dear Benoit, > hope you had restful holidays. > Below is the charter proposal we prepared following the consensus > calls and review of the draft charter text, basically adding to the WG > item list point 3. for the joint server configuration data model and > point 4. for RESTCONF. > We would like to ask you to initiate the re-chartering and the > approval by the IESG. Thank you. > Bert & Mehmet > --------------- > Network Configuration (netconf) > ------------------------------- > Charter > Current Status: Active > Chairs: > Bert Wijnen > Mehmet Ersue > Operations and Management Area Directors: > Benoit Claise > Joel Jaeggli > Operations and Management Area Advisor: > Benoit Claise > Mailing Lists: > General Discussion: netconf@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/netconf > Archive: http://www.ietf.org/mail-archive/web/netconf/ > Description of Working Group: > Configuration of networks of devices has become a critical requirement > for operators in today's highly interconnected networks. Large and small > operators alike have developed their own mechanisms or have used vendor > specific mechanisms to transfer configuration data to and from a device > and to examine device state information which may impact the > configuration. Each of these mechanisms may be different in various > aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. > The NETCONF protocol has the following characteristics: > - Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data > - Is extensible enough so that vendors can provide access to all > configuration data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and formatting- > related changes between releases) > - Uses an XML-based data representation, that can be easily > manipulated > using non-specialized XML manipulation tools. > - Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems > - Supports multiple (e.g. candidate and running) data-stores to > optimize > configuration preparation and activation > - Supports network wide configuration transactions (with features such > as locking and rollback capability) > - Runs over a secure transport; SSH is mandatory to implement while > TLS is an optional transport. > - Provides support for asynchronous notifications. > - Supports an Access Control Model and a YANG module for > configuring the > Access Control parameters. > - Supports a YANG module for System Notifications > The NETCONF protocol is data modeling language independent, but YANG is > the recommended NETCONF modeling language, which introduces advanced > language features for configuration management. > Based on the implementation, deployment experience and interoperability > testing, the WG aims to produce a NETCONF status report in a later > stage. > The result may be clarifications for RFC6241 and RFC6242 and addressing > any reported errata. > In the current phase of NETCONF's incremental development the workgroup > will focus on following items: > 1. Develop the call home mechanism for the mandatory SSH binding > (Reverse > SSH) providing a server-initiated session establishment. > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update > RFC 5539) and add the call home mechanism to provide a server-initiated > session establishment. > 3. Combine the server configuration data models from Reverse SSH and > RFC5539bis drafts in a separate YANG module. > 4. Develop a RESTful interface (RESTCONF) for accessing YANG data using > the datastores defined in NETCONF. The YANG patch operation will be > prepared > in a separate draft. > Goals and Milestones: > Jan 2014 - Submit initial WG drafts for RESTCONF as WG item > Apr 2014 - WGLC for RFC5539bis > Apr 2014 - WGLC for Reverse SSH > Apr 2014 - WGLC for NETCONF server configuration data model > May 2014 - Submit Reverse SSH to AD/IESG for consideration as > Proposed Standard > May 2014 - Submit RFC5539bis to AD/IESG for consideration as > Proposed Standard > Jun 2014 - WGLC for RESTCONF drafts > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed > Standard --------------000108030202040003050906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Sorry for the delay in getting back to you.

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and we made a few modifications.
You can follow up the temp charter text at http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
    The version 15, dated May 31st is the current official charter
    The version 15-06, dated Jan 10th, is the charter as proposed below in this email
    The version 15-11, dated today, is the charter after our discussion today.

As you can see from the diffs:
- we added the zero touch configuration document
- we tried to justify why the YANG patch document is needed
- we updated the milestones
- we added an important sentence regarding the RESTCONF/NETCONF alignment:
    RESTCONF should not deviate from NETCONF unless proper justifications is provided
    and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from different persons: I understand that RESTCONF is an additional simplified interface that follows RESTful principles and is compatible with a resource-oriented device abstraction, but will RESTCONF be in line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between the NMS and the managed device. Hence my question during the last meeting opendaylight presentation: will RESTCONF be used as north bound interface only protocol, or also as a south bound interface. The answer was both: So we might have different (competing) solutions to managed devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it still work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even know if this is a valid question, but I'm wondering if we should say something about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
Dear Benoit,
 
hope you had restful holidays.
 
Below is the charter proposal we prepared following the consensus calls and review of the draft charter text, basically adding to the WG item list point 3. for the joint server configuration data model and point 4. for RESTCONF.
 
We would like to ask you to initiate the re-chartering and the approval by the IESG. Thank you.
 
Bert & Mehmet
 
 
--------------- 
 
Network Configuration (netconf)
-------------------------------
 
Charter
 
Current Status: Active
 
Chairs:
     Bert Wijnen <bertietf@bwijnen.net>
     Mehmet Ersue <mehmet.ersue@nsn.com>
 
Operations and Management Area Directors:
     Benoit Claise <bclaise@cisco.com>
     Joel Jaeggli <joelja@bogus.com>
 
Operations and Management Area Advisor:
     Benoit Claise <bclaise@cisco.com>
 
Mailing Lists:
     General Discussion: netconf@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            http://www.ietf.org/mail-archive/web/netconf/
 
Description of Working Group:
 
  Configuration of networks of devices has become a critical requirement
  for operators in today's highly interconnected networks. Large and small
  operators alike have developed their own mechanisms or have used vendor
  specific mechanisms to transfer configuration data to and from a device
  and to examine device state information which may impact the
  configuration. Each of these mechanisms may be different in various
  aspects, such as session establishment, user authentication,
  configuration data exchange, and error responses.
 
  The NETCONF protocol has the following characteristics:
 
    - Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data
    - Is extensible enough so that vendors can provide access to all
    configuration data on the device using a single protocol
    - Has a programmatic interface (avoids screen scraping and formatting-
    related changes between releases)
    - Uses an XML-based data representation, that can be easily manipulated
    using non-specialized XML manipulation tools.
    - Supports integration with existing user authentication methods
    - Supports integration with existing configuration database systems
    - Supports multiple (e.g. candidate and running) data-stores to optimize
    configuration preparation and activation
    - Supports network wide configuration transactions (with features such
    as locking and rollback capability)
   - Runs over a secure transport; SSH is mandatory to implement while TLS is an optional transport.
    - Provides support for asynchronous notifications.
    - Supports an Access Control Model and a YANG module for configuring the
    Access Control parameters.
    - Supports a YANG module for System Notifications
 
 
  The NETCONF protocol is data modeling language independent, but YANG is
  the recommended NETCONF modeling language, which introduces advanced
  language features for configuration management.
 
  Based on the implementation, deployment experience and interoperability
  testing, the WG aims to produce a NETCONF status report in a later stage.
  The result may be clarifications for RFC6241 and RFC6242 and addressing
  any reported errata.
 
  In the current phase of NETCONF's incremental development the workgroup
  will focus on following items:
 
  1. Develop the call home mechanism for the mandatory SSH binding (Reverse
  SSH) providing a server-initiated session establishment.
 
  2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
  RFC 5539) and add the call home mechanism to provide a server-initiated
  session establishment.
 
  3. Combine the server configuration data models from Reverse SSH and
  RFC5539bis drafts in a separate YANG module.
 
  4. Develop a RESTful interface (RESTCONF) for accessing YANG data using
  the datastores defined in NETCONF. The YANG patch operation will be prepared
  in a separate draft.
 
 
Goals and Milestones:
  Jan 2014 - Submit initial WG drafts for RESTCONF as WG item
  Apr 2014 - WGLC for RFC5539bis
  Apr 2014 - WGLC for Reverse SSH
  Apr 2014 - WGLC for NETCONF server configuration data model
  May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed Standard
  May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard
  Jun 2014 - WGLC for RESTCONF drafts
  Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard 
 
 

--------------000108030202040003050906-- From bclaise@cisco.com Mon Jan 13 07:19:35 2014 Return-Path: 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 6EAD61AE20A for ; Mon, 13 Jan 2014 07:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 KQSo-I-HMA1e for ; Mon, 13 Jan 2014 07:19:33 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05FD31AE1EE for ; Mon, 13 Jan 2014 07:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2511; q=dns/txt; s=iport; t=1389626362; x=1390835962; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cK4lqGPLqwhSzFa7IVl61gJ97G1kUskpbQz3AuPu/OQ=; b=b2kimCSO6xNjCzMj9+uGA6VMC8/Qp69+qT/xoJFDu2nEE5KRLG7OmN/+ vsFnZm6ASVVeUuEcRgLz/xyWlvfU2rXWA7W7AG/OaE348OGhOvtfmE/VX Wt9V/zFetEpN6WMqI1do5F5sBaAqe38YDdc1jLtdVX4kupYY/QfHTq4Fc U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALQD1FKQ/khM/2dsb2JhbABAGoMLOLpDgRMWdIImAQEEOEABEAshFg8JAwIBAgFFBgEMAQUCAQGIAA02xEkXjhptB4Q3AQOYF4ZFi1CDLjs9 X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208";a="3569255" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 13 Jan 2014 15:19:21 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0DFJKSd018828; Mon, 13 Jan 2014 15:19:20 GMT Message-ID: <52D403F7.3030604@cisco.com> Date: Mon, 13 Jan 2014 16:19:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: RFC Errata System , andy@yumaworks.com, mbj@tail-f.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com References: <20140110133239.2CB797FC398@rfc-editor.org> In-Reply-To: <20140110133239.2CB797FC398@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, jernej.tuljak@mg-soft.com Subject: Re: [Netconf] [Technical Errata Reported] RFC6536 (3863) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:19:35 -0000 Dear all, On this errata, I'm unclear whether a clarification is needed. If it's the case, please update the errata and let me know. Note: errata 3862, which is similar, is discussed on the netmod WG. Regards, Benoit > The following errata report has been submitted for RFC6536, > "Network Configuration Protocol (NETCONF) Access Control Model". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6536&eid=3863 > > -------------------------------------- > Type: Technical > Reported by: Jernej Tuljak > > Section: 3.5.2. > > Original Text > ------------- > typedef group-name-type { > > type string { > > length "1..max"; > > pattern "[^\*].*"; > > } > > description > > "Name of administrative group to which > > users can be assigned."; > > } > > Corrected Text > -------------- > typedef group-name-type { > > type string { > > length "1..max"; > > pattern '[^\*].*'; > > } > > description > > "Name of administrative group to which > > users can be assigned."; > > } > > Notes > ----- > As per RFC6020, Section 6.1.3., a backslash within a double-quoted string introduces a special character. The only valid escape sequences inside a double-quoted YANG string are: \n, \t, \" and \. As \* is not a valid escape sequence, a single quoted string should be used to specify the offending pattern statement's argument. The quotes could also be omitted. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6536 (draft-ietf-netconf-access-control-07) > -------------------------------------- > Title : Network Configuration Protocol (NETCONF) Access Control Model > Publication Date : March 2012 > Author(s) : A. Bierman, M. Bjorklund > Category : PROPOSED STANDARD > Source : Network Configuration > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > . > From bclaise@cisco.com Mon Jan 13 07:50:49 2014 Return-Path: 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 CF0C71AE115 for ; Mon, 13 Jan 2014 07:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nOwi6JYQ5Kx8 for ; Mon, 13 Jan 2014 07:50:47 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id DA36A1AE098 for ; Mon, 13 Jan 2014 07:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9476; q=dns/txt; s=iport; t=1389628236; x=1390837836; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=n4o2CFHuysLx2sxc6KRi1ri2/Zklge+0JuZLVwOJbCA=; b=hN4T9uG5IA8QHmEk1L0J5vXamVSzDOk6CSiXKb9lej+TC9kyBzzkDeET TJdiQKN8vrklOIBaUOemaFBm3BWAyJPD6KS2CLAC8WcZrKkPao5IUYPB5 KnsngTXXBKl0ZSvJFn2lgxqbNDfQkryhQbzdyEIHzz9vgJ9fTsCGr9+20 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGYK1FKQ/khN/2dsb2JhbABAGoMLOLl1T4EUFnSCJQEBAQQBAQEqQQoRCxgJFggHCQMCAQIBFR8RBgEMBgIBAQWHew02qnaZUBeOJRACAVaENwSYF4ZFi1CDLjs9 X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208,217";a="2900584" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 13 Jan 2014 15:50:34 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DFoYIc001234; Mon, 13 Jan 2014 15:50:34 GMT Message-ID: <52D40B4A.4050001@cisco.com> Date: Mon, 13 Jan 2014 16:50:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jonathan Hansford , netconf@ietf.org References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131209210752.GA70828@elstar.local> <52A635DC.1040708@hansfords.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050208090408000702070201" Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:50:50 -0000 This is a multi-part message in MIME format. --------------050208090408000702070201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/2013 12:22, Jonathan Hansford wrote: > > Is there any way of adding Notes to an existing erratum? I cannot find > one. > Done. Regards, Benoit > > For the record: > > Erratum 3821: > This erratum seeks to clarify the meaning of the term "confirmed > commit" for those not familiar with the use of the term within JUNOS. > In particular, that the use of "confirmed" is not in the sense of the > adjective (meaning "firmly established") but rather that the commit > needs to be confirmed. It also emphasises that a "confirming commit" > cannot be reverted. Finally it identifies that it is possible to have > a sequence of "confirmed commits" prior to a "confirming commit" and > that, should no "confirming commit" be received, the configuration > will revert to the state prior to the first "confirmed commit" in the > sequence. > > Erratum 3822: > This erratum seeks to clarify that will cancel all > configuration changes arising from a sequence of "confirmed commits". > > Erratum 3823: > This erratum seeks to clarify that the use of the "persist" parameter > will persist all configuration changes arising from a sequence of > "confirmed commits". > > On 2013-12-09 21:27, Jonathan Hansford wrote: > >> Apologies, >> >> This was my first submission of errata and they came out of my September >> email and the subsequent thread about confirmed commits >> (http://www.ietf.org/mail-archive/web/netconf/current/msg08314.html). >> Consequently there has already been some discussion around the issue. >> The points I was seeking to clarify related to the definition of the >> term "Confirmed commit" (something that makes sense to those who have >> had exposure to JUNOS but appeared counter-intuitive to me in that a >> confirmed commit is one that hasn't yet been confirmed) and the fact >> that it is possible to have a sequence of confirmed commits prior to the >> confirming commit. I'm happy to add that text to the errata. >> >> Jonathan >> >> On 09/12/2013 21:07, Juergen Schoenwaelder wrote: >>> On Mon, Dec 09, 2013 at 09:34:58PM +0100, Bert Wijnen (IETF) wrote: >>>> We have a set of 3 new errata reported to RFC6241. See: >>>> http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table >>>> We would like to hear from the authors/editors what their opinion >>>> is on the reported errata. It is probably best to report your views >>>> to the netconf mailing list. but if you rather disuss it here >>>> first, that is OK too. We probably have to repeat the discussion on >>>> the mlist later if we do, so best to do it on the mailing list. It >>>> will hopefully trigger views from others aswell. >>> I think it would help a lot if there would be a motivation or some >>> sort of an explanation in addition to the OLD NEW text. As it is, I >>> have to guess what the submitter wants to achieve with these errata. >>> Since these are technical errata, it should be possible to describe >>> the problem/bug that is being fixed. It seems that the submitter is >>> trying to address multiple issues in those changes. Anyway, an >>> explanation would have been nice to have. /js >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------050208090408000702070201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 10/12/2013 12:22, Jonathan Hansford wrote:

Is there any way of adding Notes to an existing erratum? I cannot find one.

Done.

Regards, Benoit

For the record:

Erratum 3821:
This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence.

Erratum 3822:
This erratum seeks to clarify that <cancel-commit> will cancel all configuration changes arising from a sequence of "confirmed commits".

Erratum 3823:
This erratum seeks to clarify that the use of the "persist" parameter will persist all configuration changes arising from a sequence of "confirmed commits".

On 2013-12-09 21:27, Jonathan Hansford wrote:

Apologies,

This was my first submission of errata and they came out of my September 
email and the subsequent thread about confirmed commits 
(http://www.ietf.org/mail-archive/web/netconf/current/msg08314.html). 
Consequently there has already been some discussion around the issue. 
The points I was seeking to clarify related to the definition of the 
term "Confirmed commit" (something that makes sense to those who have 
had exposure to JUNOS but appeared counter-intuitive to me in that a 
confirmed commit is one that hasn't yet been confirmed) and the fact 
that it is possible to have a sequence of confirmed commits prior to the 
confirming commit. I'm happy to add that text to the errata.

Jonathan

On 09/12/2013 21:07, Juergen Schoenwaelder wrote:
On Mon, Dec 09, 2013 at 09:34:58PM +0100, Bert Wijnen (IETF) wrote:
We have a set of 3 new errata reported to RFC6241. See: http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table We would like to hear from the authors/editors what their opinion is on the reported errata. It is probably best to report your views to the netconf mailing list. but if you rather disuss it here first, that is OK too. We probably have to repeat the discussion on the mlist later if we do, so best to do it on the mailing list. It will hopefully trigger views from others aswell.
I think it would help a lot if there would be a motivation or some sort of an explanation in addition to the OLD NEW text. As it is, I have to guess what the submitter wants to achieve with these errata. Since these are technical errata, it should be possible to describe the problem/bug that is being fixed. It seems that the submitter is trying to address multiple issues in those changes. Anyway, an explanation would have been nice to have. /js
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--------------050208090408000702070201-- From wwwrun@rfc-editor.org Mon Jan 13 07:53:40 2014 Return-Path: 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 DD2191AE192; Mon, 13 Jan 2014 07:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 uulsKXdr02GM; Mon, 13 Jan 2014 07:53:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 157D51AE15A; Mon, 13 Jan 2014 07:53:37 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2E4B97FC396; Mon, 13 Jan 2014 07:53:26 -0800 (PST) To: jonathan@hansfords.net, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com From: RFC Errata System Message-Id: <20140113155326.2E4B97FC396@rfc-editor.org> Date: Mon, 13 Jan 2014 07:53:26 -0800 (PST) Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Held for Document Update] RFC6241 (3821) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 15:53:41 -0000 The following errata report has been held for document update for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jonathan Hansford Date Reported: 2013-12-06 Held by: Benoit Claise (IESG) Section: 8.4.1 Original Text ------------- 8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the operation and the , , , and parameters for the operation. See Section 8.3 for further details on the operation. A confirmed operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter. The timeout period can be adjusted with the parameter. If a follow-up confirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed operation MAY introduce additional changes to the configuration. If the element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the element is given in the confirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. To cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued, by using the operation. Corrected Text -------------- 8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the operation, the , , , and parameters for the operation, and differentiate between a “to be confirmed” operation (a “confirmed commit”) and a confirming operation. See Section 8.3 for further details on the operation. A confirmed operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up confirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed operation MAY introduce additional changes to the configuration. If the element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the element is given in the confirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more confirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued, unless the last confirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of confirmed commits. To cancel the current sequence of confirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of confirmed commits was issued, by using the operation. Notes ----- This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From bclaise@cisco.com Mon Jan 13 08:01:57 2014 Return-Path: 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 372FF1AE1A0 for ; Mon, 13 Jan 2014 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 FJzox4Gehve5 for ; Mon, 13 Jan 2014 08:01:54 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 55E0D1AE09F for ; Mon, 13 Jan 2014 08:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18794; q=dns/txt; s=iport; t=1389628902; x=1390838502; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=+Lzvqf3Co9LFsKzC0bBzv0pwTXMTWWAYgCsrlPE3aHI=; b=fB0x2X3N8M/6Gi/XMmyPr9Rvvvh2cVuQSZFnkurcNikU+/hreY5aEC/I qrX0diLlMo3l6Ebiy5VuMl3BHOmXlpV297J08isMwjT0oVI0p0kS6lbfR iaAOLLoMIY3PCPGLZmjWyVKWd1U7X7Xvi6i8u6vLGWTdjR7N4kyhJJpao g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAJsM1FKQ/khN/2dsb2JhbABAGoMLOLpEgRQWdIIlAQEBBHgNBBsBAwECChYPCQMCAQIBDywCCAYNBgIBAQWHZwMRDTa/Ew2EeReMdIICGAaEMQSBU5RYgWyGRYYVhTuDLjs9 X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208,217";a="2901094" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 13 Jan 2014 16:01:41 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0DG1fbf004500 for ; Mon, 13 Jan 2014 16:01:41 GMT Message-ID: <52D40DE5.3060201@cisco.com> Date: Mon, 13 Jan 2014 17:01:41 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: NETCONF References: <20140113155326.2E4B97FC396@rfc-editor.org> In-Reply-To: <20140113155326.2E4B97FC396@rfc-editor.org> X-Forwarded-Message-Id: <20140113155326.2E4B97FC396@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------010007060205010401050809" Subject: [Netconf] Fwd: [Errata Held for Document Update] RFC6241 (3821) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:01:57 -0000 This is a multi-part message in MIME format. --------------010007060205010401050809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, There was much discussion on this errata, but no perfect text proposed AFAICT. It's now in the "Editorial", "Held for Document Update" From http://www.ietf.org/iesg/statement/errata-processing.html: *Hold for Document Update* - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update. The exact text might be discussed further in the WG when/if a bis document is worked on, or in an implementation guideline. Regards, Benoit -------- Original Message -------- Subject: [Errata Held for Document Update] RFC6241 (3821) Date: Mon, 13 Jan 2014 07:53:26 -0800 From: RFC Errata System To: , , , , CC: , , , The following errata report has been held for document update for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jonathan Hansford Date Reported: 2013-12-06 Held by: Benoit Claise (IESG) Section: 8.4.1 Original Text ------------- 8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the operation and the , , , and parameters for the operation. See Section 8.3 for further details on the operation. A confirmed operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter. The timeout period can be adjusted with the parameter. If a follow-up confirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed operation MAY introduce additional changes to the configuration. If the element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the element is given in the confirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing the confirmed commit is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued, unless the confirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the confirmed commit was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the confirmed commit. To cancel a confirmed commit and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the confirmed commit was issued, by using the operation. Corrected Text -------------- 8.4.1. Description The :confirmed-commit:1.1 capability indicates that the server will support the operation, the , , , and parameters for the operation, and differentiate between a ?to be confirmed? operation (a ?confirmed commit?) and a confirming operation. See Section 8.3 for further details on the operation. A confirmed operation MUST be reverted if a confirming commit is not issued within the timeout period (by default 600 seconds = 10 minutes). The confirming commit is a operation without the parameter and, if successful, cannot be reverted. The timeout period can be adjusted with the parameter. If a follow-up confirmed operation is issued before the timer expires, the timer is reset to the new value (600 seconds by default). Both the confirming commit and a follow-up confirmed operation MAY introduce additional changes to the configuration. If the element is not given in the confirmed commit operation, any follow-up commit and the confirming commit MUST be issued on the same session that issued the confirmed commit. If the element is given in the confirmed operation, a follow-up commit and the confirming commit can be given on any session, and they MUST include a element with a value equal to the given value of the element. If the server also advertises the :startup capability, a from running to startup is also necessary to save the changes to startup. If the session issuing a sequence of one or more confirmed commits is terminated for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued, unless the last confirmed commit also included a element. If the device reboots for any reason before the confirm timeout expires, the server MUST restore the configuration to its state before the sequence of confirmed commits was issued. If a confirming commit is not issued, the device will revert its configuration to the state prior to the issuance of the first in the current sequence of confirmed commits. To cancel the current sequence of confirmed commits and revert changes without waiting for the confirm timeout to expire, the client can explicitly restore the configuration to its state before the sequence of confirmed commits was issued, by using the operation. Notes ----- This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence. -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG . --------------010007060205010401050809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

There was much discussion on this errata, but no perfect text proposed AFAICT.
It's now in the "Editorial", "Held for Document Update"

From http://www.ietf.org/iesg/statement/errata-processing.html:
Hold for Document Update - The erratum is not a necessary update to the RFC. However, any future update of the document might consider this erratum, and determine whether it is correct and merits including in the update.
The exact text might be discussed further in the WG when/if a bis document is worked on, or in an implementation guideline.

Regards, Benoit


-------- Original Message --------
Subject: [Errata Held for Document Update] RFC6241 (3821)
Date: Mon, 13 Jan 2014 07:53:26 -0800
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: <jonathan@hansfords.net>, <rob.enns@gmail.com>, <mbj@tail-f.com>, <j.schoenwaelder@jacobs-university.de>, <andy@yumaworks.com>
CC: <bclaise@cisco.com>, <iesg@ietf.org>, <netconf@ietf.org>, <rfc-editor@rfc-editor.org> 


The following errata report has been held for document update 
for RFC6241, "Network Configuration Protocol (NETCONF)". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3821

--------------------------------------
Status: Held for Document Update
Type: Editorial

Reported by: Jonathan Hansford <jonathan@hansfords.net>
Date Reported: 2013-12-06
Held by: Benoit Claise (IESG)

Section: 8.4.1

Original Text
-------------
8.4.1.  Description



The :confirmed-commit:1.1 capability indicates that the server will

support the <cancel-commit> operation and the <confirmed>,

<confirm-timeout>, <persist>, and <persist-id> parameters for the

<commit> operation.  See Section 8.3 for further details on the

<commit> operation.



A confirmed <commit> operation MUST be reverted if a confirming

commit is not issued within the timeout period (by default 600

seconds = 10 minutes).  The confirming commit is a <commit> operation

without the <confirmed> parameter.  The timeout period can be

adjusted with the <confirm-timeout> parameter.  If a follow-up

confirmed <commit> operation is issued before the timer expires, the

timer is reset to the new value (600 seconds by default).  Both the

confirming commit and a follow-up confirmed <commit> operation MAY

introduce additional changes to the configuration.



If the <persist> element is not given in the confirmed commit

operation, any follow-up commit and the confirming commit MUST be

issued on the same session that issued the confirmed commit.  If the

<persist> element is given in the confirmed <commit> operation, a

follow-up commit and the confirming commit can be given on any

session, and they MUST include a <persist-id> element with a value

equal to the given value of the <persist> element.



If the server also advertises the :startup capability, a

<copy-config> from running to startup is also necessary to save the

changes to startup.



If the session issuing the confirmed commit is terminated for any

reason before the confirm timeout expires, the server MUST restore

the configuration to its state before the confirmed commit was

issued, unless the confirmed commit also included a <persist>

element.



If the device reboots for any reason before the confirm timeout

expires, the server MUST restore the configuration to its state

before the confirmed commit was issued.



If a confirming commit is not issued, the device will revert its

configuration to the state prior to the issuance of the confirmed

commit.  To cancel a confirmed commit and revert changes without

waiting for the confirm timeout to expire, the client can explicitly

restore the configuration to its state before the confirmed commit

was issued, by using the <cancel-commit> operation.

Corrected Text
--------------
8.4.1.  Description



The :confirmed-commit:1.1 capability indicates that the server will

support the <cancel-commit> operation, the <confirmed>, <confirm-

timeout>, <persist>, and <persist-id> parameters for the <commit>

operation, and differentiate between a “to be confirmed” <commit>

operation (a “confirmed commit”) and a confirming <commit>

operation. See Section 8.3 for further details on the <commit>

operation.



A confirmed <commit> operation MUST be reverted if a confirming

commit is not issued within the timeout period (by default 600

seconds = 10 minutes). The confirming commit is a <commit> operation

without the <confirmed> parameter and, if successful, cannot be

reverted. The timeout period can be adjusted with the <confirm-

timeout> parameter. If a follow-up confirmed <commit> operation is

issued before the timer expires, the timer is reset to the new value

(600 seconds by default). Both the confirming commit and a follow-up

confirmed <commit> operation MAY introduce additional changes to the

configuration.



If the <persist> element is not given in the confirmed commit

operation, any follow-up commit and the confirming commit MUST be

issued on the same session that issued the confirmed commit. If the

<persist> element is given in the confirmed <commit> operation, a

follow-up commit and the confirming commit can be given on any

session, and they MUST include a <persist-id> element with a value

equal to the given value of the <persist> element.



If the server also advertises the :startup capability, a <copy-

config> from running to startup is also necessary to save the

changes to startup. If the session issuing a sequence of one or more

confirmed commits is terminated for any reason before the confirm

timeout expires, the server MUST restore the configuration to its

state before the sequence of confirmed commits was issued, unless

the last confirmed commit also included a <persist> element.



If the device reboots for any reason before the confirm timeout

expires, the server MUST restore the configuration to its state

before the sequence of confirmed commits was issued.



If a confirming commit is not issued, the device will revert its

configuration to the state prior to the issuance of the first in the

current sequence of confirmed commits. To cancel the current

sequence of confirmed commits and revert changes without waiting for

the confirm timeout to expire, the client can explicitly restore the

configuration to its state before the sequence of confirmed commits

was issued, by using the <cancel-commit> operation.

Notes
-----
This erratum seeks to clarify the meaning of the term "confirmed commit" for those not familiar with the use of the term within JUNOS. In particular, that the use of "confirmed" is not in the sense of the adjective (meaning "firmly established") but rather that the commit needs to be confirmed. It also emphasises that a "confirming commit" cannot be reverted. Finally it identifies that it is possible to have a sequence of "confirmed commits" prior to a "confirming commit" and that, should no "confirming commit" be received, the configuration will revert to the state prior to the first "confirmed commit" in the sequence.

--------------------------------------
RFC6241 (draft-ietf-netconf-4741bis-10)
--------------------------------------
Title               : Network Configuration Protocol (NETCONF)
Publication Date    : June 2011
Author(s)           : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed.
Category            : PROPOSED STANDARD
Source              : Network Configuration
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

.


--------------010007060205010401050809-- From wwwrun@rfc-editor.org Mon Jan 13 08:03:41 2014 Return-Path: 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 427281AE181; Mon, 13 Jan 2014 08:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 jG4bpPL_yb1W; Mon, 13 Jan 2014 08:03:39 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C52241AE04F; Mon, 13 Jan 2014 08:03:39 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D7E327FC2CB; Mon, 13 Jan 2014 08:03:28 -0800 (PST) To: jonathan@hansfords.net, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com From: RFC Errata System Message-Id: <20140113160328.D7E327FC2CB@rfc-editor.org> Date: Mon, 13 Jan 2014 08:03:28 -0800 (PST) Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Held for Document Update] RFC6241 (3822) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:03:41 -0000 The following errata report has been held for document update for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3822 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jonathan Hansford Date Reported: 2013-12-06 Held by: Benoit Claise (IESG) Section: 8.4.4.1 Original Text ------------- Description: Cancels an ongoing confirmed commit. If the parameter is not given, the operation MUST be issued on the same session that issued the confirmed commit. Parameters: persist-id: Cancels a persistent confirmed commit. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. Corrected Text -------------- Description: Cancels an ongoing sequence of confirmed commits. If the parameter is not given, the operation MUST be issued on the same session that issued the sequence of confirmed commits. Parameters: persist-id: Cancels a persistent sequence of confirmed commits. The value MUST be equal to the value given in the parameter to the operation. If the value does not match, the operation fails with an "invalid-value" error. Notes ----- This erratum seeks to clarify that will cancel all configuration changes arising from a sequence of "confirmed commits". -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Jan 13 08:04:14 2014 Return-Path: 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 023E91AE181; Mon, 13 Jan 2014 08:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-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 Kue_FMQDVqmE; Mon, 13 Jan 2014 08:04:12 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 94C531AE04F; Mon, 13 Jan 2014 08:04:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 750E07FC2CB; Mon, 13 Jan 2014 08:04:00 -0800 (PST) To: jonathan@hansfords.net, rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com From: RFC Errata System Message-Id: <20140113160401.750E07FC2CB@rfc-editor.org> Date: Mon, 13 Jan 2014 08:04:00 -0800 (PST) Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, netconf@ietf.org Subject: [Netconf] [Errata Held for Document Update] RFC6241 (3823) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 16:04:14 -0000 The following errata report has been held for document update for RFC6241, "Network Configuration Protocol (NETCONF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6241&eid=3823 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Jonathan Hansford Date Reported: 2013-12-06 Held by: Benoit Claise (IESG) Section: 8.4.5.1 Original Text ------------- persist: Make the confirmed commit survive a session termination, and set a token on the ongoing confirmed commit. Corrected Text -------------- persist: Make the confirmed commit survive a session termination, and set a token on the ongoing sequence of confirmed commits. Notes ----- This erratum seeks to clarify that the use of the "persist" parameter will persist all configuration changes arising from a sequence of "confirmed commits". -------------------------------------- RFC6241 (draft-ietf-netconf-4741bis-10) -------------------------------------- Title : Network Configuration Protocol (NETCONF) Publication Date : June 2011 Author(s) : R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. Bierman, Ed. Category : PROPOSED STANDARD Source : Network Configuration Area : Operations and Management Stream : IETF Verifying Party : IESG From kwatsen@juniper.net Mon Jan 13 09:30:50 2014 Return-Path: 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 7E36E1AE00F for ; Mon, 13 Jan 2014 09:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 o3pJNyU6Z1eC for ; Mon, 13 Jan 2014 09:30:46 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E51AC4A7 for ; Mon, 13 Jan 2014 09:30:46 -0800 (PST) Received: from mail156-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 13 Jan 2014 17:30:35 +0000 Received: from mail156-va3 (localhost [127.0.0.1]) by mail156-va3-R.bigfish.com (Postfix) with ESMTP id 4788B3E0123; Mon, 13 Jan 2014 17:30:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzdb82h9371I119bIc85ehd799h4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah18de19h8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h1155h) Received-SPF: pass (mail156-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(377454003)(164054003)(45074003)(199002)(31966008)(80022001)(65816001)(79102001)(50986001)(69226001)(4396001)(56776001)(77096001)(83506001)(66066001)(74502001)(81816001)(83072002)(56816005)(85306002)(15975445006)(74662001)(47446002)(19580395003)(19580405001)(2656002)(54316002)(81542001)(15202345003)(77982001)(87266001)(83322001)(16236675002)(74366001)(81342001)(74876001)(49866001)(63696002)(81686001)(54356001)(47736001)(74706001)(80976001)(85852003)(87936001)(76786001)(59766001)(47976001)(561944002)(551934002)(53806001)(92566001)(16297215004)(76482001)(92726001)(90146001)(76796001)(36756003)(46102001)(93136001)(51856001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail156-va3 (localhost.localdomain [127.0.0.1]) by mail156-va3 (MessageSwitch) id 1389634232976134_17698; Mon, 13 Jan 2014 17:30:32 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.231]) by mail156-va3.bigfish.com (Postfix) with ESMTP id E5785440049; Mon, 13 Jan 2014 17:30:32 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 13 Jan 2014 17:30:30 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 13 Jan 2014 17:30:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.842.7; Mon, 13 Jan 2014 17:30:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.64]) with mapi id 15.00.0842.003; Mon, 13 Jan 2014 17:30:26 +0000 From: Kent Watsen To: Benoit Claise , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHF39qA///0OIA= Date: Mon, 13 Jan 2014 17:30:25 +0000 Message-ID: References: <52D3E647.9070000@cisco.com> In-Reply-To: <52D3E647.9070000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 00909363D5 Content-Type: multipart/alternative; boundary="_000_CEF9866957F28kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Pete Resnick , 'Barry Leiba' , Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 17:30:50 -0000 --_000_CEF9866957F28kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Benoit, One comment regarding the charter, current phase item #2 says: "Develop a = zero touch configuration document, specific the NETCONF reverse SSH use cas= e.". I thought we were doing it both for NETCONF reverse-SSH and NETCONF = reverse-TLS. Is it ok to amend this statement to include reverse-TLS too? Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are: #5. Support for configuration transactions across a number of devices would significantly simplify network configuration management. #13. It is important to distinguish between the distribution of configurations and the activation of a certain configuration. Devices should be able to hold multiple configurations. Is this an issue that needs to be addressed? Regarding northbound vs southbound protocols and different/competing soluti= ons to managed devices =96 I don't fully understand your concern. How is = an application (e.g. an NMS) presenting a RESTCONF interface causing a diff= erent or competing solution? Are you thinking that the requirements might= differ and, in our attempt to appease the app-folks, we somehow harm the s= olution for devices? I personally don't see this as the case; having just= re-read the RESTCONF =9603 draft, it is very much aligned with NETCONF and= therefore device-management. Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal = to HTTP and that which versions of HTTP it's compatible with doesn't need t= o be called out in the charter. That said, you raise a good point that the= RESTONF draft should be scrubbed so that it's clear that it's not specific= to HTTP 1.1. Thanks, Kent From: Benoit Claise > Date: Monday, January 13, 2014 8:12 AM To: "Ersue, Mehmet (NSN - DE/Munich)" > Cc: Pete Resnick >, 'Barry Leiba' = >, NetConf > Subject: Re: [Netconf] Netconf Charter update for approval Dear all, Sorry for the delay in getting back to you. Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and= we made a few modifications. You can follow up the temp charter text at http://datatracker.ietf.org/doc/= charter-ietf-netconf/ Under the history tab, there is a very useful diff tool. The version 15, dated May 31st is the current official charter The version 15-06, dated Jan 10th, is the charter as proposed below in = this email The version 15-11, dated today, is the charter after our discussion tod= ay. As you can see from the diffs: - we added the zero touch configuration document - we tried to justify why the YANG patch document is needed - we updated the milestones - we added an important sentence regarding the RESTCONF/NETCONF alignment: RESTCONF should not deviate from NETCONF unless proper justifications i= s provided and documented. - minor edits Feedback? I have two more points: 1. A question to which I've been receiving different answers from different= persons: I understand that RESTCONF is an additional simplified interface = that follows RESTful principles and is compatible with a resource-oriented = device abstraction, but will RESTCONF be in line with the RFC 3535 section = 3 requirements. I understand that those requirements are for the communication between the = NMS and the managed device. Hence my question during the last meeting opend= aylight presentation: will RESTCONF be used as north bound interface only p= rotocol, or also as a south bound interface. The answer was both: So we mig= ht have different (competing) solutions to managed devices. 2. HTTP2.0 is developed in the HTTPbis WG. I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it sti= ll work with HTTP2.0? Or is this completely orthogonal? I've not been been following the HTTP2.0 developments, so I don't even know= if this is a valid question, but I'm wondering if we should say something = about the HTTP 2.0 compatibility in the charter? Regards, Benoit Dear Benoit, hope you had restful holidays. Below is the charter proposal we prepared following the consensus calls and= review of the draft charter text, basically adding to the WG item list poi= nt 3. for the joint server configuration data model and point 4. for RESTCO= NF. We would like to ask you to initiate the re-chartering and the approval by = the IESG. Thank you. Bert & Mehmet --------------- Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Benoit Claise Joel Jaeggli Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol has the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting- related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimiz= e configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS = is an optional transport. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring th= e Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol is data modeling language independent, but YANG is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. 3. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate YANG module. 4. Develop a RESTful interface (RESTCONF) for accessing YANG data using the datastores defined in NETCONF. The YANG patch operation will be prepa= red in a separate draft. Goals and Milestones: Jan 2014 - Submit initial WG drafts for RESTCONF as WG item Apr 2014 - WGLC for RFC5539bis Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for NETCONF server configuration data model May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed St= andard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Sta= ndard Jun 2014 - WGLC for RESTCONF drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Stand= ard --_000_CEF9866957F28kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Benoit,

One comment regarding the charter, current phase item #2 says:  &= quot;Develop a zero touch configuration document, specific the NETCONF reve= rse SSH use case.".   I thought we were doing it both for NE= TCONF reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement to include reverse-TLS too?


Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) = are:

    #5.  Support for configuration transactions across = a number of devices
           would significantly simplify = network configuration management.

    #13. It is important to distinguish between the distribu= tion of
             configurations and the= activation of a certain configuration.
             Devices should be able= to hold multiple configurations.

Is this an issue that needs to be addressed?

Regarding northbound vs southbound protocols and different/compet= ing solutions to managed devices =96 I don't fully understand your concern.=   How is an application (e.g. an NMS) presenting a RESTCONF interface= causing a different or competing solution?   Are you thinking that the requirements might differ and, in our att= empt to appease the app-folks, we somehow harm the solution for devices? &n= bsp; I personally don't see this as the case; having just re-read the RESTC= ONF =9603 draft, it is very much aligned with NETCONF and therefore device-management.

Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthog= onal to HTTP and that which versions of HTTP it's compatible with doesn't n= eed to be called out in the charter.  That said, you raise a good poin= t that the RESTONF draft should be scrubbed so that it's clear that it's not specific to HTTP 1.1.

Thanks,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, January 13, 2014 8:12= AM
To: "Ersue, Mehmet (NSN - DE/M= unich)" <mehmet.ersue@nsn.c= om>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, 'Barry Le= iba' <barryleiba@computer.org= >, NetConf <netconf@ietf.org<= /a>>
Subject: Re: [Netconf] Netconf Char= ter update for approval

Dear all,

Sorry for the delay in getting back to you.

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and= we made a few modifications.
You can follow up the temp charter text at http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
    The version 15, dated May 31st is the current official c= harter
    The version 15-06, dated Jan 10th, is the charter as pro= posed below in this email
    The version 15-11, dated today, is the charter after our= discussion today.

As you can see from the diffs:
- we added the zero touch configuration document
- we tried to justify why the YANG patch document is needed
- we updated the milestones
- we added an important sentence regarding the RESTCONF/NETCONF alignment:<= br>     RESTCONF should not deviate from NETCONF unless proper j= ustifications is provided
    and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from different= persons: I understand that RESTCONF is an additional simplified interface = that follows RESTful principles and is compatible with a resource-oriented = device abstraction, but will RESTCONF be in line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between the = NMS and the managed device. Hence my question during the last meeting opend= aylight presentation: will RESTCONF be used as north bound interface only p= rotocol, or also as a south bound interface. The answer was both: So we might have different (competing) sol= utions to managed devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it sti= ll work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even know= if this is a valid question, but I'm wondering if we should say something = about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
Dear Benoit,
 
hope you had restful holidays.
 
Below is the charter proposal we prepared following the consensus call= s and review of the draft charter text, basically adding to the WG item lis= t point 3. for the joint server configuration data model and point 4. for R= ESTCONF.
 
We would like to ask you to initiate the re-chartering and the approva= l by the IESG. Thank you.
 
Bert & Mehmet
 
 
--------------- 
 
= Network Configuration (netconf)
= -------------------------------
=  
= Charter
=  
= Current Status: Active
=  
= Chairs:
=      Bert Wijnen <= ;bertietf@bwijnen.net>
=      Mehmet Ersue <= ;mehmet.ersue@nsn.com>
=  
= Operations and Management Area Directors:
=      Benoit Claise <bc= laise@cisco.com>
=      Joel Jaeggli <joe= lja@bogus.com>
=  
= Operations and Management Area Advisor:
=      Benoit Claise <bc= laise@cisco.com>
=  
= Mailing Lists:
=      General Discussion: netc= onf@ietf.org
=      To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
=      Archive:       =      http://www.ietf.org/mail-archive/web/netconf/
=  
= Description of Working Group:
=  
=   Configuration of networks of devices has become a critical requireme= nt
=   for operators in today's highly interconnected networks. Large and s= mall
=   operators alike have developed their own mechanisms or have used ven= dor
=   specific mechanisms to transfer configuration data to and from a dev= ice
=   and to examine device state information which may impact the<= /font>
=   configuration. Each of these mechanisms may be different in various<= /span>
=   aspects, such as session establishment, user authentication,<= /font>
=   configuration data exchange, and error responses.
=  
=   The NETCONF protocol has the following characteristics:
=  
=     - Provides retrieval mechanisms which can differentiate = between
=     configuration data and non-configuration data
=     - Is extensible enough so that vendors can provide acces= s to all
=     configuration data on the device using a single protocol=
=     - Has a programmatic interface (avoids screen scraping a= nd formatting-
=     related changes between releases)
=     - Uses an XML-based data representation, that can be eas= ily manipulated
=     using non-specialized XML manipulation tools.
=     - Supports integration with existing user authentication= methods
=     - Supports integration with existing configuration datab= ase systems
=     - Supports multiple (e.g. candidate and running) data-st= ores to optimize
=     configuration preparation and activation
=     - Supports network wide configuration transactions (with= features such
=     as locking and rollback capability)
=    - Runs over a secure transport; SSH is mandatory to implement = while TLS is an optional transport.
=     - Provides support for asynchronous notifications.
=     - Supports an Access Control Model and a YANG module for= configuring the
=     Access Control parameters.
=     - Supports a YANG module for System Notifications=
=  
=  
=   The NETCONF protocol is data modeling language independent, but YANG= is
=   the recommended NETCONF modeling language, which introduces advanced=
=   language features for configuration management.
=  
=   Based on the implementation, deployment experience and interoperabil= ity
=   testing, the WG aims to produce a NETCONF status report in a later s= tage.
=   The result may be clarifications for RFC6241 and RFC6242 and address= ing
=   any reported errata.
=  
=   In the current phase of NETCONF's incremental development the workgr= oup
=   will focus on following items:
=  
=   1. Develop the call home mechanism for the mandatory SSH binding (Re= verse
=   SSH) providing a server-initiated session establishment.
=  
=   2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., up= date
=   RFC 5539) and add the call home mechanism to provide a server-initia= ted
=   session establishment.
=  
=   3. Combine the server configuration data models from Reverse SSH and
=   RFC5539bis drafts in a separate YANG module.
=  
=   4. Develop a RESTful interface (RESTCONF) for accessing YANG data us= ing
=   the datastores defined in NETCONF. The YANG patch operation will be = prepared
=   in a separate draft.
=  
=  
= Goals and Milestones:
=   Jan 2014 - Submit initial WG drafts for RESTCONF as WG item
=   Apr 2014 - WGLC for RFC5539bis
=   Apr 2014 - WGLC for Reverse SSH
=   Apr 2014 - WGLC for NETCONF server configuration data model
=   May 2014 - Submit Reverse SSH to AD/IESG for consideration as Propos= ed Standard
=   May 2014 - Submit RFC5539bis to AD/IESG for consideration as Propose= d Standard
=   Jun 2014 - WGLC for RESTCONF drafts
=   Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed = Standard 
 
 

 --_000_CEF9866957F28kwatsenjunipernet_-- From barryleiba@gmail.com Tue Jan 14 07:31:18 2014 Return-Path: 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 999451AE0EA for ; Tue, 14 Jan 2014 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 C5cZ3MOzkM8C for ; Tue, 14 Jan 2014 07:31:17 -0800 (PST) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id E27991AE0F7 for ; Tue, 14 Jan 2014 07:31:11 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id cm18so6524629qab.9 for ; Tue, 14 Jan 2014 07:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ntgprsOUaLJailPdgDr/pQxyYBBxkc0y6QMkAE7YoiM=; b=iqR8qObuJ6BwEx7oMXBf2oBcJ4oTQHSQ9ShF2wxKrH50CqYOdViJkxFmhlmAtsbz5d LT9OnCPMcA2q7pmCq5W5FOUr0XUq2+rZJGNkVdIoE8mMaBO90nCzrae4Y86bnBupHyT1 N32EchuVlfjXCSJBPjtvPvXPZTIWkk9hPEBvBoVMOBnOuCK9RZlaYn/37SRq6M1oI5ZO 66jC1erMjMWUMY13f3HUagi7xFQjaItnkqAUzeZMijVciRJ8vrK8hRsqkTRwPBtqTj87 axN158m7uih2NqBhct+6pa0bn3haX1uKekDMh4YrtSfrTPo6afnF0+GoKuFxI6UK6OWj THnw== MIME-Version: 1.0 X-Received: by 10.224.166.70 with SMTP id l6mr3810460qay.25.1389713460367; Tue, 14 Jan 2014 07:31:00 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.23.67 with HTTP; Tue, 14 Jan 2014 07:31:00 -0800 (PST) In-Reply-To: <52D3E647.9070000@cisco.com> References: <52D3E647.9070000@cisco.com> Date: Tue, 14 Jan 2014 10:31:00 -0500 X-Google-Sender-Auth: mG9L7llTKDCYGDuqNExA6DseebM Message-ID: From: Barry Leiba To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Cc: Pete Resnick , Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 15:31:18 -0000 Hi, all. Just hitting the one App-related part: > 2. HTTP2.0 is developed in the HTTPbis WG. > I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it > still work with HTTP2.0? Or is this completely orthogonal? > I've not been been following the HTTP2.0 developments, so I don't even know > if this is a valid question, but I'm wondering if we should say something > about the HTTP 2.0 compatibility in the charter? I think there's no issue here. First, http 2.0 won't be suitable for all situations, and http 1.1 will be around and considered current for a very long time yet. Second, http 2.0 is being designed to be protocol compatible with http 1.1. Implementations will have to change to use http 2.0, but those changes should involve code around the edges, not at the core. At the core, other protocols should not have to change to become http-2.0-aware. > hope you had restful holidays. RESTful? Hahahahaha...... Barry, Applications AD From bclaise@cisco.com Tue Jan 14 08:44:47 2014 Return-Path: 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 C06971AE14C for ; Tue, 14 Jan 2014 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 MIHwl3ThrrMg for ; Tue, 14 Jan 2014 08:44:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 74DD41ADFD0 for ; Tue, 14 Jan 2014 08:44:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41245; q=dns/txt; s=iport; t=1389717868; x=1390927468; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZQqv5RJY5nKdQ6ogfdMvNm2sRR40+J1WFuP0S5r7jmg=; b=AB4PtxOB6c1cbcRXdfPd5DWT33iR1uHnF/hDQg0PVq7uxYFRiVZ0q5M0 VaA/UkJqtGt/PXjG6heVZJjxJfLENrwC8wXYIUAeGp86m5tBt6bMI11dF aW3DGyjeGrOi6QfOYtQ+el8bfzOS4oGJlFfFd+VVSLCBdRt07ZEoZ/MOK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAARp1VKQ/khL/2dsb2JhbABagkdEOLpjT4EVFnSCJQEBAQQBAQEqQQYEARALDgMDAQIKAxMBAQYHCQMCAQIBFR8JCAYKAwEFAgEBBRKHaQ3ENBeOGwoQAgE+EQeENwSTdoQogTCFFYtQgy47gTU X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208,217";a="2950197" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 14 Jan 2014 16:44:26 +0000 Received: from [10.149.0.203] (dhcp-10-149-0-203.cisco.com [10.149.0.203]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EGiQvf020943; Tue, 14 Jan 2014 16:44:26 GMT Message-ID: <52D5696A.8040201@cisco.com> Date: Tue, 14 Jan 2014 17:44:26 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Kent Watsen , "Ersue, Mehmet (NSN - DE/Munich)" References: <52D3E647.9070000@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000307010306040509080405" Cc: Pete Resnick , 'Barry Leiba' , Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 16:44:48 -0000 This is a multi-part message in MIME format. --------------000307010306040509080405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Kent, > Hi Benoit, > > One comment regarding the charter, current phase item #2 says: > "Develop a zero touch configuration document, specific the NETCONF > reverse SSH use case.". I thought we were doing it both for NETCONF > reverse-SSH and NETCONF reverse-TLS. Is it ok to amend this statement > to include reverse-TLS too? Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are: > > #5. Support for configuration transactions across a number of devices > would significantly simplify network configuration management. > > #13. It is important to distinguish between the distribution of > configurations and the activation of a certain configuration. > Devices should be able to hold multiple configurations. > > Is this an issue that needs to be addressed? From the charter "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented." > > Regarding northbound vs southbound protocols and different/competing > solutions to managed devices – I don't fully understand your concern. > How is an application (e.g. an NMS) presenting a RESTCONF interface > causing a different or competing solution? Are you thinking that the > requirements might differ and, in our attempt to appease the > app-folks, we somehow harm the solution for devices? I personally > don't see this as the case; having just re-read the RESTCONF –03 > draft, it is very much aligned with NETCONF and therefore > device-management. I simply meant that, if RESTCONF would be used as a northbound protocol, and NETCONF as southbound protocol, the messaging would have been easier as RESTCONF and NETCONF would not be competent protocols. > > Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely > orthogonal to HTTP and that which versions of HTTP it's compatible > with doesn't need to be called out in the charter. That said, you > raise a good point that the RESTONF draft should be scrubbed so that > it's clear that it's not specific to HTTP 1.1. Barry answered that. We're good. Regards, Benoit > > Thanks, > Kent > > > From: Benoit Claise > > Date: Monday, January 13, 2014 8:12 AM > To: "Ersue, Mehmet (NSN - DE/Munich)" > > Cc: Pete Resnick >, 'Barry Leiba' > >, NetConf > > > Subject: Re: [Netconf] Netconf Charter update for approval > > Dear all, > > Sorry for the delay in getting back to you. > > Today Bert, Mehmet, and I had a quick conf. call regarding the > charter, and we made a few modifications. > You can follow up the temp charter text at > http://datatracker.ietf.org/doc/charter-ietf-netconf/ > Under the history tab, there is a very useful diff tool. > The version 15, dated May 31st is the current official charter > The version 15-06, dated Jan 10th, is the charter as proposed > below in this email > The version 15-11, dated today, is the charter after our > discussion today. > > As you can see from the diffs: > - we added the zero touch configuration document > - we tried to justify why the YANG patch document is needed > - we updated the milestones > - we added an important sentence regarding the RESTCONF/NETCONF alignment: > RESTCONF should not deviate from NETCONF unless proper > justifications is provided > and documented. > - minor edits > > Feedback? > > I have two more points: > > 1. A question to which I've been receiving different answers from > different persons: I understand that RESTCONF is an additional > simplified interface that follows RESTful principles and is compatible > with a resource-oriented device abstraction, but will RESTCONF be in > line with the RFC 3535 section 3 requirements. > I understand that those requirements are for the communication between > the NMS and the managed device. Hence my question during the last > meeting opendaylight presentation: will RESTCONF be used as north > bound interface only protocol, or also as a south bound interface. The > answer was both: So we might have different (competing) solutions to > managed devices. > > 2. HTTP2.0 is developed in the HTTPbis WG. > I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will > it still work with HTTP2.0? Or is this completely orthogonal? > I've not been been following the HTTP2.0 developments, so I don't even > know if this is a valid question, but I'm wondering if we should say > something about the HTTP 2.0 compatibility in the charter? > > Regards, Benoit >> Dear Benoit, >> hope you had restful holidays. >> Below is the charter proposal we prepared following the consensus >> calls and review of the draft charter text, basically adding to the >> WG item list point 3. for the joint server configuration data model >> and point 4. for RESTCONF. >> We would like to ask you to initiate the re-chartering and the >> approval by the IESG. Thank you. >> Bert & Mehmet >> --------------- >> Network Configuration (netconf) >> ------------------------------- >> Charter >> Current Status: Active >> Chairs: >> Bert Wijnen >> Mehmet Ersue >> Operations and Management Area Directors: >> Benoit Claise >> Joel Jaeggli >> Operations and Management Area Advisor: >> Benoit Claise >> Mailing Lists: >> General Discussion: netconf@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/netconf >> Archive: http://www.ietf.org/mail-archive/web/netconf/ >> Description of Working Group: >> Configuration of networks of devices has become a critical requirement >> for operators in today's highly interconnected networks. Large and >> small >> operators alike have developed their own mechanisms or have used vendor >> specific mechanisms to transfer configuration data to and from a device >> and to examine device state information which may impact the >> configuration. Each of these mechanisms may be different in various >> aspects, such as session establishment, user authentication, >> configuration data exchange, and error responses. >> The NETCONF protocol has the following characteristics: >> - Provides retrieval mechanisms which can differentiate between >> configuration data and non-configuration data >> - Is extensible enough so that vendors can provide access to all >> configuration data on the device using a single protocol >> - Has a programmatic interface (avoids screen scraping and >> formatting- >> related changes between releases) >> - Uses an XML-based data representation, that can be easily >> manipulated >> using non-specialized XML manipulation tools. >> - Supports integration with existing user authentication methods >> - Supports integration with existing configuration database systems >> - Supports multiple (e.g. candidate and running) data-stores to >> optimize >> configuration preparation and activation >> - Supports network wide configuration transactions (with features >> such >> as locking and rollback capability) >> - Runs over a secure transport; SSH is mandatory to implement >> while TLS is an optional transport. >> - Provides support for asynchronous notifications. >> - Supports an Access Control Model and a YANG module for >> configuring the >> Access Control parameters. >> - Supports a YANG module for System Notifications >> The NETCONF protocol is data modeling language independent, but YANG is >> the recommended NETCONF modeling language, which introduces advanced >> language features for configuration management. >> Based on the implementation, deployment experience and >> interoperability >> testing, the WG aims to produce a NETCONF status report in a later >> stage. >> The result may be clarifications for RFC6241 and RFC6242 and >> addressing >> any reported errata. >> In the current phase of NETCONF's incremental development the workgroup >> will focus on following items: >> 1. Develop the call home mechanism for the mandatory SSH binding >> (Reverse >> SSH) providing a server-initiated session establishment. >> 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., >> update >> RFC 5539) and add the call home mechanism to provide a server-initiated >> session establishment. >> 3. Combine the server configuration data models from Reverse SSH and >> RFC5539bis drafts in a separate YANG module. >> 4. Develop a RESTful interface (RESTCONF) for accessing YANG data >> using >> the datastores defined in NETCONF. The YANG patch operation will be >> prepared >> in a separate draft. >> Goals and Milestones: >> Jan 2014 - Submit initial WG drafts for RESTCONF as WG item >> Apr 2014 - WGLC for RFC5539bis >> Apr 2014 - WGLC for Reverse SSH >> Apr 2014 - WGLC for NETCONF server configuration data model >> May 2014 - Submit Reverse SSH to AD/IESG for consideration as >> Proposed Standard >> May 2014 - Submit RFC5539bis to AD/IESG for consideration as >> Proposed Standard >> Jun 2014 - WGLC for RESTCONF drafts >> Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed >> Standard > --------------000307010306040509080405 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Kent,
Hi Benoit,

One comment regarding the charter, current phase item #2 says:  "Develop a zero touch configuration document, specific the NETCONF reverse SSH use case.".   I thought we were doing it both for NETCONF reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement to include reverse-TLS too?
Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/


Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are:

    #5.  Support for configuration transactions across a number of devices
           would significantly simplify network configuration management.

    #13. It is important to distinguish between the distribution of
             configurations and the activation of a certain configuration.
             Devices should be able to hold multiple configurations.

Is this an issue that needs to be addressed?
From the charter "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented."

Regarding northbound vs southbound protocols and different/competing solutions to managed devices – I don't fully understand your concern.   How is an application (e.g. an NMS) presenting a RESTCONF interface causing a different or competing solution?   Are you thinking that the requirements might differ and, in our attempt to appease the app-folks, we somehow harm the solution for devices?   I personally don't see this as the case; having just re-read the RESTCONF –03 draft, it is very much aligned with NETCONF and therefore device-management.
I simply meant that, if RESTCONF would be used as a northbound protocol, and NETCONF as southbound protocol, the messaging would have been easier as RESTCONF and NETCONF would not be competent protocols.

Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal to HTTP and that which versions of HTTP it's compatible with doesn't need to be called out in the charter.  That said, you raise a good point that the RESTONF draft should be scrubbed so that it's clear that it's not specific to HTTP 1.1.
Barry answered that. We're good.

Regards, Benoit

Thanks,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Monday, January 13, 2014 8:12 AM
To: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Cc: Pete Resnick <presnick@qti.qualcomm.com>, 'Barry Leiba' <barryleiba@computer.org>, NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Netconf Charter update for approval

Dear all,

Sorry for the delay in getting back to you.

Today Bert, Mehmet, and I had a quick conf. call regarding the charter, and we made a few modifications.
You can follow up the temp charter text at http://datatracker.ietf.org/doc/charter-ietf-netconf/
Under the history tab, there is a very useful diff tool.
    The version 15, dated May 31st is the current official charter
    The version 15-06, dated Jan 10th, is the charter as proposed below in this email
    The version 15-11, dated today, is the charter after our discussion today.

As you can see from the diffs:
- we added the zero touch configuration document
- we tried to justify why the YANG patch document is needed
- we updated the milestones
- we added an important sentence regarding the RESTCONF/NETCONF alignment:
    RESTCONF should not deviate from NETCONF unless proper justifications is provided
    and documented.
- minor edits

Feedback?

I have two more points:

1. A question to which I've been receiving different answers from different persons: I understand that RESTCONF is an additional simplified interface that follows RESTful principles and is compatible with a resource-oriented device abstraction, but will RESTCONF be in line with the RFC 3535 section 3 requirements.
I understand that those requirements are for the communication between the NMS and the managed device. Hence my question during the last meeting opendaylight presentation: will RESTCONF be used as north bound interface only protocol, or also as a south bound interface. The answer was both: So we might have different (competing) solutions to managed devices.

2. HTTP2.0 is developed in the HTTPbis WG.
I see that draft-bierman-netconf-restconf is based on HTTP 1.1. Will it still work with HTTP2.0? Or is this completely orthogonal?
I've not been been following the HTTP2.0 developments, so I don't even know if this is a valid question, but I'm wondering if we should say something about the HTTP 2.0 compatibility in the charter?

Regards, Benoit
Dear Benoit,
 
hope you had restful holidays.
 
Below is the charter proposal we prepared following the consensus calls and review of the draft charter text, basically adding to the WG item list point 3. for the joint server configuration data model and point 4. for RESTCONF.
 
We would like to ask you to initiate the re-chartering and the approval by the IESG. Thank you.
 
Bert & Mehmet
 
 
--------------- 
 
Network Configuration (netconf)
-------------------------------
 
Charter
 
Current Status: Active
 
Chairs:
     Bert Wijnen <bertietf@bwijnen.net>
     Mehmet Ersue <mehmet.ersue@nsn.com>
 
Operations and Management Area Directors:
     Benoit Claise <bclaise@cisco.com>
     Joel Jaeggli <joelja@bogus.com>
 
Operations and Management Area Advisor:
     Benoit Claise <bclaise@cisco.com>
 
Mailing Lists:
     General Discussion: netconf@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            http://www.ietf.org/mail-archive/web/netconf/
 
Description of Working Group:
 
  Configuration of networks of devices has become a critical requirement
  for operators in today's highly interconnected networks. Large and small
  operators alike have developed their own mechanisms or have used vendor
  specific mechanisms to transfer configuration data to and from a device
  and to examine device state information which may impact the
  configuration. Each of these mechanisms may be different in various
  aspects, such as session establishment, user authentication,
  configuration data exchange, and error responses.
 
  The NETCONF protocol has the following characteristics:
 
    - Provides retrieval mechanisms which can differentiate between
    configuration data and non-configuration data
    - Is extensible enough so that vendors can provide access to all
    configuration data on the device using a single protocol
    - Has a programmatic interface (avoids screen scraping and formatting-
    related changes between releases)
    - Uses an XML-based data representation, that can be easily manipulated
    using non-specialized XML manipulation tools.
    - Supports integration with existing user authentication methods
    - Supports integration with existing configuration database systems
    - Supports multiple (e.g. candidate and running) data-stores to optimize
    configuration preparation and activation
    - Supports network wide configuration transactions (with features such
    as locking and rollback capability)
   - Runs over a secure transport; SSH is mandatory to implement while TLS is an optional transport.
    - Provides support for asynchronous notifications.
    - Supports an Access Control Model and a YANG module for configuring the
    Access Control parameters.
    - Supports a YANG module for System Notifications
 
 
  The NETCONF protocol is data modeling language independent, but YANG is
  the recommended NETCONF modeling language, which introduces advanced
  language features for configuration management.
 
  Based on the implementation, deployment experience and interoperability
  testing, the WG aims to produce a NETCONF status report in a later stage.
  The result may be clarifications for RFC6241 and RFC6242 and addressing
  any reported errata.
 
  In the current phase of NETCONF's incremental development the workgroup
  will focus on following items:
 
  1. Develop the call home mechanism for the mandatory SSH binding (Reverse
  SSH) providing a server-initiated session establishment.
 
  2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
  RFC 5539) and add the call home mechanism to provide a server-initiated
  session establishment.
 
  3. Combine the server configuration data models from Reverse SSH and
  RFC5539bis drafts in a separate YANG module.
 
  4. Develop a RESTful interface (RESTCONF) for accessing YANG data using
  the datastores defined in NETCONF. The YANG patch operation will be prepared
  in a separate draft.
 
 
Goals and Milestones:
  Jan 2014 - Submit initial WG drafts for RESTCONF as WG item
  Apr 2014 - WGLC for RFC5539bis
  Apr 2014 - WGLC for Reverse SSH
  Apr 2014 - WGLC for NETCONF server configuration data model
  May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed Standard
  May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard
  Jun 2014 - WGLC for RESTCONF drafts
  Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard 
 
 

--------------000307010306040509080405-- From andy@yumaworks.com Tue Jan 14 09:20:41 2014 Return-Path: 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 3848D1AE13C for ; Tue, 14 Jan 2014 09:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LVuRzPR87peN for ; Tue, 14 Jan 2014 09:20:32 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9861AE125 for ; Tue, 14 Jan 2014 09:20:30 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id k5so7635360qej.7 for ; Tue, 14 Jan 2014 09:20:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8QMHVJm8k4Ly+nQIm7AZ2LdV3AD4hysHxYHOIm3x7cw=; b=h3BTGdPHfwi7yyW0TCwb2Hm6zcDxnmM5QnonfetWgw34bUVS5DIAT2i18jtih9UdJj G5unFxNJzFaZs1PvnxH4cK+NTi9KWYtskSo0XLRW4UpW/WDlvDFlD5jIEIUuBoOO/kSo v5PmalxL1GH7MF4nDRHZ3IRJKuhVDcsqtxAncZUkarORXmfvFuR7enqJlFVWWA5MeZSL 5VdKbJU0tg5q/X4jpuHaQ61wLzM+XvIsnR2j43yfx2DgnxAJburtYwRZvA/FfIOONLun s2Q1OiTBHGBYtJH0l2YjXAPlKfWes4XO7XGo1pIZUq7dYA+cFUhvuGizwwI8tCCA/qtY +sAg== X-Gm-Message-State: ALoCoQmoahd4I83wZ8GrXUWpiUsLiLDcgGjUkXI7eMX3mr+NCnC4WHafHF8t+bpWfxIzg7orsSxY MIME-Version: 1.0 X-Received: by 10.49.2.170 with SMTP id 10mr5125916qev.24.1389720018598; Tue, 14 Jan 2014 09:20:18 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 14 Jan 2014 09:20:18 -0800 (PST) In-Reply-To: <52D5696A.8040201@cisco.com> References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> Date: Tue, 14 Jan 2014 09:20:18 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=047d7b6da3d40bd32304eff168c6 Cc: Pete Resnick , Barry Leiba , Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 17:20:41 -0000 --047d7b6da3d40bd32304eff168c6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise wrote: > Hi Kent, > > Hi Benoit, > > One comment regarding the charter, current phase item #2 says: "Develop > a zero touch configuration document, specific the NETCONF reverse SSH use > case.". I thought we were doing it both for NETCONF reverse-SSH and > NETCONF reverse-TLS. Is it ok to amend this statement to include > reverse-TLS too? > > Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/ > > > > Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) > are: > > #5. Support for configuration transactions across a number of > devices > would significantly simplify network configuration management. > > #13. It is important to distinguish between the distribution of > configurations and the activation of a certain > configuration. > Devices should be able to hold multiple configurations. > > Is this an issue that needs to be addressed? > > From the charter "RESTCONF should not deviate from NETCONF unless proper > justifications is provided and documented." > > > I this this text is problematic. The WG is not addressing #5 above at this time. #13 requires interpretation. It could mean support for named configurations and the ability to boot (or switch at runtime) between them. NETCONF does not support that either. IMO this "should not deviate" sentence needs to be replaced. NETCONF has sessions and operations tuned for session-based management. It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. RESTCONF is going to deviate from that. RESTCONF imposes a resource model on the content and NETCONF does not. I think the intent is that the impact on a NETCONF server implementation should be kept at a minimum. No new features can be added that would break a NETCONF client managing a dual NETCONF/RESTCONF server. > Regarding northbound vs southbound protocols and different/competing > solutions to managed devices =96 I don't fully understand your concern. = How > is an application (e.g. an NMS) presenting a RESTCONF interface causing a > different or competing solution? Are you thinking that the requirements > might differ and, in our attempt to appease the app-folks, we somehow har= m > the solution for devices? I personally don't see this as the case; havi= ng > just re-read the RESTCONF =9603 draft, it is very much aligned with NETCO= NF > and therefore device-management. > > I simply meant that, if RESTCONF would be used as a northbound protocol, > and NETCONF as southbound protocol, the messaging would have been easier = as > RESTCONF and NETCONF would not be competent protocols. > Northbound vs. southbound is a very subjective distinction. RESTCONF vs. NETCONF is a project-specific engineering decision about tools, training, and how much device-specific control the application really needs from the server(s). IMO, YANG is the real difference maker. RESTCONF is about getting HTTP app developers to use YANG, rather than getting NETCONF app developers to use RESTCONF. > Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely > orthogonal to HTTP and that which versions of HTTP it's compatible with > doesn't need to be called out in the charter. That said, you raise a goo= d > point that the RESTONF draft should be scrubbed so that it's clear that > it's not specific to HTTP 1.1. > > Barry answered that. We're good. > > Regards, Benoit > Thanks, > Kent > > Andy --047d7b6da3d40bd32304eff168c6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,


On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise <bclaise@cisco.c= om> wrote:
=20 =20 =20
Hi Kent,
=20
Hi Benoit,

One comment regarding the charter, current phase item #2 says: =A0"Develop a zero touch configuration document, specifi= c the NETCONF reverse=A0SSH use case.". =A0 I thought we were do= ing it both for NETCONF reverse-SSH and NETCONF reverse-TLS. =A0Is it ok to amend this statement to include reverse-TLS too?
Updated. See http://datatracker.ietf.org/doc/charter-ietf-netc= onf/


Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are:

=A0 =A0 #5. =A0Support for configuration transactions across a number of devices
=A0 =A0 =A0 =A0 =A0 =A0would significantly simplify network configuration management.

=A0 =A0 #13. It is important to distinguish between the distribution of
=A0 =A0 =A0 =A0 =A0 =A0 =A0configurations and the activation o= f a certain configuration.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Devices should be able to hold mult= iple configurations.

Is this an issue that needs to be addressed?
From the charter "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented."


I = this this text is problematic.
The WG is not addressing #5 above = at this time.

#13 requires interpretation. It coul= d mean support for
named configurations and the ability to boot (or switch
at r= untime) between them. NETCONF does not support that either.

<= /div>
IMO this "should not deviate" sentence needs to be repl= aced.
NETCONF has sessions and operations tuned for session-based management= .
It takes up to 8 request/response pairs to accomplish 1 edit in= NETCONF.
RESTCONF is going to deviate from that. RESTCONF impose= s a resource
model on the content and NETCONF does not.

I = think the intent is that the impact on a NETCONF server implementation
should be kept at a minimum. =A0No new features can be added that wou= ld
break a NETCONF client managing a dual NETCONF/RESTCONF server.
<= div>

=A0
<= div bgcolor=3D"#FFFFFF" text=3D"#000000">
Regarding northbound vs southbound protocols and=A0different/competing solutions to managed devices =96 I don= 9;t fully understand your concern. =A0 How is an application (e.g. an NMS) presenting a RESTCONF interface causing a different or competing solution? =A0 Are you thinking that the requirements might differ and, in our attempt to appease the app-folks, we somehow harm the solution for devices? =A0 I personally don't s= ee this as the case; having just re-read the RESTCONF =9603 draft, it is very much aligned with NETCONF and therefore device-management.
I simply meant that, if RESTCONF would be used as a northbound protocol, and NETCONF as southbound protocol, the messaging would have been easier as RESTCONF and NETCONF would not be competent protocols.


Nor= thbound vs. southbound is a very subjective distinction.
RESTCONF= vs. NETCONF is a project-specific engineering
decision about too= ls, training, and how much device-specific
control the application really needs from the server(s).
IMO= , YANG is the real difference maker. RESTCONF is
about getting HT= TP app developers to use YANG, rather
than getting NETCONF app de= velopers to use RESTCONF.




Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal to HTTP and that which versions of HTTP it's compatible with doesn't need to be called out in the charter. =A0That said, you raise a good point that the RESTONF draft should be scrubbed so that it's clear that it's not specific to HTTP 1.1.
Barry answered that. We're good.

Regards, Benoit
=20
Thanks,
Kent


An= dy
=A0
--047d7b6da3d40bd32304eff168c6-- From jclarke@cisco.com Tue Jan 14 10:03:18 2014 Return-Path: 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 13E491AE101 for ; Tue, 14 Jan 2014 10:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 EoTTh7dbGAV7 for ; Tue, 14 Jan 2014 10:03:16 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 86B541ADFB6 for ; Tue, 14 Jan 2014 10:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2726; q=dns/txt; s=iport; t=1389722585; x=1390932185; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=spYzXvGctvIhWpQuOEULbTrSNEG7wqCbg8I9oTNYIFQ=; b=Yhjx8hEfpG6Adk+z8hqecJJSWdkVs9Jpu7u39N+gJNn5cByzbFT8U0S5 fJItP88RDZlByLf7wS7MjkLejBYpwiROedlqpAWA5GNLOXmahpQ3qsBCZ ipznIIvvSsUXfDBulYNcPwIWVDHxaaYYRiAJp+PnoF1PIcmgyDRF25Zd9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAPR61VKtJXG9/2dsb2JhbABaDoJ9OINUt16BFRZ0giUBAQEDASNVBgsLDgoCAgUWCwICCQMCAQIBRQYBDAgBAYd4CA2oUpsQF4EpjWWCb4FIAQOJRYpzg2aBMJBlgm5dHg X-IronPort-AV: E=Sophos;i="4.95,658,1384300800"; d="scan'208";a="12796814" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 14 Jan 2014 18:03:04 +0000 Received: from dhcp-10-150-54-98.cisco.com (dhcp-10-150-54-98.cisco.com [10.150.54.98]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0EI335h000792; Tue, 14 Jan 2014 18:03:04 GMT Message-ID: <52D57BD7.7060006@cisco.com> Date: Tue, 14 Jan 2014 13:03:03 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tal Mizrahi , netconf@ietf.org References: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> In-Reply-To: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 18:03:18 -0000 On 1/2/14, 10:56 AM, Tal Mizrahi wrote: > > Hi, > > We have posted an updated draft: > http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 > > Thanks to all the people who reviewed and sent comments about draft 00. > Here is a summary of the changes compared to draft 00: > - We have added discussion about the scheduling tolerance: an upper > bound on how far into the future/past an RPC can be scheduled. > - The scheduled time now refers to the *start* time of the operation, > rather than to its completion. > - The time format has been changed to date-and-time. I read through the draft, Tal, and I have a few comments. Section 3.1: I think there should be a way to query the server's current time to make sure the client and server agree. This should be part of the overall dialogue between the two when scheduling will be done. Even though the client may be configured to use NTP, the server may not have had a chance to sync to its clock source. You talk about time sync, but I think this extra level of checking will assure that the server doesn't do something the client didn't expect. At the very least, the client may decide to abort the scheduled operation. This goes outside of the time tolerance you define in Section 3.5. I could, for example, say I have a 10 second tolerance in either direction of time 2015-10-21T04:29:00.235. The server gets a chance to execute at 2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015-10-21T05:29:00.235. Section 3.4: You introduce time-interval here without really saying how it will be used. You do this later, but it seemed a bit disjointed to me. Maybe swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4. Section 4.5 You define the element but you reference it as : OLD TEXT: ...operation. Every message MAY include the ... NEW TEXT: ...operation. Every message MAY include the ... NIT: I would swap the order of and as the former references the latter. Section 4.5.1: You have two leaf nodes with the name sched-max-past. They have two different descriptions. I think the first should be sched-max-future. > At this point, draft 01 is soft-real-time-oriented. We are interested to > hear feedback about whether there is an interest in the working group to > develop the hard real-time functionality as well. I think soft time is fine. However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC. How would I go about ensuring that an RPC completed (or not) at the scheduled time? Joe From wdec.ietf@gmail.com Tue Jan 14 12:13:40 2014 Return-Path: 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 CBCB71AE13E for ; Tue, 14 Jan 2014 12:13:40 -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 4or739dNRw-v for ; Tue, 14 Jan 2014 12:13:37 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D59FF1AE210 for ; Tue, 14 Jan 2014 12:13:37 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so107383pbb.18 for ; Tue, 14 Jan 2014 12:13:26 -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=EKIWlzkddFkhVjwhEzD+yewldCP5gGwApBD7cqYBI84=; b=kCaGMrpvbfXY7ayInhtgFobddFaRaHGZHrfLCBTM/7QjZU3wXHzjjgyUSUQspwVxzt FUm6eBqcExfTTBA//CcrAwZuqBc8qipxNdfnMhWcAoiL8DZ2DZzGJV6RD1TJlY7nKBdW RtA65xdzk+sqk0SCZzlzIw23VLO0QMH4JohZv3YkutpUHUIP4N9WupIf2BvyCPNUuHg1 I383QPB6PDXzWkguznMaX4EF/7C17NVC0J5ukSjcy+0WwusbQi5tyvafkL0srXFm0umR 95L8iljS/rHNWUA+251cDnW9yU4Uo2nOPpFaXWQit8AxvirrdGaJYoKYsss4Q6wGJ27B A3Yw== MIME-Version: 1.0 X-Received: by 10.68.233.33 with SMTP id tt1mr4087543pbc.64.1389730406329; Tue, 14 Jan 2014 12:13:26 -0800 (PST) Received: by 10.70.57.163 with HTTP; Tue, 14 Jan 2014 12:13:26 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 21:13:26 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model (was Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 20:13:40 -0000 On 10 January 2014 19:03, Andy Bierman wrote: > Hi, > > The resource management model is a fairly important part of > the RESTCONF architecture. Perhaps all attempts so far have > been too simplistic. > > The YANG node type seems to be irrelevant to answering > the question "what is a sub-resource?" The set of mandatory[1] > descendant nodes are not sub-resources of a given parent. > They must exist and cannot be created and deleted > independently of the parent resource. So a sub-resource > is really any descendant sub-tree that can be created and > deleted independent of the parent resource. > > IMO there should not be a complex set of rules for restricting URIs > and HTTP methods, based on mandatory vs. optional nodes. > This is a conceptual distinction which does not need to be > enforced somehow in the protocol. The problem is that in designing an API, it's generally crucial to allow the designer to control how the API will be consumed. The -03 Restconf spec removes most of such controls by not distinguishing between a resource and its sub-resources: every possible data item is a URI resource possibly exposed to the HTTP verbs, and likewise every resource is a data item of its parent resource. Relying on the client in "knowing" the "right way" in which to consume an API will lead to poor API experience(s) and breakages like leading to corrupt data, besides likely gross deviation from REST principles. An Example of the corruption problem was/is presented below in the original text in the "update tax-amount along with price" example. Relying on the client to "do the right thing" is problematic, if the history of API usage is anything to go by. The way I see it: Draft -02 did not have this issue, at least not as a major issue. Now, the issue was seemingly introduced in draft -03 to address another problem, the deletion of an optional leaf/data-item, for which there are other reasonable solutions that do not lead to the issue in draft -03. Summarized, the solutions to these partial deletes are: 1. Stay with GET and PUT as the means to update (even if sub-optimal from a data size transfer - they work for most APIs) 2. Introduce a subset of regular JSON patching, in the form of a new media-type, that provides specifically the "delete" operation 3. Indicate a "full" yang patch, as was done in draft -02 (or whichever draft that text lives in now). 4. Introduce a new action/operation resource (eg test.com/restconf/jukebox/songs/delete) 5. Define a new meta-data header for the partial delete operation. That said, there is another solution, which however involves Yang: 6. Define in Yang a meta-parameter which designates what containers or lists are to be URIs or have their end-leaf resources "directly" exposed. Surely, some other options can also come into play, but in essence, I think at least the above options need to be looked at. An eventual solution to these problems would be for implementations to "manually" mark up their code, in effect steering or staying away from Restconf, or leaving it confined to some very narrow usage/audience which would be a shame. Regards, Wojciech. > > It seems arbitrary to say that a resource target URI can point > at a container/list but not a leaf/leaf-list. The server is going > to use the YANG validation rules to determine if an operation > is allowed. DELETE will fail for a mandatory container, same > as a leaf. > > [1] mandatory can be complex: > static: mandatory, min-elements > dynamic: if-feature, when + > > > Andy > > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec wrote: >> >> On 10 January 2014 14:39, Wojciech Dec wrote: >> > On 10 January 2014 11:37, Andy Bierman wrote: >> >> >> >> >> >> >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec >> >> wrote: >> >>> >> >>> Hi Martin, >> >>> >> >>> On 8 January 2014 12:29, Martin Bjorklund wrote: >> >>> > Wojciech Dec wrote: >> >>> >> On 6 January 2014 12:49, Andy Bierman wrote: >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >> >>> >> > >> >>> >> > 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 > >>> 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 /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. >> >>> >> >> >> >> >> >> Plain PATCH does not allow an optional leaf to be deleted. >> >> JSON patch does not work well with named data like YANG. >> >> Ignoring YANG naming and using integer indices that renumber >> >> every time a list is changed is a non-starter. The only way to >> >> delete an optional leaf is to GET the entire parent resource, >> >> edit it offline (remove the leaf) and PUT the parent resource. >> >> This is operationally disruptive and expensive to implement >> >> in the server. Optional leafs make up most configuration data, >> >> so a CM solution that doesn't work well for optional leafs is a bad >> >> idea. >> > >> > I should have been clearer: Media Type discussion aside, I meant JSON >> > patch as in "json patch for json reresented yang data", ie likely a >> > subset of pure 'application/json-patch+json', with yang-patch being in >> > some other doc. . The fact that JSON patch does not work for xml is, >> > for me at least, not an issue. A simple answer can thus be that the >> > patch is for json only. >> > In general, I don't quite follow why you say that json patch doesn't >> > allow for leaf deletion; the "remove" op seems to be pretty much >> > intended for that. Gee, the json (yang) patch could even be just >> > limited to just this task. >> > >> > That said, a solution to the " how to delete an optional leaf" problem >> > that ends up treating every data item in the system to a resource, >> > with no way for the designer to override, appears also as a bad idea. >> > Given that we have a full API spec here, even adding a custom >> > parameterized operation to the URI may be a better solution. Also, >> > evidence from the REST API world out there also indicates that for >> > better or worse, GET and PUT do actually work at scale. I would still >> > see this still as easier to deal with and implement than having every >> > single (sub-resource) data item as a resource.... >> > >> > So, in summary, "conservative" options, all leading to getting the >> > spec back from resource extremes as I see can be: >> > 1. Stay with GET and PUT (I suspect that this is what will get most use >> > anyway). >> > 2. Introduce JSON patching, in the form of say >> > "application/yang-json-patch" to the spec (happy to work up some text) >> > 3. Get back the "full" yang patch from draft -02 >> > 4. Introduce a new action/operation invoked via a parameter. >> >> Forgot to add one more: >> 5. Introduce meta-data to handle the partial update. >> >> > >> > Thoughts? >> > >> > Cheers. >> >> >> >> >> >>> >> >>> Cheers, >> >>> Wojciech. >> >> >> >> >> >> >> >> Andy >> >> >> >>> >> >>> > >> >>> > /martin >> >> >> >> > > From mbj@tail-f.com Tue Jan 14 13:33:45 2014 Return-Path: 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 A764E1AE146 for ; Tue, 14 Jan 2014 13:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 GTa6ug4rNLkR for ; Tue, 14 Jan 2014 13:33:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C23241AE242 for ; Tue, 14 Jan 2014 13:33:41 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id EA029240C2D1; Tue, 14 Jan 2014 22:33:29 +0100 (CET) Date: Tue, 14 Jan 2014 22:33:29 +0100 (CET) Message-Id: <20140114.223329.95627287.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: 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 Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 21:33:45 -0000 Wojciech Dec wrote: > On 10 January 2014 19:03, Andy Bierman wrote: > > Hi, > > > > The resource management model is a fairly important part of > > the RESTCONF architecture. Perhaps all attempts so far have > > been too simplistic. > > > > The YANG node type seems to be irrelevant to answering > > the question "what is a sub-resource?" The set of mandatory[1] > > descendant nodes are not sub-resources of a given parent. > > They must exist and cannot be created and deleted > > independently of the parent resource. So a sub-resource > > is really any descendant sub-tree that can be created and > > deleted independent of the parent resource. > > > > IMO there should not be a complex set of rules for restricting URIs > > and HTTP methods, based on mandatory vs. optional nodes. > > This is a conceptual distinction which does not need to be > > enforced somehow in the protocol. > > The problem is that in designing an API, it's generally crucial to > allow the designer to control how the API will be consumed. Agreed. > The -03 > Restconf spec removes most of such controls by not distinguishing > between a resource and its sub-resources: every possible data item is > a URI resource possibly exposed to the HTTP verbs, and likewise every > resource is a data item of its parent resource. Relying on the client > in "knowing" the "right way" in which to consume an API will lead to > poor API experience(s) and breakages like leading to corrupt data, > besides likely gross deviation from REST principles. An Example of the > corruption problem was/is presented below in the original text in the > "update tax-amount along with price" example. As I already wrote, the proper YANG-way to handle this case is to provide constraint in the data model, in the form of must expressions. Just requiring the client to always send both values doesn't guarantee anything. > Relying on the client to > "do the right thing" is problematic, if the history of API usage is > anything to go by. Right, so this is why constraint enforcement in the server is important. > The way I see it: Draft -02 did not have this issue, at least not as a > major issue. Now, the issue was seemingly introduced in draft -03 to > address another problem, the deletion of an optional leaf/data-item, > for which there are other reasonable solutions that do not lead to the > issue in draft -03. Summarized, the solutions to these partial deletes > are: > > 1. Stay with GET and PUT as the means to update (even if sub-optimal > from a data size transfer - they work for most APIs) This means that if you want to delete two optional leafs in two different resources, you have to do two PUTs. This means two different transactions. > 2. Introduce a subset of regular JSON patching, in the form of a new > media-type, that provides specifically the "delete" operation > 3. Indicate a "full" yang patch, as was done in draft -02 (or > whichever draft that text lives in now). Yes this might be an option. > 4. Introduce a new action/operation resource (eg > test.com/restconf/jukebox/songs/delete) This has the same problem as 1. > 5. Define a new meta-data header for the partial delete operation. Is this restful / httpful? > That said, there is another solution, which however involves Yang: 6. > Define in Yang a meta-parameter which designates what containers or > lists are to be URIs or have their end-leaf resources "directly" > exposed. This is something we have discussed from the very start as well. So far we haven't seen any user requirements for it. However, it doesn't solve the delete problem. /martin > Surely, some other options can also come into play, but in essence, I > think at least the above options need to be looked at. > An eventual solution to these problems would be for implementations to > "manually" mark up their code, in effect steering or staying away from > Restconf, or leaving it confined to some very narrow usage/audience > which would be a shame. > > Regards, > Wojciech. > > > > > It seems arbitrary to say that a resource target URI can point > > at a container/list but not a leaf/leaf-list. The server is going > > to use the YANG validation rules to determine if an operation > > is allowed. DELETE will fail for a mandatory container, same > > as a leaf. > > > > [1] mandatory can be complex: > > static: mandatory, min-elements > > dynamic: if-feature, when + > > > > > > Andy > > > > > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec wrote: > >> > >> On 10 January 2014 14:39, Wojciech Dec wrote: > >> > On 10 January 2014 11:37, Andy Bierman wrote: > >> >> > >> >> > >> >> > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec > >> >> wrote: > >> >>> > >> >>> Hi Martin, > >> >>> > >> >>> On 8 January 2014 12:29, Martin Bjorklund wrote: > >> >>> > Wojciech Dec wrote: > >> >>> >> On 6 January 2014 12:49, Andy Bierman wrote: > >> >>> >> > > >> >>> >> > > >> >>> >> > > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > >> >>> >> > > >> >>> >> > 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 >> >>> 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 /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. > >> >>> > >> >> > >> >> > >> >> Plain PATCH does not allow an optional leaf to be deleted. > >> >> JSON patch does not work well with named data like YANG. > >> >> Ignoring YANG naming and using integer indices that renumber > >> >> every time a list is changed is a non-starter. The only way to > >> >> delete an optional leaf is to GET the entire parent resource, > >> >> edit it offline (remove the leaf) and PUT the parent resource. > >> >> This is operationally disruptive and expensive to implement > >> >> in the server. Optional leafs make up most configuration data, > >> >> so a CM solution that doesn't work well for optional leafs is a bad > >> >> idea. > >> > > >> > I should have been clearer: Media Type discussion aside, I meant JSON > >> > patch as in "json patch for json reresented yang data", ie likely a > >> > subset of pure 'application/json-patch+json', with yang-patch being in > >> > some other doc. . The fact that JSON patch does not work for xml is, > >> > for me at least, not an issue. A simple answer can thus be that the > >> > patch is for json only. > >> > In general, I don't quite follow why you say that json patch doesn't > >> > allow for leaf deletion; the "remove" op seems to be pretty much > >> > intended for that. Gee, the json (yang) patch could even be just > >> > limited to just this task. > >> > > >> > That said, a solution to the " how to delete an optional leaf" problem > >> > that ends up treating every data item in the system to a resource, > >> > with no way for the designer to override, appears also as a bad idea. > >> > Given that we have a full API spec here, even adding a custom > >> > parameterized operation to the URI may be a better solution. Also, > >> > evidence from the REST API world out there also indicates that for > >> > better or worse, GET and PUT do actually work at scale. I would still > >> > see this still as easier to deal with and implement than having every > >> > single (sub-resource) data item as a resource.... > >> > > >> > So, in summary, "conservative" options, all leading to getting the > >> > spec back from resource extremes as I see can be: > >> > 1. Stay with GET and PUT (I suspect that this is what will get most use > >> > anyway). > >> > 2. Introduce JSON patching, in the form of say > >> > "application/yang-json-patch" to the spec (happy to work up some text) > >> > 3. Get back the "full" yang patch from draft -02 > >> > 4. Introduce a new action/operation invoked via a parameter. > >> > >> Forgot to add one more: > >> 5. Introduce meta-data to handle the partial update. > >> > >> > > >> > Thoughts? > >> > > >> > Cheers. > >> >> > >> >> > >> >>> > >> >>> Cheers, > >> >>> Wojciech. > >> >> > >> >> > >> >> > >> >> Andy > >> >> > >> >>> > >> >>> > > >> >>> > /martin > >> >> > >> >> > > > > > From andy@yumaworks.com Tue Jan 14 14:19:28 2014 Return-Path: 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 C91BD1AE2C5 for ; Tue, 14 Jan 2014 14:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vXgyAAfbOLo5 for ; Tue, 14 Jan 2014 14:19:24 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9CA1AE2BC for ; Tue, 14 Jan 2014 14:19:24 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id a11so293425qen.24 for ; Tue, 14 Jan 2014 14:19:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xLonfVZq0YP3Hm7X2X5pepJvZv7xPDUtJwIBdTmSrmE=; b=EgiNueJO0A7O8fvOqsGRAW0k1ZZrKLmfx3rPC13rByMTVMXxvvXVBfo4J1yzAHg/w9 wDSN1no1gm2AEUBDjaTksJvZ2OGbUpV1Z9mdFbLEdV07XedMklYvKdvCziiZYciuBv8K nLHuGSLH7hPMLukVdeGm1fKwNlQ5AT8Pd91uzVIQ7Ilf0ne7y9u6Onkvwl3KgjORCSIj PsLgPPYz4HR+a38OVFwtYqN7kmq2qPvGp7RZ/mwoTTy9PWGdPnNyhk5DGCFiq2amVmaM GVSW5fC5fEWMZyC7H/RJemn3c3m0XBtkN/bRPY8/G60fIijM9c49FWLG3PyVfy5E35aC Qz3g== X-Gm-Message-State: ALoCoQlNR1lIHWjgRnEK43O9DHEH3wwMao0s6zhN2VdB/CEUg1XeAPZpg8SSfp+cyDVDd/nMwD51 MIME-Version: 1.0 X-Received: by 10.224.119.200 with SMTP id a8mr7198107qar.7.1389737952641; Tue, 14 Jan 2014 14:19:12 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 14 Jan 2014 14:19:12 -0800 (PST) In-Reply-To: <20140114.223329.95627287.mbj@tail-f.com> References: <20140114.223329.95627287.mbj@tail-f.com> Date: Tue, 14 Jan 2014 14:19:12 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2fae6ff9c4004eff594cd Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2014 22:19:29 -0000 --001a11c2fae6ff9c4004eff594cd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund wrote: > Wojciech Dec wrote: > > On 10 January 2014 19:03, Andy Bierman wrote: > > > Hi, > > > > > > The resource management model is a fairly important part of > > > the RESTCONF architecture. Perhaps all attempts so far have > > > been too simplistic. > > > > > > The YANG node type seems to be irrelevant to answering > > > the question "what is a sub-resource?" The set of mandatory[1] > > > descendant nodes are not sub-resources of a given parent. > > > They must exist and cannot be created and deleted > > > independently of the parent resource. So a sub-resource > > > is really any descendant sub-tree that can be created and > > > deleted independent of the parent resource. > > > > > > IMO there should not be a complex set of rules for restricting URIs > > > and HTTP methods, based on mandatory vs. optional nodes. > > > This is a conceptual distinction which does not need to be > > > enforced somehow in the protocol. > > > > The problem is that in designing an API, it's generally crucial to > > allow the designer to control how the API will be consumed. > > Agreed. > > > The -03 > > Restconf spec removes most of such controls by not distinguishing > > between a resource and its sub-resources: every possible data item is > > a URI resource possibly exposed to the HTTP verbs, and likewise every > > resource is a data item of its parent resource. Relying on the client > > in "knowing" the "right way" in which to consume an API will lead to > > poor API experience(s) and breakages like leading to corrupt data, > > besides likely gross deviation from REST principles. An Example of the > > corruption problem was/is presented below in the original text in the > > "update tax-amount along with price" example. > > As I already wrote, the proper YANG-way to handle this case is to > provide constraint in the data model, in the form of must > expressions. Just requiring the client to always send both values > doesn't guarantee anything. > I think a client could be developed that viewed all YANG terminals as attributes and all lists and containers as resources. I do not see the value in this approach, because in order to edit a resource the app really needs to know the YANG definition of the resource. A generic "create_resource" approach based on containers/leafs, etc. may not work because the must/min-elements/mandatory type of constraints will be enforced by the server, even if they are ignored by the client. > > Relying on the client to > > "do the right thing" is problematic, if the history of API usage is > > anything to go by. > > Right, so this is why constraint enforcement in the server is > important. > > > The way I see it: Draft -02 did not have this issue, at least not as a > > major issue. Now, the issue was seemingly introduced in draft -03 to > > address another problem, the deletion of an optional leaf/data-item, > > for which there are other reasonable solutions that do not lead to the > > issue in draft -03. Summarized, the solutions to these partial deletes > > are: > I still do not understand the issue. Declaring containers and lists to be resources and leaf, leaf-list to be attributes does not account for the YANG constraints. I don't see how preventing the server from accepting a DELETE on a leaf or leaf-list breaks any clients. If your client doesn't want to use DELETE and prefers to use YANG Patch or PUT instead, that still works. > > > 1. Stay with GET and PUT as the means to update (even if sub-optimal > > from a data size transfer - they work for most APIs) > > This means that if you want to delete two optional leafs in two > different resources, you have to do two PUTs. This means two > different transactions. > > > 2. Introduce a subset of regular JSON patching, in the form of a new > > media-type, that provides specifically the "delete" operation > > 3. Indicate a "full" yang patch, as was done in draft -02 (or > > whichever draft that text lives in now). > > Yes this might be an option. > > > 4. Introduce a new action/operation resource (eg > > test.com/restconf/jukebox/songs/delete) > > This has the same problem as 1. > > > 5. Define a new meta-data header for the partial delete operation. > > Is this restful / httpful? > > > That said, there is another solution, which however involves Yang: 6. > > Define in Yang a meta-parameter which designates what containers or > > lists are to be URIs or have their end-leaf resources "directly" > > exposed. > > This is something we have discussed from the very start as well. So > far we haven't seen any user requirements for it. However, it doesn't > solve the delete problem. > > > /martin > Andy > > > > > Surely, some other options can also come into play, but in essence, I > > think at least the above options need to be looked at. > > An eventual solution to these problems would be for implementations to > > "manually" mark up their code, in effect steering or staying away from > > Restconf, or leaving it confined to some very narrow usage/audience > > which would be a shame. > > > > Regards, > > Wojciech. > > > > > > > > It seems arbitrary to say that a resource target URI can point > > > at a container/list but not a leaf/leaf-list. The server is going > > > to use the YANG validation rules to determine if an operation > > > is allowed. DELETE will fail for a mandatory container, same > > > as a leaf. > > > > > > [1] mandatory can be complex: > > > static: mandatory, min-elements > > > dynamic: if-feature, when + > > > > > > > > > Andy > > > > > > > > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec > wrote: > > >> > > >> On 10 January 2014 14:39, Wojciech Dec wrote: > > >> > On 10 January 2014 11:37, Andy Bierman wrote: > > >> >> > > >> >> > > >> >> > > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec > > > >> >> wrote: > > >> >>> > > >> >>> Hi Martin, > > >> >>> > > >> >>> On 8 January 2014 12:29, Martin Bjorklund wrote: > > >> >>> > Wojciech Dec wrote: > > >> >>> >> On 6 January 2014 12:49, Andy Bierman > wrote: > > >> >>> >> > > > >> >>> >> > > > >> >>> >> > > > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > > >> >>> >> > > > >> >>> >> > 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 > >> >>> 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 /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. > > >> >>> > > >> >> > > >> >> > > >> >> Plain PATCH does not allow an optional leaf to be deleted. > > >> >> JSON patch does not work well with named data like YANG. > > >> >> Ignoring YANG naming and using integer indices that renumber > > >> >> every time a list is changed is a non-starter. The only way to > > >> >> delete an optional leaf is to GET the entire parent resource, > > >> >> edit it offline (remove the leaf) and PUT the parent resource. > > >> >> This is operationally disruptive and expensive to implement > > >> >> in the server. Optional leafs make up most configuration data, > > >> >> so a CM solution that doesn't work well for optional leafs is a bad > > >> >> idea. > > >> > > > >> > I should have been clearer: Media Type discussion aside, I meant > JSON > > >> > patch as in "json patch for json reresented yang data", ie likely a > > >> > subset of pure 'application/json-patch+json', with yang-patch being > in > > >> > some other doc. . The fact that JSON patch does not work for xml is, > > >> > for me at least, not an issue. A simple answer can thus be that the > > >> > patch is for json only. > > >> > In general, I don't quite follow why you say that json patch doesn't > > >> > allow for leaf deletion; the "remove" op seems to be pretty much > > >> > intended for that. Gee, the json (yang) patch could even be just > > >> > limited to just this task. > > >> > > > >> > That said, a solution to the " how to delete an optional leaf" > problem > > >> > that ends up treating every data item in the system to a resource, > > >> > with no way for the designer to override, appears also as a bad > idea. > > >> > Given that we have a full API spec here, even adding a custom > > >> > parameterized operation to the URI may be a better solution. Also, > > >> > evidence from the REST API world out there also indicates that for > > >> > better or worse, GET and PUT do actually work at scale. I would > still > > >> > see this still as easier to deal with and implement than having > every > > >> > single (sub-resource) data item as a resource.... > > >> > > > >> > So, in summary, "conservative" options, all leading to getting the > > >> > spec back from resource extremes as I see can be: > > >> > 1. Stay with GET and PUT (I suspect that this is what will get most > use > > >> > anyway). > > >> > 2. Introduce JSON patching, in the form of say > > >> > "application/yang-json-patch" to the spec (happy to work up some > text) > > >> > 3. Get back the "full" yang patch from draft -02 > > >> > 4. Introduce a new action/operation invoked via a parameter. > > >> > > >> Forgot to add one more: > > >> 5. Introduce meta-data to handle the partial update. > > >> > > >> > > > >> > Thoughts? > > >> > > > >> > Cheers. > > >> >> > > >> >> > > >> >>> > > >> >>> Cheers, > > >> >>> Wojciech. > > >> >> > > >> >> > > >> >> > > >> >> Andy > > >> >> > > >> >>> > > >> >>> > > > >> >>> > /martin > > >> >> > > >> >> > > > > > > > > > --001a11c2fae6ff9c4004eff594cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
Wojciech Dec <wdec.ietf@gmail.com> wrote:
> On 10 January 2014 19:03, Andy Bierman <andy@yumaworks.com> wrote:
> > Hi,
> >
> > The resource management model is a fairly important part of
> > the RESTCONF architecture. =A0Perhaps all attempts so far have > > been too simplistic.
> >
> > The YANG node type seems to be irrelevant to answering
> > the question "what is a sub-resource?" =A0The set of ma= ndatory[1]
> > descendant nodes are not sub-resources of a given parent.
> > They must exist and cannot be created and deleted
> > independently of the parent resource. So a sub-resource
> > is really any descendant sub-tree that can be created and
> > deleted independent of the parent resource.
> >
> > IMO there should not be a complex set of rules for restricting UR= Is
> > and HTTP methods, based on mandatory vs. optional nodes.
> > This is a conceptual distinction which does not need to be
> > enforced somehow in the protocol.
>
> The problem is that in designing an API, it's generally crucial to=
> allow the designer to control how the API will be consumed.

Agreed.

> The -03
> Restconf spec removes most of such controls by not distinguishing
> between a resource and its sub-resources: every possible data item is<= br> > a URI resource possibly exposed to the HTTP verbs, and likewise every<= br> > resource is a data item of its parent resource. Relying on the client<= br> > in "knowing" the "right way" in which to consume a= n API will lead to
> poor API experience(s) and breakages like leading to corrupt data,
> besides likely gross deviation from REST principles. An Example of the=
> corruption problem was/is presented below in the original text in the<= br> > "update tax-amount along with price" example.

As I already wrote, the proper YANG-way to handle this case is to
provide constraint in the data model, in the form of must
expressions. =A0Just requiring the client to always send both values
doesn't guarantee anything.


I think a client could be developed that viewed all YANG terminals<= /div>
as attributes and all lists and containers as resources. =A0I do = not
see the value in this approach, because in order to edit a resource
the app really needs to know the YANG definition of the resource.

A generic "create_resource" approach base= d on containers/leafs, etc.
may not work because the must/min-elements/mandatory type of
constraints will be enforced by the server, even if they are ignored
=
by the client.



> Relying on the client to
> "do the right thing" is problematic, if the history of API u= sage is
> anything to go by.

Right, so this is why constraint enforcement in the server is
important.

> The way I see it: Draft -02 did not have this issue, at least not as a=
> major issue. Now, the issue was seemingly introduced in draft -03 to > address another problem, the deletion of an optional leaf/data-item, > for which there are other reasonable solutions that do not lead to the=
> issue in draft -03. Summarized, the solutions to these partial deletes=
> are:


I still do not= understand the issue.
Declaring containers and lists to be resou= rces and leaf, leaf-list
to be attributes does not account for th= e YANG constraints. I don't
see how preventing the server from accepting a DELETE on
a l= eaf or leaf-list breaks any clients. =A0If your client doesn't
want to use DELETE and prefers to use YANG Patch or PUT instead,
that still works.


>
> 1. Stay with GET and PUT as the means to update (even if sub-optimal > from a data size transfer - they work for most APIs)

This means that if you want to delete two optional leafs in two
different resources, you have to do two PUTs. =A0This means two
different transactions.

> 2. Introduce a subset of regular JSON patching, in the form of a new > media-type, that provides specifically the "delete" operatio= n
> 3. Indicate a "full" yang patch, as was done in draft -02 (o= r
> whichever draft that text lives in now).

Yes this might be an option.

> 4. Introduce a new action/operation resource (eg
> test.com/restconf/jukebox/songs/delete)

This has the same problem as 1.

> 5. Define a new meta-data header for the partial delete operation.

Is this restful / httpful?

> That said, there is another solution, which however involves Yang: 6.<= br> > Define in Yang a meta-parameter which designates what containers or > lists are to be URIs or have their end-leaf resources "directly&q= uot;
> exposed.

This is something we have discussed from the very start as well. =A0So
far we haven't seen any user requirements for it. =A0However, it doesn&= #39;t
solve the delete problem.


/martin


Andy
<= br>
=A0



> Surely, some other options can also come into play, but in essence, I<= br> > think at least the above options need to be looked at.
> An eventual solution to these problems would be for implementations to=
> "manually" mark up their code, in effect steering or staying= away from
> Restconf, or leaving it confined to some very narrow usage/audience > which would be a shame.
>
> Regards,
> Wojciech.
>
> >
> > It seems arbitrary to say that a resource target URI can point > > at a container/list but not a leaf/leaf-list. =A0The server is go= ing
> > to use the YANG validation rules to determine if an operation
> > is allowed. =A0DELETE will fail for a mandatory container, same > > as a leaf.
> >
> > [1] mandatory can be complex:
> > =A0 =A0static: mandatory, min-elements
> > =A0 =A0dynamic: if-feature, when + <static>
> >
> >
> > Andy
> >
> >
> > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> >>
> >> On 10 January 2014 14:39, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> >> > On 10 January 2014 11:37, Andy Bierman <andy@yumaworks.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec <wdec.ietf@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> 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 &= lt;andy@yumaworks.com> wrote:<= br> > >> >>> >> >
> >> >>> >> >
> >> >>> >> >
> >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wo= jciech Dec
> >> >>> >> > <wdec.ietf@gmail.com>
> >> >>> >> > wrote:
> >> >>> >> >>
> >> >>> >> >> Hi Andy, all,
> >> >>> >> >>
> >> >>> >> >> are the issues leading to this= draft =A0documented 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 re= sources. Am I correct in
> >> >>> >> >> interpreting
> >> >>> >> >> it
> >> >>> >> >> that now =A0every leaf node = =A0effectively becomes a resource with a
> >> >>> >> >> separate URI? Could the author= s 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 opt= ional leaf).
> >> >>> >>
> >> >>> >>
> >> >>> >> I am still not able to get the full rat= ionale for the change. =A0Can
> >> >>> >> the
> >> >>> >> authors or chairs provide that?
> >> >>> >>
> >> >>> >> Anyway, it now appears that every singl= e data leaf is a resource,
> >> >>> >> instead of an attribute
> >> >>> >
> >> >>> > Yes, every leaf is a subresource to its par= ent list or container.
> >> >>> > This just means that you can GET/POST/DELET= E the leaf directly, w/o
> >> >>> > having to PATCH the parent.
> >> >>> >
> >> >>> >> and the spec doesn't specify a dist= inction
> >> >>> >> between handling parent resources and i= ts sub-resources, e.g. At
> >> >>> >> the
> >> >>> >> very least POST/PUT operations to sub r= esources need to be
> >> >>> >> constrained
> >> >>> >> by their parent resource, and leaving t= hat up to the implementation
> >> >>> >> is
> >> >>> >> kind of a step backwards for the spec a= s 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 par= ent resource, how should
> >> >>> >> multiple sub-resource changes be coordi= nated (the parent resource
> >> >>> >> needs to be consistent)? Etc.
> >> >>> >
> >> >>> > I am afraid I do not understand your concer= n. =A0Could you provide an
> >> >>> > example (data model and requests) that you = feel is problematic or
> >> >>> > unclear?
> >> >>>
> >> >>>
> >> >>> A simple example:
> >> >>>
> >> >>> =A0 =A0 container book {
> >> >>>
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf price {
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type = string;
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf tax-amount = {
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0type = string;
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> >> >>>
> >> >>> =A0 =A0 =A0}
> >> >>>
> >> >>> Price and taxt are typically related.
> >> >>> A (better) REST API design would seek to minimiz= e transactional
> >> >>> effects to the client while protecting the consi= stency/sanity of the
> >> >>> data: To update the resource, a POST operation t= o foo/book would carry
> >> >>> in the envelope both a new price and the tax amo= unt. A (worse) REST
> >> >>> API design would expose both price and tax-amoun= t as separate
> >> >>> resources, accept POST to both foo/book/price an= d foo/book/tax-amount
> >> >>> and hope-for-the-best that the client succeeds a= nd all. Several non
> >> >>> trivial failuire scenarios come up here too.
> >> >>>
> >> >>> The key is that REST API design is very much abo= ut determining what is
> >> >>> a resource, =A0its 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 ultimatel= y complicates and
> >> >>> bloats code (on client, server, and likely both)= , and will lead to
> >> >>> brittle API and poor user experience.
> >> >>>
> >> >>> Another quick example:
> >> >>>
> >> >>>
> >> >>> =A0 =A0 container book {
> >> >>>
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list page {
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 key page= -nr;
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf pag= e-nr {type string;}
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf tex= t {type string;}
> >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> >> >>> =A0 =A0 =A0}
> >> >>>
> >> >>> The RESTConf URI for the above would <root st= uff
> >> >>> here>/book/page/{page-nr}/text
> >> >>>
> >> >>> In general with REST APIs it is important that w= e do NOT expose the
> >> >>> dependent sub-resources directly thus allowing s= omeone to create (POST
> >> >>> or PUT) to <root stuff here>/book/page/{pa= ge-nr} =A0without 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 =A0handler to also d= o book creation,
> >> >>> validation, etc, is not a great design. It compl= icates 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 s= upposed problem. That's why
> >> >>> >> it
> >> >>> >> would be good to understand the rationa= le some more.
> >> >>> >
> >> >>> > If the "yang patch" media type is= opitonal, there is no other way to
> >> >>> > delete optional leafs. =A0If the optional l= eaf 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 =A0or b) = handling (specifying in
> >> >>> the draft how-to do) updates via POST. Thus brin= ging in back the
> >> >>> simple patch would be a good move. And the Yang = patch is something
> >> >>> that can go into another spec, I agree.
> >> >>>
> >> >>
> >> >>
> >> >> Plain PATCH does not allow an optional leaf to be de= leted.
> >> >> JSON patch does not work well with named data like Y= ANG.
> >> >> Ignoring YANG naming and using integer indices that = renumber
> >> >> every time a list is changed is a non-starter. =A0Th= e only way to
> >> >> delete an optional leaf is to GET the entire parent = resource,
> >> >> edit it offline (remove the leaf) and PUT the parent= resource.
> >> >> This is operationally disruptive and expensive to im= plement
> >> >> in the server. =A0Optional leafs make up most config= uration data,
> >> >> so a CM solution that doesn't work well for opti= onal leafs is a bad
> >> >> idea.
> >> >
> >> > I should have been clearer: Media Type discussion aside,= I meant JSON
> >> > patch as in "json patch for json reresented yang da= ta", ie likely a
> >> > subset of pure 'application/json-patch+json', wi= th yang-patch being in
> >> > some other doc. . The fact that JSON patch does not work= for xml is,
> >> > for me at least, not an issue. A simple answer can thus = be that the
> >> > patch is for json only.
> >> > In general, I don't quite follow why you say that js= on patch doesn't
> >> > allow for leaf deletion; the "remove" op seems= to be pretty much
> >> > intended for that. Gee, the json (yang) patch could even= be just
> >> > limited to just this task.
> >> >
> >> > That said, a solution to the " how to delete an opt= ional leaf" problem
> >> > that ends up treating every data item in the system to a= resource,
> >> > with no way for the designer to override, appears also a= s a bad idea.
> >> > Given that we have a full API spec here, even adding a c= ustom
> >> > parameterized operation to the URI may be a better solut= ion. Also,
> >> > evidence from the REST API world out there also indicate= s that for
> >> > better or worse, GET and PUT do actually work at scale. = I would still
> >> > see this still as easier to deal with and implement than= having every
> >> > single (sub-resource) data item as a resource....
> >> >
> >> > So, in summary, "conservative" options, all le= ading to getting the
> >> > spec back from resource extremes as I see can be:
> >> > 1. Stay with GET and PUT (I suspect that this is what wi= ll get most use
> >> > anyway).
> >> > 2. Introduce JSON patching, in the form of say
> >> > "application/yang-json-patch" to the spec (hap= py to work up some text)
> >> > 3. Get back the "full" yang patch from draft -= 02
> >> > 4. Introduce a new action/operation invoked via a parame= ter.
> >>
> >> Forgot to add one more:
> >> 5. Introduce meta-data to handle the partial update.
> >>
> >> >
> >> > Thoughts?
> >> >
> >> > Cheers.
> >> >>
> >> >>
> >> >>>
> >> >>> Cheers,
> >> >>> Wojciech.
> >> >>
> >> >>
> >> >>
> >> >> Andy
> >> >>
> >> >>>
> >> >>> >
> >> >>> > /martin
> >> >>
> >> >>
> >
> >
>

--001a11c2fae6ff9c4004eff594cd-- From wdec.ietf@gmail.com Wed Jan 15 01:35:14 2014 Return-Path: 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 7FD951AE062 for ; Wed, 15 Jan 2014 01:35:14 -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 jfVr_rJel1fw for ; Wed, 15 Jan 2014 01:35:11 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id DECEE1AE02E for ; Wed, 15 Jan 2014 01:35:10 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so895678pde.0 for ; Wed, 15 Jan 2014 01:34: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=5yMjwMDepc2rBKQEue1QJh4zH2pFVAeBjxO6fO4AHNc=; b=o7jOGaunVEVHt2wEAe2brQgFsatvjkXLRk2aISFOEGHf14efp0u5To1uNXd7RhQCjq KJ5lHGDFvDZUD9cJveR66rJD82iiLHMcplAY+xQkRNDfoJY3XbvG+OrHXchKBHUGg6Zk 9SdCNtoFhZ6DNSjCZBSNkqzPYiCrYuylWrv/HTiEqte9dWP3hodQ/WpjS2ndiJrfC1nL NXbmVR9CX192ECqNpwhmBTM/wnh9H+VI1JiqqjpI9mquBYbZbW/RW2waCkN1fBpjmIOx 7psnWB4B1iHaTV+xLSFyOBpOC7GCNZqwPgC/HBDeQ2IRMClYVQKSE1cFqtxokzP0TmfJ DGSQ== MIME-Version: 1.0 X-Received: by 10.67.5.233 with SMTP id cp9mr1304458pad.147.1389778499339; Wed, 15 Jan 2014 01:34:59 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 15 Jan 2014 01:34:59 -0800 (PST) In-Reply-To: References: <20140114.223329.95627287.mbj@tail-f.com> Date: Wed, 15 Jan 2014 10:34:59 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 09:35:14 -0000 On 14 January 2014 23:19, Andy Bierman wrote: > > > > On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund wrote: >> >> Wojciech Dec wrote: >> > On 10 January 2014 19:03, Andy Bierman wrote: >> > > Hi, >> > > >> > > The resource management model is a fairly important part of >> > > the RESTCONF architecture. Perhaps all attempts so far have >> > > been too simplistic. >> > > >> > > The YANG node type seems to be irrelevant to answering >> > > the question "what is a sub-resource?" The set of mandatory[1] >> > > descendant nodes are not sub-resources of a given parent. >> > > They must exist and cannot be created and deleted >> > > independently of the parent resource. So a sub-resource >> > > is really any descendant sub-tree that can be created and >> > > deleted independent of the parent resource. >> > > >> > > IMO there should not be a complex set of rules for restricting URIs >> > > and HTTP methods, based on mandatory vs. optional nodes. >> > > This is a conceptual distinction which does not need to be >> > > enforced somehow in the protocol. >> > >> > The problem is that in designing an API, it's generally crucial to >> > allow the designer to control how the API will be consumed. >> >> Agreed. >> >> > The -03 >> > Restconf spec removes most of such controls by not distinguishing >> > between a resource and its sub-resources: every possible data item is >> > a URI resource possibly exposed to the HTTP verbs, and likewise every >> > resource is a data item of its parent resource. Relying on the client >> > in "knowing" the "right way" in which to consume an API will lead to >> > poor API experience(s) and breakages like leading to corrupt data, >> > besides likely gross deviation from REST principles. An Example of the >> > corruption problem was/is presented below in the original text in the >> > "update tax-amount along with price" example. >> >> As I already wrote, the proper YANG-way to handle this case is to >> provide constraint in the data model, in the form of must >> expressions. Just requiring the client to always send both values >> doesn't guarantee anything. > > > > I think a client could be developed that viewed all YANG terminals > as attributes and all lists and containers as resources. I do not > see the value in this approach, because in order to edit a resource > the app really needs to know the YANG definition of the resource. Yes, given our previous discussion on URI's, etc, I see that in the generic case apps would require to also know the YANG definition too, but whether the app chooses to update a composite resource going sub-resource by sub-resource or addressing the resource is something that the YANG model doesn't say. As mentioned, typically the API designer has the levers to guide this sort of behavior. > > A generic "create_resource" approach based on containers/leafs, etc. > may not work because the must/min-elements/mandatory type of > constraints will be enforced by the server, even if they are ignored > by the client. > > >> >> > Relying on the client to >> > "do the right thing" is problematic, if the history of API usage is >> > anything to go by. >> >> Right, so this is why constraint enforcement in the server is >> important. >> >> > The way I see it: Draft -02 did not have this issue, at least not as a >> > major issue. Now, the issue was seemingly introduced in draft -03 to >> > address another problem, the deletion of an optional leaf/data-item, >> > for which there are other reasonable solutions that do not lead to the >> > issue in draft -03. Summarized, the solutions to these partial deletes >> > are: > > > > I still do not understand the issue. > Declaring containers and lists to be resources and leaf, leaf-list > to be attributes does not account for the YANG constraints. I don't > see how preventing the server from accepting a DELETE on > a leaf or leaf-list breaks any clients. If your client doesn't > want to use DELETE and prefers to use YANG Patch or PUT instead, > that still works. Well, that's because it is not the client that breaks, but rather, actions by the client can (and actually case will, coz we've seen this in other REST APIs) corrupt the state of the data-store/lead to inconsistent data on the server. Since the sub resources are directly accessible, they could get updated directly and asynchronously irrespective of any related sub-resources. Should a client fail after doing the "PUT/update price" but before "PUT/update tax-amount", the store will be in trouble. A side problem in this is also what should clients accessing the parent resource see while these "sub transactions" are happening. With REST, this problem is much easier to deal with when the PUT/update operation is done at the parent level. This type of problem is sometimes "solved" in some (supposedly) RESTful services by locking the resource (ie trying to do a synchronous change), locking related resources, etc. Regards, Wojciech. > > >> > >> > 1. Stay with GET and PUT as the means to update (even if sub-optimal >> > from a data size transfer - they work for most APIs) >> >> This means that if you want to delete two optional leafs in two >> different resources, you have to do two PUTs. This means two >> different transactions. >> >> > 2. Introduce a subset of regular JSON patching, in the form of a new >> > media-type, that provides specifically the "delete" operation >> > 3. Indicate a "full" yang patch, as was done in draft -02 (or >> > whichever draft that text lives in now). >> >> Yes this might be an option. >> >> > 4. Introduce a new action/operation resource (eg >> > test.com/restconf/jukebox/songs/delete) >> >> This has the same problem as 1. >> >> > 5. Define a new meta-data header for the partial delete operation. >> >> Is this restful / httpful? >> >> > That said, there is another solution, which however involves Yang: 6. >> > Define in Yang a meta-parameter which designates what containers or >> > lists are to be URIs or have their end-leaf resources "directly" >> > exposed. >> >> This is something we have discussed from the very start as well. So >> far we haven't seen any user requirements for it. However, it doesn't >> solve the delete problem. >> >> >> /martin > > > > Andy > > >> >> >> >> >> > Surely, some other options can also come into play, but in essence, I >> > think at least the above options need to be looked at. >> > An eventual solution to these problems would be for implementations to >> > "manually" mark up their code, in effect steering or staying away from >> > Restconf, or leaving it confined to some very narrow usage/audience >> > which would be a shame. >> > >> > Regards, >> > Wojciech. >> > >> > > >> > > It seems arbitrary to say that a resource target URI can point >> > > at a container/list but not a leaf/leaf-list. The server is going >> > > to use the YANG validation rules to determine if an operation >> > > is allowed. DELETE will fail for a mandatory container, same >> > > as a leaf. >> > > >> > > [1] mandatory can be complex: >> > > static: mandatory, min-elements >> > > dynamic: if-feature, when + >> > > >> > > >> > > Andy >> > > >> > > >> > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec >> > > wrote: >> > >> >> > >> On 10 January 2014 14:39, Wojciech Dec wrote: >> > >> > On 10 January 2014 11:37, Andy Bierman wrote: >> > >> >> >> > >> >> >> > >> >> >> > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec >> > >> >> >> > >> >> wrote: >> > >> >>> >> > >> >>> Hi Martin, >> > >> >>> >> > >> >>> On 8 January 2014 12:29, Martin Bjorklund wrote: >> > >> >>> > Wojciech Dec wrote: >> > >> >>> >> On 6 January 2014 12:49, Andy Bierman >> > >> >>> >> wrote: >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > >> > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >> > >> >>> >> > >> > >> >>> >> > 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 > > >> >>> 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 /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. >> > >> >>> >> > >> >> >> > >> >> >> > >> >> Plain PATCH does not allow an optional leaf to be deleted. >> > >> >> JSON patch does not work well with named data like YANG. >> > >> >> Ignoring YANG naming and using integer indices that renumber >> > >> >> every time a list is changed is a non-starter. The only way to >> > >> >> delete an optional leaf is to GET the entire parent resource, >> > >> >> edit it offline (remove the leaf) and PUT the parent resource. >> > >> >> This is operationally disruptive and expensive to implement >> > >> >> in the server. Optional leafs make up most configuration data, >> > >> >> so a CM solution that doesn't work well for optional leafs is a >> > >> >> bad >> > >> >> idea. >> > >> > >> > >> > I should have been clearer: Media Type discussion aside, I meant >> > >> > JSON >> > >> > patch as in "json patch for json reresented yang data", ie likely a >> > >> > subset of pure 'application/json-patch+json', with yang-patch being >> > >> > in >> > >> > some other doc. . The fact that JSON patch does not work for xml >> > >> > is, >> > >> > for me at least, not an issue. A simple answer can thus be that the >> > >> > patch is for json only. >> > >> > In general, I don't quite follow why you say that json patch >> > >> > doesn't >> > >> > allow for leaf deletion; the "remove" op seems to be pretty much >> > >> > intended for that. Gee, the json (yang) patch could even be just >> > >> > limited to just this task. >> > >> > >> > >> > That said, a solution to the " how to delete an optional leaf" >> > >> > problem >> > >> > that ends up treating every data item in the system to a resource, >> > >> > with no way for the designer to override, appears also as a bad >> > >> > idea. >> > >> > Given that we have a full API spec here, even adding a custom >> > >> > parameterized operation to the URI may be a better solution. Also, >> > >> > evidence from the REST API world out there also indicates that for >> > >> > better or worse, GET and PUT do actually work at scale. I would >> > >> > still >> > >> > see this still as easier to deal with and implement than having >> > >> > every >> > >> > single (sub-resource) data item as a resource.... >> > >> > >> > >> > So, in summary, "conservative" options, all leading to getting the >> > >> > spec back from resource extremes as I see can be: >> > >> > 1. Stay with GET and PUT (I suspect that this is what will get most >> > >> > use >> > >> > anyway). >> > >> > 2. Introduce JSON patching, in the form of say >> > >> > "application/yang-json-patch" to the spec (happy to work up some >> > >> > text) >> > >> > 3. Get back the "full" yang patch from draft -02 >> > >> > 4. Introduce a new action/operation invoked via a parameter. >> > >> >> > >> Forgot to add one more: >> > >> 5. Introduce meta-data to handle the partial update. >> > >> >> > >> > >> > >> > Thoughts? >> > >> > >> > >> > Cheers. >> > >> >> >> > >> >> >> > >> >>> >> > >> >>> Cheers, >> > >> >>> Wojciech. >> > >> >> >> > >> >> >> > >> >> >> > >> >> Andy >> > >> >> >> > >> >>> >> > >> >>> > >> > >> >>> > /martin >> > >> >> >> > >> >> >> > > >> > > >> > > > From andy@yumaworks.com Wed Jan 15 02:21:11 2014 Return-Path: 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 974041AE07A for ; Wed, 15 Jan 2014 02:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 pN5PlPniGShw for ; Wed, 15 Jan 2014 02:21:06 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id BED481AE013 for ; Wed, 15 Jan 2014 02:21:05 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i8so753216qcq.4 for ; Wed, 15 Jan 2014 02:20:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gMWBKAzAxNLvRMMe9Zsz/lVWL6Ak2hUnobOQXm8bxME=; b=a1rWorB6hrSu6/Mg4uTr1VpgHZyFen8Twk4tKnOe8XOoIFr6Yfp7z0FE7vZQ6V6uUj MqwLw/Z5aKhZg+fJgbBhJ31UMDht0m1zmbX+6mvg+FqPnGfB0ummz1YB5XTi0R0Y+slN 1g33Hrzs3Zmt+xCWGkgErMtrNZSitQiMzvoyBAh2TcAR9AX7xW0NKXn0nznrCdhkKh5A 77z3kHnfI2E5KOUXnLTMZ7POiLnXyCX1dp4jZBZQ/XfJEcONBP0DttFm1IXmzyjuZopX bMb+U8u9ZU8RQQcA3r0xlUv2ysmkPvHA+9JNo2nJiEmN9uEY2+XZCbRTmtvDB0qA+Jlq xAdA== X-Gm-Message-State: ALoCoQmMW5iEo7qIGG7YoryVdfww+qAP2XgGjWjnZbC4Ytx6EtF98Lpa4XBpofzTivyIwP6DqBbS MIME-Version: 1.0 X-Received: by 10.49.131.164 with SMTP id on4mr3066397qeb.16.1389781253979; Wed, 15 Jan 2014 02:20:53 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 15 Jan 2014 02:20:53 -0800 (PST) In-Reply-To: References: <20140114.223329.95627287.mbj@tail-f.com> Date: Wed, 15 Jan 2014 02:20:53 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bd75132f5902a04efffa951 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 10:21:11 -0000 --047d7bd75132f5902a04efffa951 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 15, 2014 at 1:34 AM, Wojciech Dec wrote: > On 14 January 2014 23:19, Andy Bierman wrote: > > > > > > > > On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund > wrote: > >> > >> Wojciech Dec wrote: > >> > On 10 January 2014 19:03, Andy Bierman wrote: > >> > > Hi, > >> > > > >> > > The resource management model is a fairly important part of > >> > > the RESTCONF architecture. Perhaps all attempts so far have > >> > > been too simplistic. > >> > > > >> > > The YANG node type seems to be irrelevant to answering > >> > > the question "what is a sub-resource?" The set of mandatory[1] > >> > > descendant nodes are not sub-resources of a given parent. > >> > > They must exist and cannot be created and deleted > >> > > independently of the parent resource. So a sub-resource > >> > > is really any descendant sub-tree that can be created and > >> > > deleted independent of the parent resource. > >> > > > >> > > IMO there should not be a complex set of rules for restricting URIs > >> > > and HTTP methods, based on mandatory vs. optional nodes. > >> > > This is a conceptual distinction which does not need to be > >> > > enforced somehow in the protocol. > >> > > >> > The problem is that in designing an API, it's generally crucial to > >> > allow the designer to control how the API will be consumed. > >> > >> Agreed. > >> > >> > The -03 > >> > Restconf spec removes most of such controls by not distinguishing > >> > between a resource and its sub-resources: every possible data item is > >> > a URI resource possibly exposed to the HTTP verbs, and likewise every > >> > resource is a data item of its parent resource. Relying on the client > >> > in "knowing" the "right way" in which to consume an API will lead to > >> > poor API experience(s) and breakages like leading to corrupt data, > >> > besides likely gross deviation from REST principles. An Example of the > >> > corruption problem was/is presented below in the original text in the > >> > "update tax-amount along with price" example. > >> > >> As I already wrote, the proper YANG-way to handle this case is to > >> provide constraint in the data model, in the form of must > >> expressions. Just requiring the client to always send both values > >> doesn't guarantee anything. > > > > > > > > I think a client could be developed that viewed all YANG terminals > > as attributes and all lists and containers as resources. I do not > > see the value in this approach, because in order to edit a resource > > the app really needs to know the YANG definition of the resource. > > Yes, given our previous discussion on URI's, etc, I see that in the > generic case apps would require to also know the YANG definition too, > but whether the app chooses to update a composite resource going > sub-resource by sub-resource or addressing the resource is something > that the YANG model doesn't say. As mentioned, typically the API > designer has the levers to guide this sort of behavior. > > container my-resource { leaf a { type string; } list b { min-elements 1; key x; leaf x { type string; } } } Here is an example that breaks the simple "lists are sub-resources" design. The client code cannot assume that it always has to provide child leafs and never has to provide child lists. The server will reject requests to create my-resource unless it has at least 1 instance of list b. The client cannot ignore the YANG constraints. > > > A generic "create_resource" approach based on containers/leafs, etc. > > may not work because the must/min-elements/mandatory type of > > constraints will be enforced by the server, even if they are ignored > > by the client. > > > > > >> > >> > Relying on the client to > >> > "do the right thing" is problematic, if the history of API usage is > >> > anything to go by. > >> > >> Right, so this is why constraint enforcement in the server is > >> important. > >> > >> > The way I see it: Draft -02 did not have this issue, at least not as a > >> > major issue. Now, the issue was seemingly introduced in draft -03 to > >> > address another problem, the deletion of an optional leaf/data-item, > >> > for which there are other reasonable solutions that do not lead to the > >> > issue in draft -03. Summarized, the solutions to these partial deletes > >> > are: > > > > > > > > I still do not understand the issue. > > Declaring containers and lists to be resources and leaf, leaf-list > > to be attributes does not account for the YANG constraints. I don't > > see how preventing the server from accepting a DELETE on > > a leaf or leaf-list breaks any clients. If your client doesn't > > want to use DELETE and prefers to use YANG Patch or PUT instead, > > that still works. > > Well, that's because it is not the client that breaks, but rather, > actions by the client can (and actually case will, coz we've seen this > in other REST APIs) corrupt the state of the data-store/lead to > inconsistent data on the server. Since the sub resources are directly > accessible, they could get updated directly and asynchronously > irrespective of any related sub-resources. Should a client fail after > doing the "PUT/update price" but before "PUT/update tax-amount", the > store will be in trouble. > YANG defines what needs to be present for the resource to be valid. Nothing short of understanding the YANG constraints is going to prevent an app from sending invalid requests. > A side problem in this is also what should clients accessing the > parent resource see while these "sub transactions" are happening. > With REST, this problem is much easier to deal with when the > PUT/update operation is done at the parent level. > > This type of problem is sometimes "solved" in some (supposedly) > RESTful services by locking the resource (ie trying to do a > synchronous change), locking related resources, etc. > > Regards, > Wojciech. > Andy > > > > > >> > > >> > 1. Stay with GET and PUT as the means to update (even if sub-optimal > >> > from a data size transfer - they work for most APIs) > >> > >> This means that if you want to delete two optional leafs in two > >> different resources, you have to do two PUTs. This means two > >> different transactions. > >> > >> > 2. Introduce a subset of regular JSON patching, in the form of a new > >> > media-type, that provides specifically the "delete" operation > >> > 3. Indicate a "full" yang patch, as was done in draft -02 (or > >> > whichever draft that text lives in now). > >> > >> Yes this might be an option. > >> > >> > 4. Introduce a new action/operation resource (eg > >> > test.com/restconf/jukebox/songs/delete) > >> > >> This has the same problem as 1. > >> > >> > 5. Define a new meta-data header for the partial delete operation. > >> > >> Is this restful / httpful? > >> > >> > That said, there is another solution, which however involves Yang: 6. > >> > Define in Yang a meta-parameter which designates what containers or > >> > lists are to be URIs or have their end-leaf resources "directly" > >> > exposed. > >> > >> This is something we have discussed from the very start as well. So > >> far we haven't seen any user requirements for it. However, it doesn't > >> solve the delete problem. > >> > >> > >> /martin > > > > > > > > Andy > > > > > >> > >> > >> > >> > >> > Surely, some other options can also come into play, but in essence, I > >> > think at least the above options need to be looked at. > >> > An eventual solution to these problems would be for implementations to > >> > "manually" mark up their code, in effect steering or staying away from > >> > Restconf, or leaving it confined to some very narrow usage/audience > >> > which would be a shame. > >> > > >> > Regards, > >> > Wojciech. > >> > > >> > > > >> > > It seems arbitrary to say that a resource target URI can point > >> > > at a container/list but not a leaf/leaf-list. The server is going > >> > > to use the YANG validation rules to determine if an operation > >> > > is allowed. DELETE will fail for a mandatory container, same > >> > > as a leaf. > >> > > > >> > > [1] mandatory can be complex: > >> > > static: mandatory, min-elements > >> > > dynamic: if-feature, when + > >> > > > >> > > > >> > > Andy > >> > > > >> > > > >> > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec > >> > > wrote: > >> > >> > >> > >> On 10 January 2014 14:39, Wojciech Dec > wrote: > >> > >> > On 10 January 2014 11:37, Andy Bierman > wrote: > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec > >> > >> >> > >> > >> >> wrote: > >> > >> >>> > >> > >> >>> Hi Martin, > >> > >> >>> > >> > >> >>> On 8 January 2014 12:29, Martin Bjorklund > wrote: > >> > >> >>> > Wojciech Dec wrote: > >> > >> >>> >> On 6 January 2014 12:49, Andy Bierman > >> > >> >>> >> wrote: > >> > >> >>> >> > > >> > >> >>> >> > > >> > >> >>> >> > > >> > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec > >> > >> >>> >> > > >> > >> >>> >> > 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 >> > >> >>> 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 /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. > >> > >> >>> > >> > >> >> > >> > >> >> > >> > >> >> Plain PATCH does not allow an optional leaf to be deleted. > >> > >> >> JSON patch does not work well with named data like YANG. > >> > >> >> Ignoring YANG naming and using integer indices that renumber > >> > >> >> every time a list is changed is a non-starter. The only way to > >> > >> >> delete an optional leaf is to GET the entire parent resource, > >> > >> >> edit it offline (remove the leaf) and PUT the parent resource. > >> > >> >> This is operationally disruptive and expensive to implement > >> > >> >> in the server. Optional leafs make up most configuration data, > >> > >> >> so a CM solution that doesn't work well for optional leafs is a > >> > >> >> bad > >> > >> >> idea. > >> > >> > > >> > >> > I should have been clearer: Media Type discussion aside, I meant > >> > >> > JSON > >> > >> > patch as in "json patch for json reresented yang data", ie > likely a > >> > >> > subset of pure 'application/json-patch+json', with yang-patch > being > >> > >> > in > >> > >> > some other doc. . The fact that JSON patch does not work for xml > >> > >> > is, > >> > >> > for me at least, not an issue. A simple answer can thus be that > the > >> > >> > patch is for json only. > >> > >> > In general, I don't quite follow why you say that json patch > >> > >> > doesn't > >> > >> > allow for leaf deletion; the "remove" op seems to be pretty much > >> > >> > intended for that. Gee, the json (yang) patch could even be just > >> > >> > limited to just this task. > >> > >> > > >> > >> > That said, a solution to the " how to delete an optional leaf" > >> > >> > problem > >> > >> > that ends up treating every data item in the system to a > resource, > >> > >> > with no way for the designer to override, appears also as a bad > >> > >> > idea. > >> > >> > Given that we have a full API spec here, even adding a custom > >> > >> > parameterized operation to the URI may be a better solution. > Also, > >> > >> > evidence from the REST API world out there also indicates that > for > >> > >> > better or worse, GET and PUT do actually work at scale. I would > >> > >> > still > >> > >> > see this still as easier to deal with and implement than having > >> > >> > every > >> > >> > single (sub-resource) data item as a resource.... > >> > >> > > >> > >> > So, in summary, "conservative" options, all leading to getting > the > >> > >> > spec back from resource extremes as I see can be: > >> > >> > 1. Stay with GET and PUT (I suspect that this is what will get > most > >> > >> > use > >> > >> > anyway). > >> > >> > 2. Introduce JSON patching, in the form of say > >> > >> > "application/yang-json-patch" to the spec (happy to work up some > >> > >> > text) > >> > >> > 3. Get back the "full" yang patch from draft -02 > >> > >> > 4. Introduce a new action/operation invoked via a parameter. > >> > >> > >> > >> Forgot to add one more: > >> > >> 5. Introduce meta-data to handle the partial update. > >> > >> > >> > >> > > >> > >> > Thoughts? > >> > >> > > >> > >> > Cheers. > >> > >> >> > >> > >> >> > >> > >> >>> > >> > >> >>> Cheers, > >> > >> >>> Wojciech. > >> > >> >> > >> > >> >> > >> > >> >> > >> > >> >> Andy > >> > >> >> > >> > >> >>> > >> > >> >>> > > >> > >> >>> > /martin > >> > >> >> > >> > >> >> > >> > > > >> > > > >> > > > > > > --047d7bd75132f5902a04efffa951 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 15, 2014 at 1:34 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 14 January 2014 23:19, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>> Wojciech Dec <wdec.ietf@= gmail.com> wrote:
>> > On 10 January 2014 19:03, Andy Bierman <andy@yumaworks.com> wrote:
>> > > Hi,
>> > >
>> > > The resource management model is a fairly important part= of
>> > > the RESTCONF architecture. =A0Perhaps all attempts so fa= r have
>> > > been too simplistic.
>> > >
>> > > The YANG node type seems to be irrelevant to answering >> > > the question "what is a sub-resource?" =A0The = set of mandatory[1]
>> > > descendant nodes are not sub-resources of a given parent= .
>> > > They must exist and cannot be created and deleted
>> > > independently of the parent resource. So a sub-resource<= br> >> > > is really any descendant sub-tree that can be created an= d
>> > > deleted independent of the parent resource.
>> > >
>> > > IMO there should not be a complex set of rules for restr= icting URIs
>> > > and HTTP methods, based on mandatory vs. optional nodes.=
>> > > This is a conceptual distinction which does not need to = be
>> > > enforced somehow in the protocol.
>> >
>> > The problem is that in designing an API, it's generally c= rucial to
>> > allow the designer to control how the API will be consumed. >>
>> Agreed.
>>
>> > The -03
>> > Restconf spec removes most of such controls by not distinguis= hing
>> > between a resource and its sub-resources: every possible data= item is
>> > a URI resource possibly exposed to the HTTP verbs, and likewi= se every
>> > resource is a data item of its parent resource. Relying on th= e client
>> > in "knowing" the "right way" in which to = consume an API will lead to
>> > poor API experience(s) and breakages like leading to corrupt = data,
>> > besides likely gross deviation from REST principles. An Examp= le of the
>> > corruption problem was/is presented below in the original tex= t in the
>> > "update tax-amount along with price" example.
>>
>> As I already wrote, the proper YANG-way to handle this case is to<= br> >> provide constraint in the data model, in the form of must
>> expressions. =A0Just requiring the client to always send both valu= es
>> doesn't guarantee anything.
>
>
>
> I think a client could be developed that viewed all YANG terminals
> as attributes and all lists and containers as resources. =A0I do not > see the value in this approach, because in order to edit a resource > the app really needs to know the YANG definition of the resource.

Yes, given our previous discussion on URI's, etc, I see that in the
generic case apps would require to also know the YANG definition too,
but whether the app chooses to update a composite resource going
sub-resource by sub-resource or addressing the resource is something
that the YANG model doesn't say. As mentioned, typically the API
designer has the levers to guide this sort of behavior.



=A0 =A0container my-res= ource {
=A0 =A0 =A0 =A0leaf a { type string; }
=A0 =A0 = =A0 =A0list b {
=A0 =A0 =A0 =A0 =A0 min-elements 1;
=A0= =A0 =A0 =A0 =A0 key x;
=A0 =A0 =A0 =A0 =A0 leaf x { type string;= }
=A0 =A0 =A0 =A0}
=A0 =A0}

Here is a= n example that breaks the simple "lists are sub-resources" design= .
The client code cannot assume that it always has to provide chi= ld leafs and never
has to provide child lists. The server will reject requests to create = my-resource
unless it has at least 1 instance of list b. =A0T= he client cannot ignore the YANG constraints.



>
> A generic "create_resource" approach based on containers/lea= fs, etc.
> may not work because the must/min-elements/mandatory type of
> constraints will be enforced by the server, even if they are ignored > by the client.
>
>
>>
>> > Relying on the client to
>> > "do the right thing" is problematic, if the history= of API usage is
>> > anything to go by.
>>
>> Right, so this is why constraint enforcement in the server is
>> important.
>>
>> > The way I see it: Draft -02 did not have this issue, at least= not as a
>> > major issue. Now, the issue was seemingly introduced in draft= -03 to
>> > address another problem, the deletion of an optional leaf/dat= a-item,
>> > for which there are other reasonable solutions that do not le= ad to the
>> > issue in draft -03. Summarized, the solutions to these partia= l deletes
>> > are:
>
>
>
> I still do not understand the issue.
> Declaring containers and lists to be resources and leaf, leaf-list
> to be attributes does not account for the YANG constraints. I don'= t
> see how preventing the server from accepting a DELETE on
> a leaf or leaf-list breaks any clients. =A0If your client doesn't<= br> > want to use DELETE and prefers to use YANG Patch or PUT instead,
> that still works.

Well, that's because it is not the client that breaks, but rather,
actions by the client can (and actually case will, coz we've seen this<= br> in other REST APIs) corrupt the state of the data-store/lead to
inconsistent data on the server. Since the sub resources are directly
accessible, they could get updated directly and asynchronously
irrespective of any related sub-resources. Should a client fail after
doing the "PUT/update price" but before "PUT/update tax-amou= nt", the
store will be in trouble.

YANG defines = what needs to be present for the resource to be valid.
Nothing sh= ort of understanding the YANG constraints is going to
prevent an = app from sending invalid requests.

=A0
A side problem in this is also what should clients accessing the
parent resource see while these "sub transactions" are happening.=
With REST, this problem is much easier to deal with when the
PUT/update operation is done at the parent level.

This type of problem is sometimes "solved" in some (supposedly) RESTful services by locking the resource (ie trying to do a
synchronous change), locking related resources, etc.

Regards,
Wojciech.


Andy
=A0
>
>
>> >
>> > 1. Stay with GET and PUT as the means to update (even if sub-= optimal
>> > from a data size transfer - they work for most APIs)
>>
>> This means that if you want to delete two optional leafs in two >> different resources, you have to do two PUTs. =A0This means two >> different transactions.
>>
>> > 2. Introduce a subset of regular JSON patching, in the form o= f a new
>> > media-type, that provides specifically the "delete"= operation
>> > 3. Indicate a "full" yang patch, as was done in dra= ft -02 (or
>> > whichever draft that text lives in now).
>>
>> Yes this might be an option.
>>
>> > 4. Introduce a new action/operation resource (eg
>> > test.com/restconf/jukebox/songs/delete)
>>
>> This has the same problem as 1.
>>
>> > 5. Define a new meta-data header for the partial delete opera= tion.
>>
>> Is this restful / httpful?
>>
>> > That said, there is another solution, which however involves = Yang: 6.
>> > Define in Yang a meta-parameter which designates what contain= ers or
>> > lists are to be URIs or have their end-leaf resources "d= irectly"
>> > exposed.
>>
>> This is something we have discussed from the very start as well. = =A0So
>> far we haven't seen any user requirements for it. =A0However, = it doesn't
>> solve the delete problem.
>>
>>
>> /martin
>
>
>
> Andy
>
>
>>
>>
>>
>>
>> > Surely, some other options can also come into play, but in es= sence, I
>> > think at least the above options need to be looked at.
>> > An eventual solution to these problems would be for implement= ations to
>> > "manually" mark up their code, in effect steering o= r staying away from
>> > Restconf, or leaving it confined to some very narrow usage/au= dience
>> > which would be a shame.
>> >
>> > Regards,
>> > Wojciech.
>> >
>> > >
>> > > It seems arbitrary to say that a resource target URI can= point
>> > > at a container/list but not a leaf/leaf-list. =A0The ser= ver is going
>> > > to use the YANG validation rules to determine if an oper= ation
>> > > is allowed. =A0DELETE will fail for a mandatory containe= r, same
>> > > as a leaf.
>> > >
>> > > [1] mandatory can be complex:
>> > > =A0 =A0static: mandatory, min-elements
>> > > =A0 =A0dynamic: if-feature, when + <static>
>> > >
>> > >
>> > > Andy
>> > >
>> > >
>> > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec <wdec.ietf@gmail.com>
>> > > wrote:
>> > >>
>> > >> On 10 January 2014 14:39, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> > >> > On 10 January 2014 11:37, Andy Bierman <andy@yumaworks.com> wrote:
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech D= ec
>> > >> >> <= wdec.ietf@gmail.com>
>> > >> >> wrote:
>> > >> >>>
>> > >> >>> Hi Martin,
>> > >> >>>
>> > >> >>> On 8 January 2014 12:29, Martin Bjorklu= nd <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 leadin= g to this draft =A0documented 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-no= des be resources. Am I correct in
>> > >> >>> >> >> interpreting
>> > >> >>> >> >> it
>> > >> >>> >> >> that now =A0every lea= f node =A0effectively becomes a resource
>> > >> >>> >> >> with a
>> > >> >>> >> >> separate URI? Could t= he authors provide some more insight
>> > >> >>> >> >> regarding
>> > >> >>> >> >> this change?
>> > >> >>> >> >>
>> > >> >>> >> >
>> > >> >>> >> >
>> > >> >>> >> >
>> > >> >>> >> > Since YANG Patch is now o= ptional, there is no way to delete
>> > >> >>> >> > an
>> > >> >>> >> > optional leaf
>> > >> >>> >> > or leaf-list otherwise, e= xcept to copy the entire resource,
>> > >> >>> >> > and
>> > >> >>> >> > then
>> > >> >>> >> > replace
>> > >> >>> >> > the entire resource (minu= s 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 ev= ery single data leaf is a
>> > >> >>> >> resource,
>> > >> >>> >> instead of an attribute
>> > >> >>> >
>> > >> >>> > Yes, every leaf is a subresource t= o its parent list or
>> > >> >>> > container.
>> > >> >>> > This just means that you can GET/P= OST/DELETE the leaf directly,
>> > >> >>> > w/o
>> > >> >>> > having to PATCH the parent.
>> > >> >>> >
>> > >> >>> >> and the spec doesn't speci= fy a distinction
>> > >> >>> >> between handling parent resour= ces 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 t= he 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-resou= rce that doesn't meet some
>> > >> >>> >> condition
>> > >> >>> >> of
>> > >> >>> >> the parent be handled? For a s= ingle parent resource, how
>> > >> >>> >> should
>> > >> >>> >> multiple sub-resource changes = be coordinated (the parent
>> > >> >>> >> resource
>> > >> >>> >> needs to be consistent)? Etc.<= br> >> > >> >>> >
>> > >> >>> > I am afraid I do not understand yo= ur concern. =A0Could you
>> > >> >>> > provide an
>> > >> >>> > example (data model and requests) = that you feel is problematic
>> > >> >>> > or
>> > >> >>> > unclear?
>> > >> >>>
>> > >> >>>
>> > >> >>> A simple example:
>> > >> >>>
>> > >> >>> =A0 =A0 container book {
>> > >> >>>
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf pr= ice {
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0type string;
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf ta= x-amount {
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0type string;
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> > >> >>>
>> > >> >>> =A0 =A0 =A0}
>> > >> >>>
>> > >> >>> Price and taxt are typically related. >> > >> >>> A (better) REST API design would seek t= o minimize transactional
>> > >> >>> effects to the client while protecting = the consistency/sanity of
>> > >> >>> the
>> > >> >>> data: To update the resource, a POST op= eration to foo/book would
>> > >> >>> carry
>> > >> >>> in the envelope both a new price and th= e 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 s= ucceeds 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, =A0its 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 lik= ely both), and will lead
>> > >> >>> to
>> > >> >>> brittle API and poor user experience. >> > >> >>>
>> > >> >>> Another quick example:
>> > >> >>>
>> > >> >>>
>> > >> >>> =A0 =A0 container book {
>> > >> >>>
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 list pa= ge {
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= key page-nr;
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= leaf page-nr {type string;}
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= leaf text {type string;}
>> > >> >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} >> > >> >>> =A0 =A0 =A0}
>> > >> >>>
>> > >> >>> The RESTConf URI for the above would &l= t;root stuff
>> > >> >>> here>/book/page/{page-nr}/text
>> > >> >>>
>> > >> >>> In general with REST APIs it is importa= nt that we do NOT expose
>> > >> >>> the
>> > >> >>> dependent sub-resources directly thus a= llowing someone to create
>> > >> >>> (POST
>> > >> >>> or PUT) to <root stuff here>/book= /page/{page-nr} =A0without a book,
>> > >> >>> or
>> > >> >>> text without a page, or other cases tha= t do not make sense, and
>> > >> >>> in
>> > >> >>> general requiring a feast of error case= s.
>> > >> >>> Requiring the text POST/PUT =A0handler = 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 wa= s driven by questions/problems
>> > >> >>> >> in the
>> > >> >>> >> support of HTTP Patch operatio= n (incl. JSON patch), the
>> > >> >>> >> solution
>> > >> >>> >> appears to be possibly worse t= han the supposed problem. That's
>> > >> >>> >> why
>> > >> >>> >> it
>> > >> >>> >> would be good to understand th= e rationale some more.
>> > >> >>> >
>> > >> >>> > If the "yang patch" medi= a type is opitonal, there is no other
>> > >> >>> > way to
>> > >> >>> > delete optional leafs. =A0If the o= ptional leaf is a resource it
>> > >> >>> > can be
>> > >> >>> > removed with DELETE.
>> > >> >>>
>> > >> >>> Yes, but the current "solution&quo= t; is IMO a lot worse than a)
>> > >> >>> mandating
>> > >> >>> PATCH, and I mean plain JSON/XML PATCH = =A0or 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.=
>> > >> >>>
>> > >> >>
>> > >> >>
>> > >> >> Plain PATCH does not allow an optional leaf= to be deleted.
>> > >> >> JSON patch does not work well with named da= ta like YANG.
>> > >> >> Ignoring YANG naming and using integer indi= ces that renumber
>> > >> >> every time a list is changed is a non-start= er. =A0The only way to
>> > >> >> delete an optional leaf is to GET the entir= e parent resource,
>> > >> >> edit it offline (remove the leaf) and PUT t= he parent resource.
>> > >> >> This is operationally disruptive and expens= ive to implement
>> > >> >> in the server. =A0Optional leafs make up mo= st configuration data,
>> > >> >> so a CM solution that doesn't work well= for optional leafs is a
>> > >> >> bad
>> > >> >> idea.
>> > >> >
>> > >> > I should have been clearer: Media Type discussi= on aside, I meant
>> > >> > JSON
>> > >> > patch as in "json patch for json reresente= d yang data", ie likely a
>> > >> > subset of pure 'application/json-patch+json= ', with yang-patch being
>> > >> > in
>> > >> > some other doc. . The fact that JSON patch does= not work for xml
>> > >> > is,
>> > >> > for me at least, not an issue. A simple answer = can thus be that the
>> > >> > patch is for json only.
>> > >> > In general, I don't quite follow why you sa= y that json patch
>> > >> > doesn't
>> > >> > allow for leaf deletion; the "remove"= op seems to be pretty much
>> > >> > intended for that. Gee, the json (yang) patch c= ould even be just
>> > >> > limited to just this task.
>> > >> >
>> > >> > That said, a solution to the " how to dele= te an optional leaf"
>> > >> > problem
>> > >> > that ends up treating every data item in the sy= stem to a resource,
>> > >> > with no way for the designer to override, appea= rs also as a bad
>> > >> > idea.
>> > >> > Given that we have a full API spec here, even a= dding a custom
>> > >> > parameterized operation to the URI may be a bet= ter solution. Also,
>> > >> > evidence from the REST API world out there also= indicates that for
>> > >> > better or worse, GET and PUT do actually work a= t scale. I would
>> > >> > still
>> > >> > see this still as easier to deal with and imple= ment than having
>> > >> > every
>> > >> > single (sub-resource) data item as a resource..= ..
>> > >> >
>> > >> > So, in summary, "conservative" option= s, all leading to getting the
>> > >> > spec back from resource extremes as I see can b= e:
>> > >> > 1. Stay with GET and PUT (I suspect that this i= s what will get most
>> > >> > use
>> > >> > anyway).
>> > >> > 2. Introduce JSON patching, in the form of say<= br> >> > >> > "application/yang-json-patch" to the = spec (happy to work up some
>> > >> > text)
>> > >> > 3. Get back the "full" yang patch fro= m draft -02
>> > >> > 4. Introduce a new action/operation invoked via= a parameter.
>> > >>
>> > >> Forgot to add one more:
>> > >> 5. Introduce meta-data to handle the partial update.=
>> > >>
>> > >> >
>> > >> > Thoughts?
>> > >> >
>> > >> > Cheers.
>> > >> >>
>> > >> >>
>> > >> >>>
>> > >> >>> Cheers,
>> > >> >>> Wojciech.
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> Andy
>> > >> >>
>> > >> >>>
>> > >> >>> >
>> > >> >>> > /martin
>> > >> >>
>> > >> >>
>> > >
>> > >
>> >
>
>

--047d7bd75132f5902a04efffa951-- From kwatsen@juniper.net Wed Jan 15 09:58:21 2014 Return-Path: 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 DEAF71AE131 for ; Wed, 15 Jan 2014 09:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 CDWQE0o7SLxh for ; Wed, 15 Jan 2014 09:58:20 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 70B331AE11D for ; Wed, 15 Jan 2014 09:58:20 -0800 (PST) Received: from mail210-tx2-R.bigfish.com (10.9.14.243) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Wed, 15 Jan 2014 17:57:52 +0000 Received: from mail210-tx2 (localhost [127.0.0.1]) by mail210-tx2-R.bigfish.com (Postfix) with ESMTP id 320628C009F; Wed, 15 Jan 2014 17:57:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h1155h) Received-SPF: pass (mail210-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(164054003)(199002)(189002)(87266001)(63696002)(74502001)(85306002)(79102001)(69226001)(76786001)(74876001)(46102001)(87936001)(74706001)(561944002)(76796001)(92566001)(81686001)(92726001)(81342001)(77096001)(47976001)(81816001)(85852003)(47736001)(51856001)(53806001)(66066001)(81542001)(74662001)(80022001)(76482001)(36756003)(80976001)(56816005)(65816001)(83322001)(2656002)(59766001)(83072002)(31966008)(50986001)(74366001)(54356001)(49866001)(47446002)(4396001)(54316002)(90146001)(77982001)(56776001)(93136001)(83506001)(93516002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail210-tx2 (localhost.localdomain [127.0.0.1]) by mail210-tx2 (MessageSwitch) id 1389808670369087_15873; Wed, 15 Jan 2014 17:57:50 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.232]) by mail210-tx2.bigfish.com (Postfix) with ESMTP id 566438A0068; Wed, 15 Jan 2014 17:57:50 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 15 Jan 2014 17:57:43 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Wed, 15 Jan 2014 17:57:30 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.842.7; Wed, 15 Jan 2014 17:57:27 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.64]) with mapi id 15.00.0842.003; Wed, 15 Jan 2014 17:57:27 +0000 From: Kent Watsen To: Wojciech Dec , Andy Bierman Thread-Topic: [Netconf] RESTCONF Resource Model Thread-Index: AQHPEXBgoWwR9DdJq0iwuCV4AD4HJ5qEymwAgAC80ICAADiOAA== Date: Wed, 15 Jan 2014 17:57:27 +0000 Message-ID: References: <20140114.223329.95627287.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.14] x-forefront-prvs: 00922518D8 Content-Type: text/plain; charset="us-ascii" Content-ID: <3BC88E223D046546862BCF3FB97C5BA5@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2014 17:58:22 -0000 Hi Wojciech, As I see it, the access-model defined in the current RESTCONF proposal is very similar NETCONF. Both provide a hierarchical tree of data that clients can get/edit/delete at any level. In NETCONF, the "verbs" are (w/ subtree filtering) and (with operations), while in HTTP its POST/GET/PUT/DELETE and an optional PATCH. In both cases the client needs to know what it's doing and the server enforces constraints defined by the YANG model. Is there a significant difference I'm missing? Thanks, Kent From wdec.ietf@gmail.com Thu Jan 16 05:30:26 2014 Return-Path: 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 C49671AE349 for ; Thu, 16 Jan 2014 05:30:26 -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 TmdZArLjNy4V for ; Thu, 16 Jan 2014 05:30:25 -0800 (PST) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 736FA1AE0BB for ; Thu, 16 Jan 2014 05:30:25 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id jt11so590420pbb.29 for ; Thu, 16 Jan 2014 05:30:13 -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=lzhXZsm7l2oUwLfB2tapcrPScmGBZAU22ZCuQw/N9l0=; b=D8h8HfPuLORA0Kn9F13ZTTZ6HLMGpVdRsRY9n9lgEtyt8VtS5jEXbRqy78fRqvQSXj 0H6aHrvllFksunkR+5ftyhXBZPtzjObnA+Qmecfc7YoPz/Tue32bLffvWMqF2k+pRmcV a7vxt5OkcHsRG6bUG8O07o/f2u0Y51D8pG/M4xPgftprJ73Ib9iR5d2ampibwhp9DANT t2eJ4LfkDmVYSK5Lge4iDUm+c04LUn1pI1TeIs8eucbaMNuJ/2Dc8R3nSKI54P9eMefu jjCbFGtqbHQP4TPjeLs3hyVea1mTXtTlXWfoffhEUkf8M2iw+VX/HY04iupC4QztJ+N5 bJ9w== MIME-Version: 1.0 X-Received: by 10.66.165.4 with SMTP id yu4mr10081286pab.88.1389879013515; Thu, 16 Jan 2014 05:30:13 -0800 (PST) Received: by 10.70.57.163 with HTTP; Thu, 16 Jan 2014 05:30:13 -0800 (PST) In-Reply-To: References: <20140114.223329.95627287.mbj@tail-f.com> Date: Thu, 16 Jan 2014 14:30:13 +0100 Message-ID: From: Wojciech Dec To: Kent Watsen Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 13:30:27 -0000 Hi Kent, well, NETCONF provides a good deal more than is typically encountered, or sensible in RESTful designs, eg the "rollback-on-error". Candidly, I don't think that RESTConf is or should be an HTTP based equivalent of Netconf. If it is to be so then a title like HTTPCONF may be better. Regards, Wojciech. On 15 January 2014 18:57, Kent Watsen wrote: > > Hi Wojciech, > > As I see it, the access-model defined in the current RESTCONF proposal is > very similar NETCONF. Both provide a hierarchical tree of data that > clients can get/edit/delete at any level. In NETCONF, the "verbs" are > (w/ subtree filtering) and (with operations), > while in HTTP its POST/GET/PUT/DELETE and an optional PATCH. In both > cases the client needs to know what it's doing and the server enforces > constraints defined by the YANG model. Is there a significant difference > I'm missing? > > Thanks, > Kent > > > From wdec.ietf@gmail.com Thu Jan 16 05:41:44 2014 Return-Path: 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 68D341AE1F8 for ; Thu, 16 Jan 2014 05:41:44 -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 g8_mipDzULwB for ; Thu, 16 Jan 2014 05:41:41 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF9B1AE2CB for ; Thu, 16 Jan 2014 05:41:41 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so2701547pad.27 for ; Thu, 16 Jan 2014 05:41:29 -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=jrWCJnqP1LFlmV6iPYa0U5ms92RFPqoZ35IlE/WJtYM=; b=rb/MCqnOvLPf3+eIwI7ymb4c78UAwHlvf+uR0qGsG2ROHJhyvC2rWQ0WzmYS4PZXuM j5lk2qsGTV+IYodcwd4R0regO68DKrx1jtlQwrw1czonFK7oleM/U5BnPBcg8UgLtiMH OXmHL7n4nZxYNn02ILL0G8ji/VAZQ7wyM02eujt82nAjAMhRsEDKvlyeoYvPhFwxjITF 97hkw3M+8foMVrmK9RbxjkeuYWV0TBHsCjaF9nly0uDTabEfVQGm5HFqxLZbx2fasf36 BWycuyacKBWyYU59d34oygKOOD+QW96VPFG+nKNc8Lqx0CuQ62QFXdi2aWKXW003aJxs fQRw== MIME-Version: 1.0 X-Received: by 10.68.247.6 with SMTP id ya6mr9920657pbc.45.1389879689317; Thu, 16 Jan 2014 05:41:29 -0800 (PST) Received: by 10.70.57.163 with HTTP; Thu, 16 Jan 2014 05:41:29 -0800 (PST) In-Reply-To: References: <20140114.223329.95627287.mbj@tail-f.com> Date: Thu, 16 Jan 2014 14:41:29 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 13:41:44 -0000 On 15 January 2014 11:20, Andy Bierman wrote: > > > > On Wed, Jan 15, 2014 at 1:34 AM, Wojciech Dec wrote: >> >> On 14 January 2014 23:19, Andy Bierman wrote: >> > >> > >> > >> > On Tue, Jan 14, 2014 at 1:33 PM, Martin Bjorklund >> > wrote: >> >> >> >> Wojciech Dec wrote: >> >> > On 10 January 2014 19:03, Andy Bierman wrote: >> >> > > Hi, >> >> > > >> >> > > The resource management model is a fairly important part of >> >> > > the RESTCONF architecture. Perhaps all attempts so far have >> >> > > been too simplistic. >> >> > > >> >> > > The YANG node type seems to be irrelevant to answering >> >> > > the question "what is a sub-resource?" The set of mandatory[1] >> >> > > descendant nodes are not sub-resources of a given parent. >> >> > > They must exist and cannot be created and deleted >> >> > > independently of the parent resource. So a sub-resource >> >> > > is really any descendant sub-tree that can be created and >> >> > > deleted independent of the parent resource. >> >> > > >> >> > > IMO there should not be a complex set of rules for restricting URIs >> >> > > and HTTP methods, based on mandatory vs. optional nodes. >> >> > > This is a conceptual distinction which does not need to be >> >> > > enforced somehow in the protocol. >> >> > >> >> > The problem is that in designing an API, it's generally crucial to >> >> > allow the designer to control how the API will be consumed. >> >> >> >> Agreed. >> >> >> >> > The -03 >> >> > Restconf spec removes most of such controls by not distinguishing >> >> > between a resource and its sub-resources: every possible data item is >> >> > a URI resource possibly exposed to the HTTP verbs, and likewise every >> >> > resource is a data item of its parent resource. Relying on the client >> >> > in "knowing" the "right way" in which to consume an API will lead to >> >> > poor API experience(s) and breakages like leading to corrupt data, >> >> > besides likely gross deviation from REST principles. An Example of >> >> > the >> >> > corruption problem was/is presented below in the original text in the >> >> > "update tax-amount along with price" example. >> >> >> >> As I already wrote, the proper YANG-way to handle this case is to >> >> provide constraint in the data model, in the form of must >> >> expressions. Just requiring the client to always send both values >> >> doesn't guarantee anything. >> > >> > >> > >> > I think a client could be developed that viewed all YANG terminals >> > as attributes and all lists and containers as resources. I do not >> > see the value in this approach, because in order to edit a resource >> > the app really needs to know the YANG definition of the resource. >> >> Yes, given our previous discussion on URI's, etc, I see that in the >> generic case apps would require to also know the YANG definition too, >> but whether the app chooses to update a composite resource going >> sub-resource by sub-resource or addressing the resource is something >> that the YANG model doesn't say. As mentioned, typically the API >> designer has the levers to guide this sort of behavior. >> > > > container my-resource { > leaf a { type string; } > list b { > min-elements 1; > key x; > leaf x { type string; } > } > } > > Here is an example that breaks the simple "lists are sub-resources" design. > The client code cannot assume that it always has to provide child leafs and > never > has to provide child lists. The server will reject requests to create > my-resource > unless it has at least 1 instance of list b. The client cannot ignore the > YANG constraints. > > > >> > >> > A generic "create_resource" approach based on containers/leafs, etc. >> > may not work because the must/min-elements/mandatory type of >> > constraints will be enforced by the server, even if they are ignored >> > by the client. >> > >> > >> >> >> >> > Relying on the client to >> >> > "do the right thing" is problematic, if the history of API usage is >> >> > anything to go by. >> >> >> >> Right, so this is why constraint enforcement in the server is >> >> important. >> >> >> >> > The way I see it: Draft -02 did not have this issue, at least not as >> >> > a >> >> > major issue. Now, the issue was seemingly introduced in draft -03 to >> >> > address another problem, the deletion of an optional leaf/data-item, >> >> > for which there are other reasonable solutions that do not lead to >> >> > the >> >> > issue in draft -03. Summarized, the solutions to these partial >> >> > deletes >> >> > are: >> > >> > >> > >> > I still do not understand the issue. >> > Declaring containers and lists to be resources and leaf, leaf-list >> > to be attributes does not account for the YANG constraints. I don't >> > see how preventing the server from accepting a DELETE on >> > a leaf or leaf-list breaks any clients. If your client doesn't >> > want to use DELETE and prefers to use YANG Patch or PUT instead, >> > that still works. >> >> Well, that's because it is not the client that breaks, but rather, >> actions by the client can (and actually case will, coz we've seen this >> in other REST APIs) corrupt the state of the data-store/lead to >> inconsistent data on the server. Since the sub resources are directly >> accessible, they could get updated directly and asynchronously >> irrespective of any related sub-resources. Should a client fail after >> doing the "PUT/update price" but before "PUT/update tax-amount", the >> store will be in trouble. > > > YANG defines what needs to be present for the resource to be valid. > Nothing short of understanding the YANG constraints is going to > prevent an app from sending invalid requests. Think you're answering a different question . The case/problem I highlighted was a problem of API design, whereby the Restconf Spec doesn't give any control to the API designer. A (well) designed API for the simplistic "update book price & tax-amount" use-case would see (by design) the user send in a PUT/update book {price: $10, tax-amount: $2}, rather than allow all three combinations of updating that/those resource(s). I.e. the price is not a free resource, but a characteristic (sub-resource) of the book. Cheers > > >> >> A side problem in this is also what should clients accessing the >> parent resource see while these "sub transactions" are happening. >> With REST, this problem is much easier to deal with when the >> PUT/update operation is done at the parent level. >> >> This type of problem is sometimes "solved" in some (supposedly) >> RESTful services by locking the resource (ie trying to do a >> synchronous change), locking related resources, etc. >> >> Regards, >> Wojciech. > > > > Andy > >> >> > >> > >> >> > >> >> > 1. Stay with GET and PUT as the means to update (even if sub-optimal >> >> > from a data size transfer - they work for most APIs) >> >> >> >> This means that if you want to delete two optional leafs in two >> >> different resources, you have to do two PUTs. This means two >> >> different transactions. >> >> >> >> > 2. Introduce a subset of regular JSON patching, in the form of a new >> >> > media-type, that provides specifically the "delete" operation >> >> > 3. Indicate a "full" yang patch, as was done in draft -02 (or >> >> > whichever draft that text lives in now). >> >> >> >> Yes this might be an option. >> >> >> >> > 4. Introduce a new action/operation resource (eg >> >> > test.com/restconf/jukebox/songs/delete) >> >> >> >> This has the same problem as 1. >> >> >> >> > 5. Define a new meta-data header for the partial delete operation. >> >> >> >> Is this restful / httpful? >> >> >> >> > That said, there is another solution, which however involves Yang: 6. >> >> > Define in Yang a meta-parameter which designates what containers or >> >> > lists are to be URIs or have their end-leaf resources "directly" >> >> > exposed. >> >> >> >> This is something we have discussed from the very start as well. So >> >> far we haven't seen any user requirements for it. However, it doesn't >> >> solve the delete problem. >> >> >> >> >> >> /martin >> > >> > >> > >> > Andy >> > >> > >> >> >> >> >> >> >> >> >> >> > Surely, some other options can also come into play, but in essence, I >> >> > think at least the above options need to be looked at. >> >> > An eventual solution to these problems would be for implementations >> >> > to >> >> > "manually" mark up their code, in effect steering or staying away >> >> > from >> >> > Restconf, or leaving it confined to some very narrow usage/audience >> >> > which would be a shame. >> >> > >> >> > Regards, >> >> > Wojciech. >> >> > >> >> > > >> >> > > It seems arbitrary to say that a resource target URI can point >> >> > > at a container/list but not a leaf/leaf-list. The server is going >> >> > > to use the YANG validation rules to determine if an operation >> >> > > is allowed. DELETE will fail for a mandatory container, same >> >> > > as a leaf. >> >> > > >> >> > > [1] mandatory can be complex: >> >> > > static: mandatory, min-elements >> >> > > dynamic: if-feature, when + >> >> > > >> >> > > >> >> > > Andy >> >> > > >> >> > > >> >> > > On Fri, Jan 10, 2014 at 7:13 AM, Wojciech Dec >> >> > > wrote: >> >> > >> >> >> > >> On 10 January 2014 14:39, Wojciech Dec >> >> > >> wrote: >> >> > >> > On 10 January 2014 11:37, Andy Bierman >> >> > >> > wrote: >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> On Fri, Jan 10, 2014 at 1:37 AM, Wojciech Dec >> >> > >> >> >> >> > >> >> wrote: >> >> > >> >>> >> >> > >> >>> Hi Martin, >> >> > >> >>> >> >> > >> >>> On 8 January 2014 12:29, Martin Bjorklund >> >> > >> >>> wrote: >> >> > >> >>> > Wojciech Dec wrote: >> >> > >> >>> >> On 6 January 2014 12:49, Andy Bierman >> >> > >> >>> >> wrote: >> >> > >> >>> >> > >> >> > >> >>> >> > >> >> > >> >>> >> > >> >> > >> >>> >> > On Mon, Jan 6, 2014 at 3:33 AM, Wojciech Dec >> >> > >> >>> >> > >> >> > >> >>> >> > 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 > >> > >> >>> 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 /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. >> >> > >> >>> >> >> > >> >> >> >> > >> >> >> >> > >> >> Plain PATCH does not allow an optional leaf to be deleted. >> >> > >> >> JSON patch does not work well with named data like YANG. >> >> > >> >> Ignoring YANG naming and using integer indices that renumber >> >> > >> >> every time a list is changed is a non-starter. The only way to >> >> > >> >> delete an optional leaf is to GET the entire parent resource, >> >> > >> >> edit it offline (remove the leaf) and PUT the parent resource. >> >> > >> >> This is operationally disruptive and expensive to implement >> >> > >> >> in the server. Optional leafs make up most configuration data, >> >> > >> >> so a CM solution that doesn't work well for optional leafs is a >> >> > >> >> bad >> >> > >> >> idea. >> >> > >> > >> >> > >> > I should have been clearer: Media Type discussion aside, I meant >> >> > >> > JSON >> >> > >> > patch as in "json patch for json reresented yang data", ie >> >> > >> > likely a >> >> > >> > subset of pure 'application/json-patch+json', with yang-patch >> >> > >> > being >> >> > >> > in >> >> > >> > some other doc. . The fact that JSON patch does not work for xml >> >> > >> > is, >> >> > >> > for me at least, not an issue. A simple answer can thus be that >> >> > >> > the >> >> > >> > patch is for json only. >> >> > >> > In general, I don't quite follow why you say that json patch >> >> > >> > doesn't >> >> > >> > allow for leaf deletion; the "remove" op seems to be pretty much >> >> > >> > intended for that. Gee, the json (yang) patch could even be just >> >> > >> > limited to just this task. >> >> > >> > >> >> > >> > That said, a solution to the " how to delete an optional leaf" >> >> > >> > problem >> >> > >> > that ends up treating every data item in the system to a >> >> > >> > resource, >> >> > >> > with no way for the designer to override, appears also as a bad >> >> > >> > idea. >> >> > >> > Given that we have a full API spec here, even adding a custom >> >> > >> > parameterized operation to the URI may be a better solution. >> >> > >> > Also, >> >> > >> > evidence from the REST API world out there also indicates that >> >> > >> > for >> >> > >> > better or worse, GET and PUT do actually work at scale. I would >> >> > >> > still >> >> > >> > see this still as easier to deal with and implement than having >> >> > >> > every >> >> > >> > single (sub-resource) data item as a resource.... >> >> > >> > >> >> > >> > So, in summary, "conservative" options, all leading to getting >> >> > >> > the >> >> > >> > spec back from resource extremes as I see can be: >> >> > >> > 1. Stay with GET and PUT (I suspect that this is what will get >> >> > >> > most >> >> > >> > use >> >> > >> > anyway). >> >> > >> > 2. Introduce JSON patching, in the form of say >> >> > >> > "application/yang-json-patch" to the spec (happy to work up some >> >> > >> > text) >> >> > >> > 3. Get back the "full" yang patch from draft -02 >> >> > >> > 4. Introduce a new action/operation invoked via a parameter. >> >> > >> >> >> > >> Forgot to add one more: >> >> > >> 5. Introduce meta-data to handle the partial update. >> >> > >> >> >> > >> > >> >> > >> > Thoughts? >> >> > >> > >> >> > >> > Cheers. >> >> > >> >> >> >> > >> >> >> >> > >> >>> >> >> > >> >>> Cheers, >> >> > >> >>> Wojciech. >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> Andy >> >> > >> >> >> >> > >> >>> >> >> > >> >>> > >> >> > >> >>> > /martin >> >> > >> >> >> >> > >> >> >> >> > > >> >> > > >> >> > >> > >> > > > From kwatsen@juniper.net Thu Jan 16 10:41:30 2014 Return-Path: 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 104311A1F62 for ; Thu, 16 Jan 2014 10:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 OcIE5PJEQ4Ht for ; Thu, 16 Jan 2014 10:41:27 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B71A1F61 for ; Thu, 16 Jan 2014 10:41:26 -0800 (PST) Received: from mail76-co1-R.bigfish.com (10.243.78.248) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.22; Thu, 16 Jan 2014 18:41:14 +0000 Received: from mail76-co1 (localhost [127.0.0.1]) by mail76-co1-R.bigfish.com (Postfix) with ESMTP id 87FB35C006F; Thu, 16 Jan 2014 18:41:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h1155h) Received-SPF: pass (mail76-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(189002)(164054003)(199002)(77096001)(56776001)(80022001)(31966008)(4396001)(69226001)(54316002)(50986001)(77982001)(66066001)(74662001)(81816001)(65816001)(79102001)(2656002)(83322001)(81542001)(74366001)(56816005)(83072002)(81342001)(49866001)(74876001)(47976001)(59766001)(47736001)(81686001)(53806001)(76786001)(87936001)(54356001)(83506001)(74502001)(87266001)(80976001)(47446002)(85306002)(74706001)(92566001)(51856001)(90146001)(76482001)(46102001)(76796001)(85852003)(93136001)(63696002)(93516002)(36756003)(92726001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail76-co1 (localhost.localdomain [127.0.0.1]) by mail76-co1 (MessageSwitch) id 138989767299404_29833; Thu, 16 Jan 2014 18:41:12 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.251]) by mail76-co1.bigfish.com (Postfix) with ESMTP id 09ED8720048; Thu, 16 Jan 2014 18:41:12 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 16 Jan 2014 18:41:11 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 16 Jan 2014 18:41:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.842.7; Thu, 16 Jan 2014 18:40:57 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.64]) with mapi id 15.00.0842.003; Thu, 16 Jan 2014 18:40:56 +0000 From: Kent Watsen To: Wojciech Dec Thread-Topic: [Netconf] RESTCONF Resource Model Thread-Index: AQHPEXBgoWwR9DdJq0iwuCV4AD4HJ5qEymwAgAC80ICAADiOAIABm4CAgAAC/AA= Date: Thu, 16 Jan 2014 18:40:56 +0000 Message-ID: References: <20140114.223329.95627287.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.14] x-forefront-prvs: 0093C80C01 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 18:41:30 -0000 >well, NETCONF provides a good deal more than is typically encountered, >or sensible in RESTful designs, eg the "rollback-on-error". That doesn't address the point I was trying to make, let me try again. You're having concern with an API strategy and I pointed out that it's essentially the same as what we've been doing with NETCONF for some time now. It seems that if the issue was significant, it would've been raised before, but that isn't the case, which suggests this is a non-issue, unless there is a significant difference between the two. Can you identify one? FWIW, RESTCONF doesn't support rollback-on-error, since it relies on YANG-based enforcement, a luxury NETCONF didn't start with. Thanks, Kent From wdec.ietf@gmail.com Fri Jan 17 04:23:50 2014 Return-Path: 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 D0F0F1AE08D for ; Fri, 17 Jan 2014 04:23:50 -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 UdK1ul06G6LL for ; Fri, 17 Jan 2014 04:23:49 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 21E961AE08C for ; Fri, 17 Jan 2014 04:23:49 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so1745134pad.0 for ; Fri, 17 Jan 2014 04:23:36 -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=1Yimu/9yzaS3vDPYvCD9PAw2jQ9XETHgekPzqsrtUAc=; b=CzVpn1HzJ//B8U/vtV3PluJBOFkqCk/6d6w6nFwsfkzqx/sIbd/kydIE5wdFSn0BUb louhs883+JCC9gctimWfLO/5PfcclT3KGgMrxpq/pko60V6XH0qEH1SZGUGPOAx5s0cb 6lkMgvjGFHX06N+6LA/Az3iEbdcw/1qog5l+FSQRmWmdgb3j1KY0FToQIbjPfLYbna40 yb3xv2C76lDUU8DpGIv6OweMcyoeNDe8jTlfA2lOJtLW3/Sq6iRaPzlnsCwDJEYPrZ3h YaSv33ZNIt7OmqlxW+LKTYcXjpmFFCBBh8kcr1xulI1Zss8VrQpkUim6rAIz2dkLHpjx Tk4g== MIME-Version: 1.0 X-Received: by 10.66.165.4 with SMTP id yu4mr1835521pab.88.1389961416790; Fri, 17 Jan 2014 04:23:36 -0800 (PST) Received: by 10.70.57.163 with HTTP; Fri, 17 Jan 2014 04:23:36 -0800 (PST) In-Reply-To: References: <20140114.223329.95627287.mbj@tail-f.com> Date: Fri, 17 Jan 2014 13:23:36 +0100 Message-ID: From: Wojciech Dec To: Kent Watsen Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 12:23:51 -0000 On 16 January 2014 19:40, Kent Watsen wrote: > > > >>well, NETCONF provides a good deal more than is typically encountered, >>or sensible in RESTful designs, eg the "rollback-on-error". > > That doesn't address the point I was trying to make, let me try again. > You're having concern with an API strategy and I pointed out that it's > essentially the same as what we've been doing with NETCONF for some time > now. It seems that if the issue was significant, it would've been raised > before, but that isn't the case, which suggests this is a non-issue, > unless there is a significant difference between the two. Can you > identify one? Quoting from previous mail. Consider the following container book { leaf price { type string; } leaf tax-amount { type string; } } Price and tax-amount are related, and both exist only because of the book. A (proper) REST API design would seek to minimize transactional (ill) effects to the client while protecting the consistency/sanity of the data: To update the book 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, subject to separate POST operations, which is what the changes in draft -03 lead to (and draft -01, -02 didn't)... These can fail and leave inconsistent data around, etc. > > FWIW, RESTCONF doesn't support rollback-on-error, since it relies on > YANG-based enforcement, a luxury NETCONF didn't start with. ?? NETCONF provides a protocol for elaborate CRUD operations, including "luxuries" (as you put it) of roll-back, which quite definitely would be usable in the above update case should one want to do it with Netconf. As stated previously, the change in the API design in -03 introduced this issue to address a problem that can be dealt with through other means. Cheers. > > Thanks, > Kent > > From mbj@tail-f.com Fri Jan 17 04:28:22 2014 Return-Path: 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 B56A61AE097 for ; Fri, 17 Jan 2014 04:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 pyPt7RrQZjvD for ; Fri, 17 Jan 2014 04:28:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 301F91AE08C for ; Fri, 17 Jan 2014 04:28:21 -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 EFD2A240C2D0; Fri, 17 Jan 2014 13:28:07 +0100 (CET) Date: Fri, 17 Jan 2014 13:28:07 +0100 (CET) Message-Id: <20140117.132807.1604250454886260675.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: 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 Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 12:28:22 -0000 Wojciech Dec wrote: > On 16 January 2014 19:40, Kent Watsen wrote: > > > > > > > >>well, NETCONF provides a good deal more than is typically encountered, > >>or sensible in RESTful designs, eg the "rollback-on-error". > > > > That doesn't address the point I was trying to make, let me try again. > > You're having concern with an API strategy and I pointed out that it's > > essentially the same as what we've been doing with NETCONF for some time > > now. It seems that if the issue was significant, it would've been raised > > before, but that isn't the case, which suggests this is a non-issue, > > unless there is a significant difference between the two. Can you > > identify one? > > > Quoting from previous mail. Consider the following > > container book { > > leaf price { > type string; > } > leaf tax-amount { > type string; > } > > } > > Price and tax-amount are related, and both exist only because of the book. > A (proper) REST API design would seek to minimize transactional (ill) > effects to the client while protecting the consistency/sanity of the > data: To update the book resource, a POST operation to foo/book would > carry in the envelope both a new price and the tax amount. The current RESTCONF document does this. > A (worse) > REST API design would expose both price and tax-amount as separate > resources, subject to separate POST operations The current RESTCONF document does this as well. The client can choose the method it wants to use. I think we're going in circles... /martin From lhotka@nic.cz Fri Jan 17 04:31:04 2014 Return-Path: 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 D4AAC1AE0A3 for ; Fri, 17 Jan 2014 04:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.189 X-Spam-Level: X-Spam-Status: No, score=-1.189 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.538] 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 mvpf1kztDXSD for ; Fri, 17 Jan 2014 04:31:03 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 97B5B1AE093 for ; Fri, 17 Jan 2014 04:31:02 -0800 (PST) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 8814F1400F5; Fri, 17 Jan 2014 13:30:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1389961849; bh=oAeZa6L2C/9USCMNO2eMRpPs59eyQHnUGcJBYcjS+EM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kewoLvhwsFsMOdEYhPb5F6IggqmafOSTGH3/LNasNJYTuwHw8c5YY4Xz1n6tkK091 hcbswCVYJLamFIEFqLJZcOOOOQ7YJESqHH9rmDv+rHdv8PFuKgP/bgzRNevacuokwn r5G25jaGcutt2DAxH3TYO187c3W5fgI7SGjKLJNQ= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 17 Jan 2014 13:30:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08CBFC94-CBD3-4FC4-BA0C-EF1AA229EF93@nic.cz> References: <20140114.223329.95627287.mbj@tail-f.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] RESTCONF Resource Model X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 12:31:05 -0000 On 17 Jan 2014, at 13:23, Wojciech Dec wrote: > On 16 January 2014 19:40, Kent Watsen wrote: >>=20 >>=20 >>=20 >>> well, NETCONF provides a good deal more than is typically = encountered, >>> or sensible in RESTful designs, eg the "rollback-on-error". >>=20 >> That doesn't address the point I was trying to make, let me try = again. >> You're having concern with an API strategy and I pointed out that = it's >> essentially the same as what we've been doing with NETCONF for some = time >> now. It seems that if the issue was significant, it would've been = raised >> before, but that isn't the case, which suggests this is a non-issue, >> unless there is a significant difference between the two. Can you >> identify one? >=20 >=20 > Quoting from previous mail. Consider the following >=20 > container book { >=20 > leaf price { > type string; > } > leaf tax-amount { > type string; > } >=20 > } >=20 > Price and tax-amount are related, and both exist only because of the = book. Sorry, this particular example doesn=92t work for me. In my country, VAT = rate changes every 6 months on the average, so for our bookstore owners = it might make a very good sense to be able to adjust tax separately. Lada > A (proper) REST API design would seek to minimize transactional (ill) > effects to the client while protecting the consistency/sanity of the > data: To update the book 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, subject to separate POST operations, which is what the > changes in draft -03 lead to (and draft -01, -02 didn't)... These can > fail and leave inconsistent data around, etc. >=20 >=20 >>=20 >> FWIW, RESTCONF doesn't support rollback-on-error, since it relies on >> YANG-based enforcement, a luxury NETCONF didn't start with. >=20 > ?? > NETCONF provides a protocol for elaborate CRUD operations, including > "luxuries" (as you put it) of roll-back, which quite definitely would > be usable in the above update case should one want to do it with > Netconf. > As stated previously, the change in the API design in -03 introduced > this issue to address a problem that can be dealt with through other > means. >=20 > Cheers. >=20 >>=20 >> Thanks, >> Kent >>=20 >>=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From talmi@marvell.com Sun Jan 19 06:02:05 2014 Return-Path: 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 C37CD1AD8DA for ; Sun, 19 Jan 2014 06:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_PASS=-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 VkXGY8IOfuhc for ; Sun, 19 Jan 2014 06:02:04 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6C1AD68A for ; Sun, 19 Jan 2014 06:02:04 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0JE0fKo009435; Sun, 19 Jan 2014 06:01:49 -0800 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0a-0016f401.pphosted.com with ESMTP id 1hfnyu3xx2-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 19 Jan 2014 06:01:49 -0800 Received: from YK-HUB01.marvell.com (10.4.102.51) by sc-owa02.marvell.com (10.93.76.22) with Microsoft SMTP Server (TLS) id 8.3.327.1; Sun, 19 Jan 2014 06:01:49 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB01.marvell.com ([10.4.102.51]) with mapi; Sun, 19 Jan 2014 16:01:45 +0200 From: Tal Mizrahi To: Joe Marcus Clarke , Tal Mizrahi , "netconf@ietf.org" Date: Sun, 19 Jan 2014 15:57:09 +0200 Thread-Topic: [Netconf] Updated draft-mm-netconf-time-capability-01 Thread-Index: Ac8RUuRYfjLQxaHKTcKxCFN06d+fiQDyu3JQ Message-ID: <74470498B659FA4687F0B0018C19A89C01D4390857BE@IL-MB01.marvell.com> References: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> <52D57BD7.7060006@cisco.com> In-Reply-To: <52D57BD7.7060006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-19_01:2014-01-18,2014-01-19,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401190071 Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 14:02:05 -0000 Hi Joe, Thanks for the comments. > However, the draft doesn't discuss how a client can retrieve the results = of a scheduled RPC. How would I go about ensuring that an RPC completed (o= r not) at the scheduled time? If the client gets an rpc-reply with an element it knows the scheduled= operation was performed successfully.=20 If the client wants to know whether the RPC was performed *on time* it need= s to include the element in the RPC (in addition to including th= e element), causing the server to include the element in the rpc-reply. This allows the client to receive feedback a= bout the actual execution time of the RPC. This behavior is described in se= ction 3.1 of the draft. > I think there should be a way to query the server's current time to make = sure the client and server agree. One way to do this is to use the element; the client can send (a= ny kind of) an RPC to the server which includes the element. Con= sequently, the server includes the in its rpc-reply. It sh= ould be noted that this method allows a *very* rough indication about wheth= er the client and server are synchronized. However, I believe the correct way to inquire about whether the server is s= ynchronized or not is at the clock synchronization protocol layer. For exam= ple, the NTP MIB (RFC 5907) includes a set of objects that allow you to che= ck the current status of NTP, including the offset to the current reference= time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes simi= lar objects.=20 [One may ask whether NTP and PTP have a YANG module for NETCONF, but that i= s a completely different story...:) ] Thanks, Tal Mizrahi. -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Joe Marcus Cla= rke Sent: Tuesday, January 14, 2014 8:03 PM To: Tal Mizrahi; netconf@ietf.org Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 On 1/2/14, 10:56 AM, Tal Mizrahi wrote: >=20 > Hi, >=20 > We have posted an updated draft: > http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 >=20 > Thanks to all the people who reviewed and sent comments about draft 00. > Here is a summary of the changes compared to draft 00: > - We have added discussion about the scheduling tolerance: an upper > bound on how far into the future/past an RPC can be scheduled. > - The scheduled time now refers to the *start* time of the operation, > rather than to its completion. > - The time format has been changed to date-and-time. I read through the draft, Tal, and I have a few comments. Section 3.1: I think there should be a way to query the server's current time to make su= re the client and server agree. This should be part of the overall dialogu= e between the two when scheduling will be done. Even though the client may= be configured to use NTP, the server may not have had a chance to sync to = its clock source. You talk about time sync, but I think this extra level o= f checking will assure that the server doesn't do something the client didn= 't expect. At the very least, the client may decide to abort the scheduled= operation. This goes outside of the time tolerance you define in Section 3.5. I could= , for example, say I have a 10 second tolerance in either direction of time= 2015-10-21T04:29:00.235. The server gets a chance to execute at 2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015= -10-21T05:29:00.235. Section 3.4: You introduce time-interval here without really saying how it will be used.= You do this later, but it seemed a bit disjointed to me. Maybe swap sect= ions 3.4 and 3.5 and mention time-interval in the new section 3.4. Section 4.5 You define the element but you reference it as : OLD TEXT: ...operation. Every message MAY include the ... NEW TEXT: ...operation. Every message MAY include the ... NIT: I would swap the order of and as the forme= r references the latter. Section 4.5.1: You have two leaf nodes with the name sched-max-past. They have two differ= ent descriptions. I think the first should be sched-max-future. > At this point, draft 01 is soft-real-time-oriented. We are interested=20 > to hear feedback about whether there is an interest in the working=20 > group to develop the hard real-time functionality as well. I think soft time is fine. However, the draft doesn't discuss how a client= can retrieve the results of a scheduled RPC. How would I go about ensurin= g that an RPC completed (or not) at the scheduled time? Joe _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From jclarke@cisco.com Sun Jan 19 15:44:40 2014 Return-Path: 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 1B66C1A0004 for ; Sun, 19 Jan 2014 15:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.136 X-Spam-Level: X-Spam-Status: No, score=-13.136 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 bR2M9vQiGF0H for ; Sun, 19 Jan 2014 15:44:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB211A0003 for ; Sun, 19 Jan 2014 15:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5388; q=dns/txt; s=iport; t=1390175079; x=1391384679; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=edb9Puhbx1swOdzrer92Ubbq1ksnPYl7YIkwEkjECe4=; b=PGolHUlKatrMdy1Y49b7xojV3sWMGcD8ZMtxhLiLZ/tlvZuGpByLlHUw azmhk3RGcHKvajjEK/4PRH+bQQXUYwNYHk9RYmn7Yt0J5ldSilIm4vTjm lWHK56AL2cuU87I+veMRJuXHJ7sZYCUeB5+RH0qZusSf+BLMHiRLu2QFh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAABj3FKtJV2Y/2dsb2JhbABZDoJ9OLs8T4EJFnSCJQEBAQMBAQEBNTYKDQQLEQQBAQEJFggHCQMCAQIBFR8JCAYBDAYCAQGHeQgNwycXjwYGhDIBA4lHinWDZoEykGaCbl0e X-IronPort-AV: E=Sophos;i="4.95,687,1384300800"; d="scan'208";a="295341517" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jan 2014 23:44:35 +0000 Received: from rtp-jclarke-8912.cisco.com (rtp-jclarke-8912.cisco.com [10.117.46.163]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0JNiY5p032614; Sun, 19 Jan 2014 23:44:35 GMT Message-ID: <52DC6362.6060509@cisco.com> Date: Sun, 19 Jan 2014 18:44:34 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Tal Mizrahi , Tal Mizrahi , "netconf@ietf.org" References: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> <52D57BD7.7060006@cisco.com> <74470498B659FA4687F0B0018C19A89C01D4390857BE@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01D4390857BE@IL-MB01.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 23:44:40 -0000 On 1/19/14, 8:57 AM, Tal Mizrahi wrote: > Hi Joe, > > Thanks for the comments. > >> However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC. How would I go about ensuring that an RPC completed (or not) at the scheduled time? > > If the client gets an rpc-reply with an element it knows the scheduled operation was performed successfully. > If the client wants to know whether the RPC was performed *on time* it needs to include the element in the RPC (in addition to including the element), causing the server to include the element in the rpc-reply. This allows the client to receive feedback about the actual execution time of the RPC. This behavior is described in section 3.1 of the draft. I don't get this. If I schedule something to run in one hour, I have to wait an hour for the rpc-reply? That doesn't seem right. My understanding from the initial read was that I would get an rpc-reply right away to indicate the request was scheduled successfully. > >> I think there should be a way to query the server's current time to make sure the client and server agree. > > One way to do this is to use the element; the client can send (any kind of) an RPC to the server which includes the element. Consequently, the server includes the in its rpc-reply. It should be noted that this method allows a *very* rough indication about whether the client and server are synchronized. > However, I believe the correct way to inquire about whether the server is synchronized or not is at the clock synchronization protocol layer. For example, the NTP MIB (RFC 5907) includes a set of objects that allow you to check the current status of NTP, including the offset to the current reference time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes similar objects. > [One may ask whether NTP and PTP have a YANG module for NETCONF, but that is a completely different story...:) ] In terms of this draft should there be some text that explain this as a potential concern with suggestions? Joe > > Thanks, > Tal Mizrahi. > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Joe Marcus Clarke > Sent: Tuesday, January 14, 2014 8:03 PM > To: Tal Mizrahi; netconf@ietf.org > Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 > > On 1/2/14, 10:56 AM, Tal Mizrahi wrote: >> >> Hi, >> >> We have posted an updated draft: >> http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 >> >> Thanks to all the people who reviewed and sent comments about draft 00. >> Here is a summary of the changes compared to draft 00: >> - We have added discussion about the scheduling tolerance: an upper >> bound on how far into the future/past an RPC can be scheduled. >> - The scheduled time now refers to the *start* time of the operation, >> rather than to its completion. >> - The time format has been changed to date-and-time. > > I read through the draft, Tal, and I have a few comments. > > Section 3.1: > > I think there should be a way to query the server's current time to make sure the client and server agree. This should be part of the overall dialogue between the two when scheduling will be done. Even though the client may be configured to use NTP, the server may not have had a chance to sync to its clock source. You talk about time sync, but I think this extra level of checking will assure that the server doesn't do something the client didn't expect. At the very least, the client may decide to abort the scheduled operation. > > This goes outside of the time tolerance you define in Section 3.5. I could, for example, say I have a 10 second tolerance in either direction of time 2015-10-21T04:29:00.235. The server gets a chance to execute at > 2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015-10-21T05:29:00.235. > > Section 3.4: > > You introduce time-interval here without really saying how it will be used. You do this later, but it seemed a bit disjointed to me. Maybe swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4. > > Section 4.5 > > You define the element but you reference it as : > > OLD TEXT: > > ...operation. Every message MAY include the ... > > NEW TEXT: > > ...operation. Every message MAY include the ... > > NIT: I would swap the order of and as the former references the latter. > > Section 4.5.1: > > You have two leaf nodes with the name sched-max-past. They have two different descriptions. I think the first should be sched-max-future. > >> At this point, draft 01 is soft-real-time-oriented. We are interested >> to hear feedback about whether there is an interest in the working >> group to develop the hard real-time functionality as well. > > I think soft time is fine. However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC. How would I go about ensuring that an RPC completed (or not) at the scheduled time? > > Joe > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From bclaise@cisco.com Mon Jan 20 16:00:47 2014 Return-Path: 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 9584D1A027A for ; Mon, 20 Jan 2014 16:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 1LYdTxKj1U6C for ; Mon, 20 Jan 2014 16:00:45 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8801A0273 for ; Mon, 20 Jan 2014 16:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15064; q=dns/txt; s=iport; t=1390262444; x=1391472044; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=vCr7dOTGhrNf0dK+L5U4qhcsmW+DYCk3tG8o6XaWxA8=; b=mSN/BaSk3+lWlYZMrlxzIWWQqdvzOyIJp+gszogLa5PzB6cl8XMrQbaU W1RxtLssZ35BVzuzhzc5q4wJTDMae1Mn4Sye54Isum3JImA0IcEbJMMwZ /BE4f4bbYeyq6cOtAl5Dn0vreBGYYUWfnSKNStKmXsqV22+rGpUxP8IKA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJu33VKQ/khN/2dsb2JhbABZgws4vC6BDxZ0giUBAQEDAXkQCxgJHgcPAjURBg0BBQIBAQUSAYdhCA3DeReOfweEOASTeoQogTKFFYtRgy47 X-IronPort-AV: E=Sophos;i="4.95,692,1384300800"; d="scan'208,217";a="3245242" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 21 Jan 2014 00:00:43 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0L00hLf018854; Tue, 21 Jan 2014 00:00:43 GMT Message-ID: <52DDB8AB.10609@cisco.com> Date: Tue, 21 Jan 2014 01:00:43 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Bierman References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020709080302020805040505" Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 00:00:47 -0000 This is a multi-part message in MIME format. --------------020709080302020805040505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Andy, > Hi, > > > On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise > wrote: > > Hi Kent, >> Hi Benoit, >> >> One comment regarding the charter, current phase item #2 says: >> "Develop a zero touch configuration document, specific the >> NETCONF reverse SSH use case.". I thought we were doing it both >> for NETCONF reverse-SSH and NETCONF reverse-TLS. Is it ok to >> amend this statement to include reverse-TLS too? > Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/ >> >> >> Regarding RFC3535 section 3, the parts RESTCONF doesn't address >> (yet) are: >> >> #5. Support for configuration transactions across a number >> of devices >> would significantly simplify network configuration >> management. >> >> #13. It is important to distinguish between the distribution of >> configurations and the activation of a certain >> configuration. >> Devices should be able to hold multiple configurations. >> >> Is this an issue that needs to be addressed? > From the charter "RESTCONF should not deviate from NETCONF unless > proper justifications is provided and documented." >> > > I this this text is problematic. > The WG is not addressing #5 above at this time. > > #13 requires interpretation. It could mean support for > named configurations and the ability to boot (or switch > at runtime) between them. NETCONF does not support that either. > > IMO this "should not deviate" sentence needs to be replaced. > NETCONF has sessions and operations tuned for session-based management. > It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. > RESTCONF is going to deviate from that. RESTCONF imposes a resource > model on the content and NETCONF does not. I see at http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf, under "**** RESTCONF (Andy)" some discussion about alignment For example: "Mehmet: History: a new WG and a BOF was proposed. It is different from Netconf, but based on Netconf. Keep them aligned. " Which alignment do we speak about here? > > I think the intent is that the impact on a NETCONF server implementation > should be kept at a minimum. No new features can be added that would > break a NETCONF client managing a dual NETCONF/RESTCONF server. > > >> Regarding northbound vs southbound protocols >> and different/competing solutions to managed devices – I don't >> fully understand your concern. How is an application (e.g. an >> NMS) presenting a RESTCONF interface causing a different or >> competing solution? Are you thinking that the requirements >> might differ and, in our attempt to appease the app-folks, we >> somehow harm the solution for devices? I personally don't see >> this as the case; having just re-read the RESTCONF –03 draft, it >> is very much aligned with NETCONF and therefore device-management. > I simply meant that, if RESTCONF would be used as a northbound > protocol, and NETCONF as southbound protocol, the messaging would > have been easier as RESTCONF and NETCONF would not be competent > protocols. > > > > Northbound vs. southbound is a very subjective distinction. > RESTCONF vs. NETCONF is a project-specific engineering > decision about tools, training, and how much device-specific > control the application really needs from the server(s). > IMO, YANG is the real difference maker. RESTCONF is > about getting HTTP app developers to use YANG, rather > than getting NETCONF app developers to use RESTCONF. What is actually the justification for RESTCONF? Do we need RESTCONF for the HTTP tools or for the REST concepts? I could not find any justification/problem statement in draft-bierman-netconf-restconf-03 Regards, Benoit > > > >> >> Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely >> orthogonal to HTTP and that which versions of HTTP it's >> compatible with doesn't need to be called out in the charter. >> That said, you raise a good point that the RESTONF draft should >> be scrubbed so that it's clear that it's not specific to HTTP 1.1. > Barry answered that. We're good. > > Regards, Benoit > >> Thanks, >> Kent >> > > Andy --------------020709080302020805040505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Andy,
Hi,


On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Kent,
Hi Benoit,

One comment regarding the charter, current phase item #2 says:  "Develop a zero touch configuration document, specific the NETCONF reverse SSH use case.".   I thought we were doing it both for NETCONF reverse-SSH and NETCONF reverse-TLS.  Is it ok to amend this statement to include reverse-TLS too?
Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/


Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are:

    #5.  Support for configuration transactions across a number of devices
           would significantly simplify network configuration management.

    #13. It is important to distinguish between the distribution of
             configurations and the activation of a certain configuration.
             Devices should be able to hold multiple configurations.

Is this an issue that needs to be addressed?
From the charter "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented."


I this this text is problematic.
The WG is not addressing #5 above at this time.

#13 requires interpretation. It could mean support for
named configurations and the ability to boot (or switch
at runtime) between them. NETCONF does not support that either.

IMO this "should not deviate" sentence needs to be replaced.
NETCONF has sessions and operations tuned for session-based management.
It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF.
RESTCONF is going to deviate from that. RESTCONF imposes a resource
model on the content and NETCONF does not.
I see at http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf, under "**** RESTCONF (Andy)" some discussion about alignment
For example: "Mehmet: History: a new WG and a BOF was proposed. It is different from Netconf, but based on Netconf. Keep them aligned. "

Which alignment do we speak about here?


I think the intent is that the impact on a NETCONF server implementation
should be kept at a minimum.  No new features can be added that would
break a NETCONF client managing a dual NETCONF/RESTCONF server.


 
Regarding northbound vs southbound protocols and different/competing solutions to managed devices – I don't fully understand your concern.   How is an application (e.g. an NMS) presenting a RESTCONF interface causing a different or competing solution?   Are you thinking that the requirements might differ and, in our attempt to appease the app-folks, we somehow harm the solution for devices?   I personally don't see this as the case; having just re-read the RESTCONF –03 draft, it is very much aligned with NETCONF and therefore device-management.
I simply meant that, if RESTCONF would be used as a northbound protocol, and NETCONF as southbound protocol, the messaging would have been easier as RESTCONF and NETCONF would not be competent protocols.


Northbound vs. southbound is a very subjective distinction.
RESTCONF vs. NETCONF is a project-specific engineering
decision about tools, training, and how much device-specific
control the application really needs from the server(s).
IMO, YANG is the real difference maker. RESTCONF is
about getting HTTP app developers to use YANG, rather
than getting NETCONF app developers to use RESTCONF.
What is actually the justification for RESTCONF?
Do we need RESTCONF for the HTTP tools or for the REST concepts?
I could not find any justification/problem statement in draft-bierman-netconf-restconf-03

Regards, Benoit




Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal to HTTP and that which versions of HTTP it's compatible with doesn't need to be called out in the charter.  That said, you raise a good point that the RESTONF draft should be scrubbed so that it's clear that it's not specific to HTTP 1.1.
Barry answered that. We're good.

Regards, Benoit
Thanks,
Kent


Andy
 

--------------020709080302020805040505-- From andy@yumaworks.com Mon Jan 20 16:56:20 2014 Return-Path: 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 C14001A028A for ; Mon, 20 Jan 2014 16:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xI9siq7ZfBFa for ; Mon, 20 Jan 2014 16:56:18 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id C46471A0267 for ; Mon, 20 Jan 2014 16:56:17 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so6014203qaq.25 for ; Mon, 20 Jan 2014 16:56:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Axjh0NIb2jC6dSW6W6iRM3Zm9SINMb6VuO2PsEYhDBM=; b=Ifu81nZ+bju95LvD2J+U7DS7M1FLCR4vhb4DRiJ0FqNCdsCnp39+YIudctfR37uyaJ a2bXxzdEK4iYuWERCXzJtrND/xx29GyNiGmg80TCL8P1wXEjWuBso3sfs2cn+hTBajW7 Z8LjrG0MpRsRK9/Cz3cAnfX8RmdSuhNuaM9IcaNf6TTJfBaC5k8AnfQWXcr0novHD1Qd EH+oy9zeRmcvi1WmWBtP/rXLG5oc8ijFDfgq6nh7E+ise0nfKy5w9dQAfhxCjLR6ktzA Diz4eI7De7HT6HSKFnD5wGzH0jqoh4IqQcY1QGVfg4yNSv1dzQ7I5lDacA5PaC2FgNhT gNBg== X-Gm-Message-State: ALoCoQkjtMz/+dDxZQlhIJuv7h4FpFRIstQ11YRhJCEMejfMg/7Rphhmzf5zOgrArXe/3tTKtCwM MIME-Version: 1.0 X-Received: by 10.140.85.179 with SMTP id n48mr30517903qgd.91.1390265777482; Mon, 20 Jan 2014 16:56:17 -0800 (PST) Received: by 10.140.48.75 with HTTP; Mon, 20 Jan 2014 16:56:17 -0800 (PST) In-Reply-To: <52DDB8AB.10609@cisco.com> References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> Date: Mon, 20 Jan 2014 16:56:17 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c133decf981f04f070796d Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 00:56:21 -0000 --001a11c133decf981f04f070796d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: > Andy, > > Hi, > > > On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise wrote: > >> Hi Kent, >> >> Hi Benoit, >> >> One comment regarding the charter, current phase item #2 says: >> "Develop a zero touch configuration document, specific the NETCONF >> reverse SSH use case.". I thought we were doing it both for NETCONF >> reverse-SSH and NETCONF reverse-TLS. Is it ok to amend this statement t= o >> include reverse-TLS too? >> >> Updated. See http://datatracker.ietf.org/doc/charter-ietf-netconf/ >> >> >> >> Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) >> are: >> >> #5. Support for configuration transactions across a number of >> devices >> would significantly simplify network configuration management= . >> >> #13. It is important to distinguish between the distribution of >> configurations and the activation of a certain >> configuration. >> Devices should be able to hold multiple configurations. >> >> Is this an issue that needs to be addressed? >> >> From the charter "RESTCONF should not deviate from NETCONF unless proper >> justifications is provided and documented." >> >> >> > I this this text is problematic. > The WG is not addressing #5 above at this time. > > #13 requires interpretation. It could mean support for > named configurations and the ability to boot (or switch > at runtime) between them. NETCONF does not support that either. > > IMO this "should not deviate" sentence needs to be replaced. > NETCONF has sessions and operations tuned for session-based management. > It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. > RESTCONF is going to deviate from that. RESTCONF imposes a resource > model on the content and NETCONF does not. > > I see at http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf, > under "**** RESTCONF (Andy)" some discussion about alignment > For example: "Mehmet: History: a new WG and a BOF was proposed. It is > different from Netconf, but based on Netconf. Keep them aligned. " > > Which alignment do we speak about here? > The term "alignment" was used only generically in meetings so far. My comment was on the phrase in the charter "RESTCONF should not deviate from NETCONF". What does that mean? What would constitute a deviation from NETCONF that should be avoided? > > > I think the intent is that the impact on a NETCONF server implementation > should be kept at a minimum. No new features can be added that would > break a NETCONF client managing a dual NETCONF/RESTCONF server. > > > > >> Regarding northbound vs southbound protocols and different/competing >> solutions to managed devices =96 I don't fully understand your concern. = How >> is an application (e.g. an NMS) presenting a RESTCONF interface causing = a >> different or competing solution? Are you thinking that the requirement= s >> might differ and, in our attempt to appease the app-folks, we somehow ha= rm >> the solution for devices? I personally don't see this as the case; hav= ing >> just re-read the RESTCONF =9603 draft, it is very much aligned with NETC= ONF >> and therefore device-management. >> >> I simply meant that, if RESTCONF would be used as a northbound protocol, >> and NETCONF as southbound protocol, the messaging would have been easier= as >> RESTCONF and NETCONF would not be competent protocols. >> > > > Northbound vs. southbound is a very subjective distinction. > RESTCONF vs. NETCONF is a project-specific engineering > decision about tools, training, and how much device-specific > control the application really needs from the server(s). > IMO, YANG is the real difference maker. RESTCONF is > about getting HTTP app developers to use YANG, rather > than getting NETCONF app developers to use RESTCONF. > > What is actually the justification for RESTCONF? > Do we need RESTCONF for the HTTP tools or for the REST concepts? > I could not find any justification/problem statement in > draft-bierman-netconf-restconf-03 > There is text in sec. 1. If you want to suggest a rewrite, that's fine. HTTP tools that use REST concepts are needed. > > > Regards, Benoit > Andy > > > > >> Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely >> orthogonal to HTTP and that which versions of HTTP it's compatible with >> doesn't need to be called out in the charter. That said, you raise a go= od >> point that the RESTONF draft should be scrubbed so that it's clear that >> it's not specific to HTTP 1.1. >> >> Barry answered that. We're good. >> >> Regards, Benoit >> > Thanks, >> Kent >> >> > Andy > > > > --001a11c133decf981f04f070796d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
=20 =20 =20
Andy,
=20
Hi,


On Tue, Jan 14, 2014 at 8:44 AM, Benoit Claise <bclaise@cisco.com> wrote:
Hi Kent,
Hi Benoit,

One comment regarding the charter, current phase item #2 says: =A0"Develop a zero touch configurati= on document, specific the NETCONF reverse=A0SSH use case.". =A0 I thought we were doing it both for NETCONF reverse-SSH and NETCONF reverse-TLS. =A0Is it ok to amend this statement to include reverse-TLS too?
Updated. See http://datatracker.ietf.org/doc/chart= er-ietf-netconf/


Regarding RFC3535 section 3, the parts RESTCONF doesn't address (yet) are:

=A0 =A0 #5. =A0Support for configuration transacti= ons across a number of devices
=A0 =A0 =A0 =A0 =A0 =A0would significantly simplif= y network configuration management.

=A0 =A0 #13. It is important to distinguish between the distribution of
=A0 =A0 =A0 =A0 =A0 =A0 =A0configurations and the = activation of a certain configuration.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Devices should be able = to hold multiple configurations.

Is this an issue that needs to be addressed?
From the charter "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented."


I this this text is problematic.
The WG is not addressing #5 above at this time.

#13 requires interpretation. It could mean support for
named configurations and the ability to boot (or switch
at runtime) between them. NETCONF does not support that either.

IMO this "should not deviate" sentence needs to = be replaced.
NETCONF has sessions and operations tuned for session-based management.
It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF.
RESTCONF is going to deviate from that. RESTCONF imposes a resource
model on the content and NETCONF does not.
I see at http://www.ietf.org/proceedings/88/minutes/minutes-88-= netconf, under "**** RESTCONF (Andy)" some discussion about alignment
For example: "Mehmet: History: a new WG and a BOF was proposed. It is different from Netconf, but based on Netconf. Keep them aligned. "

Which alignment do we speak about here?

=

The term "alignment" was used only gene= rically in meetings so far.
My comment was on the phrase in the c= harter=A0
"RESTCONF should not deviate from NETCONF".
What d= oes that mean? =A0What would constitute a deviation from NETCONF
= that should be avoided?


=A0


I think the intent is that the impact on a NETCONF server implementation
should be kept at a minimum. =A0No new features can be added that would
break a NETCONF client managing a dual NETCONF/RESTCONF server.


=A0
Regarding northbound vs southbound protocols and=A0different/competing solutions to managed devices =96 I don't fully understand your concern. =A0 How = is an application (e.g. an NMS) presenting a RESTCONF interface causing a different or competing solution? =A0 Are you thinking that the requirements might differ and, in our attempt to appease the app-folks, we somehow harm the solution for devices? =A0 I personally don't see this as the case; having just re-read the RESTCONF =9603 draft, it is very much aligned with NETCONF and therefore device-management.
I simply meant that, if RESTCONF would be used as a northbound protocol, and NETCONF as southbound protocol, the messaging would have been easier as RESTCONF and NETCONF would not be competent protocols.


Northbound vs. southbound is a very subjective distinction.
RESTCONF vs. NETCONF is a project-specific engineering
decision about tools, training, and how much device-specific
control the application really needs from the server(s).
IMO, YANG is the real difference maker. RESTCONF is
about getting HTTP app developers to use YANG, rather
than getting NETCONF app developers to use RESTCONF.
What is actually the justification for RESTCONF?
Do we need RESTCONF for the HTTP tools or for the REST concepts?
I could not find any justification/problem statement in draft-bierman-netconf-restconf-03

There is text in sec. 1.
If you want to suggest a rewrite, t= hat's fine.
HTTP tools that use REST concepts are needed.

=A0


Regards, Benoit


Andy

=A0




Regarding HTTP1.1 vs 2.0, I believe that RESTCONF is completely orthogonal to HTTP and that which versions of HTTP it's compatible with doesn't n= eed to be called out in the charter. =A0That said, you raise a good point that the RESTONF draft should be scrubbed so that it's clear that it's not speci= fic to HTTP 1.1.
Barry answered that. We're good.

Regards, Benoit
Thanks,
Kent


Andy
=A0


--001a11c133decf981f04f070796d-- From mbj@tail-f.com Mon Jan 20 23:27:41 2014 Return-Path: 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 A7BCB1A0053 for ; Mon, 20 Jan 2014 23:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 0-axOq9iqFvc for ; Mon, 20 Jan 2014 23:27:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBA51A0042 for ; Mon, 20 Jan 2014 23:27:39 -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 1DC80240C3FF; Tue, 21 Jan 2014 08:27:38 +0100 (CET) Date: Tue, 21 Jan 2014 08:27:37 +0100 (CET) Message-Id: <20140121.082737.318089610049057078.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <52DDB8AB.10609@cisco.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 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 07:27:41 -0000 Andy Bierman wrote: > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: > > What is actually the justification for RESTCONF? [...] > HTTP tools that use REST concepts are needed. I am not sure what this means. IMO, RESTCONF in its current shape really is about HTTP, not REST concepts. /martin From wdec.ietf@gmail.com Tue Jan 21 04:21:17 2014 Return-Path: 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 3390F1A00BF for ; Tue, 21 Jan 2014 04:21:17 -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 QzpEwnff_4FO for ; Tue, 21 Jan 2014 04:21:15 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 794471A00BD for ; Tue, 21 Jan 2014 04:21:15 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp16so3324721pbb.20 for ; Tue, 21 Jan 2014 04:21:15 -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=aX35hJzwzWzBskIPyDyvSYzl6H6WrRarJ/DMpbagiAM=; b=seILMLF25dj1F2CRlD0RclhWWpHva/bUs0ZhNr6yCBeyO/eGTcKgCjiXFVP4DPW8Bz 1DpgWq1JN/pkF/46mf1onlfwccOnuih3IYWj69jlQ7M2Tmk59PTnm3hnox8Jp1CsvzqM IIKxmbGXz0e+WoIZrF0EauU3KwomJP1dHBUkokyskHqNW0WCXezFDpUaB1wlojH+sKfp Y9rh24Wjb42wD1Ut1WVYJafBHudydgjQX2g41+h1KV1R87UyffBxV4lKns0EcZj7+bLn xcMIAFlXWmT2ECzVgBCULXc6xcz5q9MBYd+9LMHAhVzHViDIm4eLn5hqPvJaLJjpMeeC 0Z3Q== MIME-Version: 1.0 X-Received: by 10.67.5.233 with SMTP id cp9mr8794485pad.147.1390306875341; Tue, 21 Jan 2014 04:21:15 -0800 (PST) Received: by 10.70.1.70 with HTTP; Tue, 21 Jan 2014 04:21:15 -0800 (PST) In-Reply-To: <20140121.082737.318089610049057078.mbj@tail-f.com> References: <52DDB8AB.10609@cisco.com> <20140121.082737.318089610049057078.mbj@tail-f.com> Date: Tue, 21 Jan 2014 13:21:15 +0100 Message-ID: From: Wojciech Dec To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:21:17 -0000 On 21 January 2014 08:27, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: >> > What is actually the justification for RESTCONF? > > [...] > >> HTTP tools that use REST concepts are needed. > > I am not sure what this means. IMO, RESTCONF in its current shape > really is about HTTP, not REST concepts. +1 /Woj. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Tue Jan 21 04:25:58 2014 Return-Path: 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 6990F1A00C8 for ; Tue, 21 Jan 2014 04:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 3EqMEWJ2YcQg for ; Tue, 21 Jan 2014 04:25:56 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD4F1A00BD for ; Tue, 21 Jan 2014 04:25:56 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7F3020071; Tue, 21 Jan 2014 13:25:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 54PIcC9lYgpb; Tue, 21 Jan 2014 13:25:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3555E2006F; Tue, 21 Jan 2014 13:25:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B90E22AC2E93; Tue, 21 Jan 2014 13:25:52 +0100 (CET) Date: Tue, 21 Jan 2014 13:25:52 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140121122552.GA47786@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <52DDB8AB.10609@cisco.com> <20140121.082737.318089610049057078.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140121.082737.318089610049057078.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:25:58 -0000 On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: > > > What is actually the justification for RESTCONF? > > [...] > > > HTTP tools that use REST concepts are needed. > > I am not sure what this means. IMO, RESTCONF in its current shape > really is about HTTP, not REST concepts. So, is this a bug or a feature? Where do you think does RESTCONF depart from REST concepts? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 21 04:33:19 2014 Return-Path: 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 D85B51A00DD for ; Tue, 21 Jan 2014 04:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 5KFogYx45NS4 for ; Tue, 21 Jan 2014 04:33:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D877B1A00F4 for ; Tue, 21 Jan 2014 04:33:16 -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 20D8F37C122; Tue, 21 Jan 2014 13:33:16 +0100 (CET) Date: Tue, 21 Jan 2014 13:33:15 +0100 (CET) Message-Id: <20140121.133315.718004433548356051.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140121122552.GA47786@elstar.local> References: <20140121.082737.318089610049057078.mbj@tail-f.com> <20140121122552.GA47786@elstar.local> 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 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:33:20 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: > > Andy Bierman wrote: > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: > > > > What is actually the justification for RESTCONF? > > > > [...] > > > > > HTTP tools that use REST concepts are needed. > > > > I am not sure what this means. IMO, RESTCONF in its current shape > > really is about HTTP, not REST concepts. > > So, is this a bug or a feature? Where do you think does RESTCONF > depart from REST concepts? Feature! See section 1.2 of the draft. /martin From j.schoenwaelder@jacobs-university.de Tue Jan 21 04:53:16 2014 Return-Path: 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 9E62D1A00D8 for ; Tue, 21 Jan 2014 04:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 Akgd5SRt2wk7 for ; Tue, 21 Jan 2014 04:53:15 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0412D1A00E9 for ; Tue, 21 Jan 2014 04:53:14 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE9FE20071; Tue, 21 Jan 2014 13:53:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qjaVrIZCQn5w; Tue, 21 Jan 2014 13:53:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2705F20064; Tue, 21 Jan 2014 13:53:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 916152AC2F89; Tue, 21 Jan 2014 13:53:10 +0100 (CET) Date: Tue, 21 Jan 2014 13:53:10 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140121125310.GB47786@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <20140121.082737.318089610049057078.mbj@tail-f.com> <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140121.133315.718004433548356051.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 12:53:16 -0000 On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: > > > Andy Bierman wrote: > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise wrote: > > > > > What is actually the justification for RESTCONF? > > > > > > [...] > > > > > > > HTTP tools that use REST concepts are needed. > > > > > > I am not sure what this means. IMO, RESTCONF in its current shape > > > really is about HTTP, not REST concepts. > > > > So, is this a bug or a feature? Where do you think does RESTCONF > > depart from REST concepts? > > Feature! See section 1.2 of the draft. > You may want to provide a pointer to what exactly you mean with HATEOAS. I think it is useful to distinguish between having schema controlled 'resources' you manipulate and schema controlled URI namespaces. It seems is arguing to be cautious with the later. Will RESTCONF follow the recommendations given in this ID or not? I understand that you do not want excessive URI discovery overhead. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 21 05:20:40 2014 Return-Path: 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 C39D31A00E0 for ; Tue, 21 Jan 2014 05:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 jCOlGOY7g-oc for ; Tue, 21 Jan 2014 05:20:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5E31A00CF for ; Tue, 21 Jan 2014 05:20:39 -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 549DE240C331; Tue, 21 Jan 2014 14:20:38 +0100 (CET) Date: Tue, 21 Jan 2014 14:20:38 +0100 (CET) Message-Id: <20140121.142038.1028614918738288551.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140121125310.GB47786@elstar.local> References: <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> <20140121125310.GB47786@elstar.local> 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 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:20:41 -0000 Juergen Schoenwaelder wrote: > It seems is arguing to be > cautious with the later. Will RESTCONF follow the recommendations > given in this ID or not? > > I understand that you do not want excessive URI discovery overhead. It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires us to use URI discovery. If this is a firm requirement on a protocol developed in the IETF, I think we should not do RESTCONF at all. The whole point of RESTCONF is to have a "quick" and "simple" interface. URI discovery puts an enormous burden on the client. Maybe it would be a good idea to get this design "approved" before we spend more time on this protocol. /martin From j.schoenwaelder@jacobs-university.de Tue Jan 21 05:32:05 2014 Return-Path: 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 6A74F1A00D3 for ; Tue, 21 Jan 2014 05:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 trFXa9ef2oDH for ; Tue, 21 Jan 2014 05:32:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 913CA1A00CE for ; Tue, 21 Jan 2014 05:32:02 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 417372008B; Tue, 21 Jan 2014 14:32:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uQrVAs49FtSt; Tue, 21 Jan 2014 14:32:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A610C20078; Tue, 21 Jan 2014 14:32:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C2DD52AC3283; Tue, 21 Jan 2014 14:31:59 +0100 (CET) Date: Tue, 21 Jan 2014 14:31:59 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140121133159.GA48038@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140121.142038.1028614918738288551.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:32:05 -0000 On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > It seems is arguing to be > > cautious with the later. Will RESTCONF follow the recommendations > > given in this ID or not? > > > > I understand that you do not want excessive URI discovery overhead. > > It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires > us to use URI discovery. If this is a firm requirement on a protocol > developed in the IETF, I think we should not do RESTCONF at all. The > whole point of RESTCONF is to have a "quick" and "simple" interface. > URI discovery puts an enormous burden on the client. > > Maybe it would be a good idea to get this design "approved" before we > spend more time on this protocol. > I believe what is indeed called for here is an early review of this work by apps area experts. It is not about 'approving' this work, it is about making sure that we get good technical advice on the design of the protocol (and of course to avoid late surprises). In other words, I think we should try to find ways to work in a positive and constructive spirit with apps area experts here. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jan 21 05:41:32 2014 Return-Path: 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 BFF921A00E8 for ; Tue, 21 Jan 2014 05:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 hUEQ3AeWrGxq for ; Tue, 21 Jan 2014 05:41:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1CE1A00D3 for ; Tue, 21 Jan 2014 05:41:31 -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 9B4AF240C36C; Tue, 21 Jan 2014 14:41:30 +0100 (CET) Date: Tue, 21 Jan 2014 14:41:30 +0100 (CET) Message-Id: <20140121.144130.263996160270161152.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140121133159.GA48038@elstar.local> References: <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> <20140121133159.GA48038@elstar.local> 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 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 13:41:33 -0000 Juergen Schoenwaelder wrote: > On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > It seems is arguing to be > > > cautious with the later. Will RESTCONF follow the recommendations > > > given in this ID or not? > > > > > > I understand that you do not want excessive URI discovery overhead. > > > > It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires > > us to use URI discovery. If this is a firm requirement on a protocol > > developed in the IETF, I think we should not do RESTCONF at all. The > > whole point of RESTCONF is to have a "quick" and "simple" interface. > > URI discovery puts an enormous burden on the client. > > > > Maybe it would be a good idea to get this design "approved" before we > > spend more time on this protocol. > > > > I believe what is indeed called for here is an early review of this > work by apps area experts. It is not about 'approving' this work, it > is about making sure that we get good technical advice on the design > of the protocol (and of course to avoid late surprises). In other > words, I think we should try to find ways to work in a positive and > constructive spirit with apps area experts here. Absolutely. How do we get this review? Do we do that *before* charter update? /martin From j.schoenwaelder@jacobs-university.de Tue Jan 21 06:00:10 2014 Return-Path: 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 BBE641A00CE for ; Tue, 21 Jan 2014 06:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 gR5kWtQCsynQ for ; Tue, 21 Jan 2014 06:00:09 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 33D281A00DB for ; Tue, 21 Jan 2014 06:00:09 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BB3532007D; Tue, 21 Jan 2014 15:00:08 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tC2Sf2QNzKVg; Tue, 21 Jan 2014 15:00:08 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F26F2007B; Tue, 21 Jan 2014 15:00:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4089F2AC33AF; Tue, 21 Jan 2014 15:00:06 +0100 (CET) Date: Tue, 21 Jan 2014 15:00:06 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140121140006.GB48100@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> <20140121133159.GA48038@elstar.local> <20140121.144130.263996160270161152.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140121.144130.263996160270161152.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:00:10 -0000 On Tue, Jan 21, 2014 at 02:41:30PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > It seems is arguing to be > > > > cautious with the later. Will RESTCONF follow the recommendations > > > > given in this ID or not? > > > > > > > > I understand that you do not want excessive URI discovery overhead. > > > > > > It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires > > > us to use URI discovery. If this is a firm requirement on a protocol > > > developed in the IETF, I think we should not do RESTCONF at all. The > > > whole point of RESTCONF is to have a "quick" and "simple" interface. > > > URI discovery puts an enormous burden on the client. > > > > > > Maybe it would be a good idea to get this design "approved" before we > > > spend more time on this protocol. > > > > > > > I believe what is indeed called for here is an early review of this > > work by apps area experts. It is not about 'approving' this work, it > > is about making sure that we get good technical advice on the design > > of the protocol (and of course to avoid late surprises). In other > > words, I think we should try to find ways to work in a positive and > > constructive spirit with apps area experts here. > > Absolutely. How do we get this review? Do we do that *before* > charter update? This is something for the chairs to figure out. There is also the formal role of a 'technical advisor'. But what we need is a serious technical review, establishing a 'technical advisor' may be a means for this but there might be other ways of getting the input. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Tue Jan 21 06:52:01 2014 Return-Path: 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 20C641A0160 for ; Tue, 21 Jan 2014 06:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 G9aHYyUGnsPE for ; Tue, 21 Jan 2014 06:52:00 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id CCF901A015F for ; Tue, 21 Jan 2014 06:51:59 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5cgG-0004Zt-Uw; Tue, 21 Jan 2014 15:51:58 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5cgG-0000Qo-S9; Tue, 21 Jan 2014 15:51:56 +0100 Message-ID: <52DE898D.6080500@bwijnen.net> Date: Tue, 21 Jan 2014 15:51:57 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Martin Bjorklund , andy@yumaworks.com, netconf@ietf.org References: <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> <20140121133159.GA48038@elstar.local> <20140121.144130.263996160270161152.mbj@tail-f.com> <20140121140006.GB48100@elstar.local> In-Reply-To: <20140121140006.GB48100@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e178ee0f9fe0c052566428ea313ba838 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 14:52:01 -0000 I am sure we can ask for an early technical review from the APSS area. Let us do that as soon as we have the charter approved and our forst WG document oin this space. Bert (my opinion, I have not checked with my co-chair yet) On 21/01/14 15:00, Juergen Schoenwaelder wrote: > On Tue, Jan 21, 2014 at 02:41:30PM +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> It seems is arguing to be >>>>> cautious with the later. Will RESTCONF follow the recommendations >>>>> given in this ID or not? >>>>> >>>>> I understand that you do not want excessive URI discovery overhead. >>>> >>>> It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 requires >>>> us to use URI discovery. If this is a firm requirement on a protocol >>>> developed in the IETF, I think we should not do RESTCONF at all. The >>>> whole point of RESTCONF is to have a "quick" and "simple" interface. >>>> URI discovery puts an enormous burden on the client. >>>> >>>> Maybe it would be a good idea to get this design "approved" before we >>>> spend more time on this protocol. >>>> >>> >>> I believe what is indeed called for here is an early review of this >>> work by apps area experts. It is not about 'approving' this work, it >>> is about making sure that we get good technical advice on the design >>> of the protocol (and of course to avoid late surprises). In other >>> words, I think we should try to find ways to work in a positive and >>> constructive spirit with apps area experts here. >> >> Absolutely. How do we get this review? Do we do that *before* >> charter update? > > This is something for the chairs to figure out. There is also the > formal role of a 'technical advisor'. But what we need is a serious > technical review, establishing a 'technical advisor' may be a means > for this but there might be other ways of getting the input. > > /js > > From andy@yumaworks.com Tue Jan 21 07:10:30 2014 Return-Path: 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 4B7051A0110 for ; Tue, 21 Jan 2014 07:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5mBZptRCnzaC for ; Tue, 21 Jan 2014 07:10:28 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 111701A010D for ; Tue, 21 Jan 2014 07:10:27 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id s1so2933843qeb.40 for ; Tue, 21 Jan 2014 07:10:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=VjxMnSOBGB9cPmMuuzr0td7F8JOxi1VLx9nfkmmmk4c=; b=Rx8CjYSsdMdPLPUW6cWjhU8uKgXYRN17xibiTQdFOn2MezdcK2FcAGVfuMNdfqZZOS QmIFE/+SglW8+YUjhoM7oyefGnTBf2gOiYuMweYCmruTgV9RMJywZHASYBffPVEvcT/8 S7+SV7uzVMdhWYRV0DNYEtyrI3wRRj7ifIOS4uKgBx/Y8+38W7OvftPmmGLYskGNifZB CqYqU9IOseppj0jPUhrY+u4sMFFDIc9ZB6rmijzsJFSoJ0HS7IqQL2SSGr3Wy64otEm5 4kY7wYQPktaTtRS/IcTrQ7IujJccDz5abf2//KGqR0cbsCpVNMJUz1//Ev4z9I9jwiC5 I+sQ== X-Gm-Message-State: ALoCoQn/YdeLSGEcsALy2Qe8ATtBhLqnm4h1JO3MOYL+z5fqgwTDTbrCoqsb62qgO12GoSX73Gm+ MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr21130483qgx.18.1390317027771; Tue, 21 Jan 2014 07:10:27 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 21 Jan 2014 07:10:27 -0800 (PST) In-Reply-To: <20140121125310.GB47786@elstar.local> References: <20140121.082737.318089610049057078.mbj@tail-f.com> <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> <20140121125310.GB47786@elstar.local> Date: Tue, 21 Jan 2014 07:10:27 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman , Netconf Content-Type: multipart/alternative; boundary=001a11c0043490f51004f07c6811 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 15:10:30 -0000 --001a11c0043490f51004f07c6811 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise > wrote: > > > > > > What is actually the justification for RESTCONF? > > > > > > > > [...] > > > > > > > > > HTTP tools that use REST concepts are needed. > > > > > > > > I am not sure what this means. IMO, RESTCONF in its current shape > > > > really is about HTTP, not REST concepts. > > > > > > So, is this a bug or a feature? Where do you think does RESTCONF > > > depart from REST concepts? > > > > Feature! See section 1.2 of the draft. > > > > You may want to provide a pointer to what exactly you mean with > HATEOAS. I think it is useful to distinguish between having schema > controlled 'resources' you manipulate and schema controlled URI > namespaces. > > It seems is arguing to be > cautious with the later. Will RESTCONF follow the recommendations > given in this ID or not? > > I understand that you do not want excessive URI discovery overhead. > > It depends on the interpretation of this text in sec 2.3: Scheme definitions define the presence, format, and semantics of a path component in URIs; all other specifications MUST NOT constrain, define structure or semantics for any path component. IMO RESTCONF does not really impose structure -- it maps arbitrary URI paths to YANG statements. For any possible URI value, a YANG module could be defined which would map to the arbitrary URI. The RESTCONF server implementation only supports a subset of all possible URIs, just like a regular WEB server. Ad-hoc APIs (e.g. OpenStack) put constraints on the structure of a particular URI when attempting to accomplish a specific task. RESTCONF is just documenting data model constraints with YANG instead of ad-hoc examples. HATEOAS and URI discovery does not scale to the level of complexity that our customers need to model and manage networking devices. It is impossible for the applications to do useful work with these complex models by discovering them on the fly. Instead, the API contract is carefully documented in YANG, and applications are designed and coded in advance to work with specific YANG modules. /js > Andy --001a11c0043490f51004f07c6811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund= wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote:=
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise <bclaise@cisco.com> wrote:
> > > > > What is actually the justification for RESTCONF? > > >
> > > [...]
> > >
> > > > HTTP tools that use REST concepts are needed.
> > >
> > > I am not sure what this means. =A0IMO, RESTCONF in its curre= nt shape
> > > really is about HTTP, not REST concepts.
> >
> > So, is this a bug or a feature? Where do you think does RESTCONF<= br> > > depart from REST concepts?
>
> Feature! =A0See section 1.2 of the draft.
>

You may want to provide a pointer to what exactly you mean with
HATEOAS. I think it is useful to distinguish between having schema
controlled 'resources' you manipulate and schema controlled URI
namespaces.

It seems <draft-ietf-appsawg-uri-get-off-my-lawn-00> is arguing to be=
cautious with the later. Will RESTCONF follow the recommendations
given in this ID or not?

I understand that you do not want excessive URI discovery overhead.


It depends on the interpretation of this text in sec 2.3:<= /div>
   Scheme definitions define the presence, format, and semantics of a
   path component in URIs; all other specifications MUST NOT constrain,
   define structure or semantics for any path component.

IMO RESTCONF does not really impose structu= re -- it maps arbitrary URI paths to
YANG statements. =A0For any = possible URI value, a YANG module could be
defined which would ma= p to the arbitrary URI. =A0The RESTCONF server implementation
only supports a subset of all possible URIs, just like a regular WEB s= erver.

Ad-hoc APIs (e.g. OpenStack) put constraint= s on the structure of a particular URI
when attempting to accompl= ish a specific task. =A0RESTCONF is just documenting
data model constraints with YANG instead of ad-hoc examples.

HATEOAS and URI discovery does not scale to the level of co= mplexity that
our customers need to model and manage networking d= evices. =A0It is impossible
for the applications to do useful work with these complex models by di= scovering
them on the fly. =A0Instead, the API contract is carefu= lly documented in YANG,
and applications are designed and coded i= n advance to work with specific
YANG modules.


/js

Andy
=A0
--001a11c0043490f51004f07c6811-- From alex@cisco.com Tue Jan 21 08:39:41 2014 Return-Path: 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 9414D1A019A for ; Tue, 21 Jan 2014 08:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 R4hQZ-pHFxRw for ; Tue, 21 Jan 2014 08:39:39 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F3C661A0174 for ; Tue, 21 Jan 2014 08:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3304; q=dns/txt; s=iport; t=1390322379; x=1391531979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1SFRI4gsFNBcPbszjM2rxJSuKfhbTQwFtGuJBmZ1D5w=; b=Ldg+JNeBIIgzbmBNOmwJqWioN0CJXzsa9nnXTKsvtfBz1r9tJgwo4b/j iTXP28LtvfbFfWEAj3OQBBqBXSo1CQO2H9C/t5kAASFQNIofwED7MDaiG EKXDZ4jg/mEJEFg4AF1XQtlG35Xv48PPFHERzs21W+ukFuk+1MBT9Zc0B c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAP2h3lKtJV2c/2dsb2JhbABWA4MLOFa7Hk+BExZ0giUBAQEEAQEBNzEDCwwCAgIBCA4CAQQBAQEKFAkHGwwLFAkIAgQBDQUIh30Nw2gXBI5KIRAHBguDE4EUBKo6gy2CKg X-IronPort-AV: E=Sophos;i="4.95,696,1384300800"; d="scan'208";a="295710398" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jan 2014 16:39:38 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s0LGdbli010219 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 16:39:37 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.159]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 10:39:38 -0600 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHScoCAAAkAnYAAMK97AAABQKwAATu7oIAAAfDOgAANqsuAAApqkAAAAEIDgAAAshIAAAD1kgAAAGV6gAAAVRYAAACmTAAABzmpoA== Date: Tue, 21 Jan 2014 16:39:38 +0000 Message-ID: References: <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> <20140121133159.GA48038@elstar.local> <20140121.144130.263996160270161152.mbj@tail-f.com> <20140121140006.GB48100@elstar.local> In-Reply-To: <20140121140006.GB48100@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 16:39:41 -0000 I agree that a review is a good idea. However, a question is also about th= e goal, and the earlier question whether the incorporation of additional fe= atures and is a bug or a feature. Basically, is the goal is to have the sa= me Netconf operations/ functionality over HTTP , or an interface based on R= eST concepts that is geared towards Web developers. Personally, I find the= value proposition of the latter more compelling than the former. =20 I liked the original charter wording to that regards better (before the add= ition of "RESTCONF should not deviate from NETCONF unless proper justificat= ions is provided and documented"), but either way it will be good to be cle= ar on the goals and who the intended target audience is.=20 --- Alex=20 -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoen= waelder Sent: Tuesday, January 21, 2014 6:00 AM To: Martin Bjorklund Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf Charter update for approval On Tue, Jan 21, 2014 at 02:41:30PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > It seems is arguing=20 > > > > to be cautious with the later. Will RESTCONF follow the=20 > > > > recommendations given in this ID or not? > > > >=20 > > > > I understand that you do not want excessive URI discovery overhead. > > >=20 > > > It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00=20 > > > requires us to use URI discovery. If this is a firm requirement=20 > > > on a protocol developed in the IETF, I think we should not do=20 > > > RESTCONF at all. The whole point of RESTCONF is to have a "quick" an= d "simple" interface. > > > URI discovery puts an enormous burden on the client. > > >=20 > > > Maybe it would be a good idea to get this design "approved" before=20 > > > we spend more time on this protocol. > > >=20 > >=20 > > I believe what is indeed called for here is an early review of this=20 > > work by apps area experts. It is not about 'approving' this work, it=20 > > is about making sure that we get good technical advice on the design=20 > > of the protocol (and of course to avoid late surprises). In other=20 > > words, I think we should try to find ways to work in a positive and=20 > > constructive spirit with apps area experts here. >=20 > Absolutely. How do we get this review? Do we do that *before*=20 > charter update? This is something for the chairs to figure out. There is also the formal ro= le of a 'technical advisor'. But what we need is a serious technical review= , establishing a 'technical advisor' may be a means for this but there migh= t be other ways of getting the input. /js =20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From wdec.ietf@gmail.com Wed Jan 22 01:49:30 2014 Return-Path: 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 7CE5A1A0231 for ; Wed, 22 Jan 2014 01:49:30 -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 Qqun5OehSkbY for ; Wed, 22 Jan 2014 01:49:28 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 565E71A03ED for ; Wed, 22 Jan 2014 01:49:28 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so161701pbc.18 for ; Wed, 22 Jan 2014 01:49:28 -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=YVvWasJrQyvGeW5iWbfKj/xLy8FombtGlj4siJ45QpQ=; b=w4V2ccw6L6ERAh1vTkEL3b/4Spi6FhAsEs8VF04buecQbf/zSyeKEkLqTN8GpNbMXi kyvlCoPuT0WYsH/43duUDfoEmS02Rmk16j05dbh2vAKSP4G9Zn4FKXLjSrY/4JAlairI S7YuOqFjzq7E8VyJ1bZr0lbfO2etpR0aEvz0O7rLkVrYMfCSpTga8UrxzGTRcCu/qS+B tod/OPLpyTfOAxU6zYcEEO0MIdZPr+mHBHUKaDm3lnygc3cf+oL5uz8/2jrK1F6RgTjT 3up4jykm9Ov455Oeiem+DXknI/X3XXNYGVHl2QBxynMM4EDz8KLiX/Z391PevqWQv8PZ MnPQ== MIME-Version: 1.0 X-Received: by 10.66.26.236 with SMTP id o12mr568247pag.15.1390384168022; Wed, 22 Jan 2014 01:49:28 -0800 (PST) Received: by 10.70.1.70 with HTTP; Wed, 22 Jan 2014 01:49:27 -0800 (PST) In-Reply-To: References: <20140121.082737.318089610049057078.mbj@tail-f.com> <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> <20140121125310.GB47786@elstar.local> Date: Wed, 22 Jan 2014 10:49:27 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 09:49:30 -0000 On 21 January 2014 16:10, Andy Bierman wrote: > > > > On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder > wrote: >> >> On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund wrote: >> > Juergen Schoenwaelder wrote: >> > > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: >> > > > Andy Bierman wrote: >> > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise >> > > > > wrote: >> > > > > > What is actually the justification for RESTCONF? >> > > > >> > > > [...] >> > > > >> > > > > HTTP tools that use REST concepts are needed. >> > > > >> > > > I am not sure what this means. IMO, RESTCONF in its current shape >> > > > really is about HTTP, not REST concepts. >> > > >> > > So, is this a bug or a feature? Where do you think does RESTCONF >> > > depart from REST concepts? >> > >> > Feature! See section 1.2 of the draft. >> > >> >> You may want to provide a pointer to what exactly you mean with >> HATEOAS. I think it is useful to distinguish between having schema >> controlled 'resources' you manipulate and schema controlled URI >> namespaces. >> >> It seems is arguing to be >> cautious with the later. Will RESTCONF follow the recommendations >> given in this ID or not? >> >> I understand that you do not want excessive URI discovery overhead. >> > > It depends on the interpretation of this text in sec 2.3: > > Scheme definitions define the presence, format, and semantics of a > path component in URIs; all other specifications MUST NOT constrain, > define structure or semantics for any path component. > > > IMO RESTCONF does not really impose structure -- it maps arbitrary URI paths > to > YANG statements. For any possible URI value, a YANG module could be > defined which would map to the arbitrary URI. The RESTCONF server > implementation > only supports a subset of all possible URIs, just like a regular WEB server. > > Ad-hoc APIs (e.g. OpenStack) put constraints on the structure of a > particular URI > when attempting to accomplish a specific task. RESTCONF is just documenting > data model constraints with YANG instead of ad-hoc examples. > > HATEOAS and URI discovery does not scale to the level of complexity that > our customers need to model and manage networking devices. It is impossible > for the applications to do useful work with these complex models by > discovering > them on the fly. Instead, the API contract is carefully documented in YANG, > and applications are designed and coded in advance to work with specific > YANG modules. Can we have some insight as to how that conclusion has been arrived at? The REST (HATEOAS) pattern is found to work rather well in many large scale web environments, often with much bigger scale than in network device config CRUD... In any case, based on the above, this work perhaps should refrain from using the REST term as intended (and voiced) by the author of REST? http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven HTTPConf may be better... /Wojciech. > > >> /js > > > Andy > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Jan 22 02:45:00 2014 Return-Path: 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 6E1BF1A0429 for ; Wed, 22 Jan 2014 02:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 RWoONy3ErlmC for ; Wed, 22 Jan 2014 02:44:57 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 41E0A1A0427 for ; Wed, 22 Jan 2014 02:44:57 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j5so198381qaq.20 for ; Wed, 22 Jan 2014 02:44:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yTUWC9Z5MOfO1hDxcF102JVAqm1QU+q0YVEe+2YaVJw=; b=Gm4t0EZjMEbhg8wqpmfrnmU/Tg35L3oTkvnV7HE9/5lEaxK0XwO05NMxg0nfjg9LMX cc3OYCoElnczEpY9YllNjjZZE+fmVcnbDlcDDgmCWAndjD/CSG8GSrF0Rp+2y4eFBmLq AJR9+PgEyDSf1xRj5oRB1Ypk3t/AiDj1p0+kEqzsegshp86AGx7QgO+Lwvjd6bL4JxGB kLFsA2TpDk1QQP71foMZEWvCDSO1zyEPpEtlHlqVQI1K8GYkpW56XYw40NjxsgJGzeND 5IOmAYqzhWHaUee2dgGBH9/OcYQ42cjEb38llVazw2zR+bmkTmidLPcTCaOrZOafwLuh tMrg== X-Gm-Message-State: ALoCoQn2OV8WB4rswcn5+PkYULv07tCdMdLmIKgNT3Rd3MYpjvBZo6Dp1LhjbUudFxzkzM6DyLts MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr1076515qgx.18.1390387496502; Wed, 22 Jan 2014 02:44:56 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 02:44:56 -0800 (PST) In-Reply-To: References: <20140121.082737.318089610049057078.mbj@tail-f.com> <20140121122552.GA47786@elstar.local> <20140121.133315.718004433548356051.mbj@tail-f.com> <20140121125310.GB47786@elstar.local> Date: Wed, 22 Jan 2014 02:44:56 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=001a11c00434d4cd3e04f08cd047 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 10:45:00 -0000 --001a11c00434d4cd3e04f08cd047 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 22, 2014 at 1:49 AM, Wojciech Dec wrote: > On 21 January 2014 16:10, Andy Bierman wrote: > > > > > > > > On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder > > wrote: > >> > >> On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund wrote: > >> > Juergen Schoenwaelder wrote: > >> > > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklund wrote: > >> > > > Andy Bierman wrote: > >> > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise < > bclaise@cisco.com> > >> > > > > wrote: > >> > > > > > What is actually the justification for RESTCONF? > >> > > > > >> > > > [...] > >> > > > > >> > > > > HTTP tools that use REST concepts are needed. > >> > > > > >> > > > I am not sure what this means. IMO, RESTCONF in its current shape > >> > > > really is about HTTP, not REST concepts. > >> > > > >> > > So, is this a bug or a feature? Where do you think does RESTCONF > >> > > depart from REST concepts? > >> > > >> > Feature! See section 1.2 of the draft. > >> > > >> > >> You may want to provide a pointer to what exactly you mean with > >> HATEOAS. I think it is useful to distinguish between having schema > >> controlled 'resources' you manipulate and schema controlled URI > >> namespaces. > >> > >> It seems is arguing to be > >> cautious with the later. Will RESTCONF follow the recommendations > >> given in this ID or not? > >> > >> I understand that you do not want excessive URI discovery overhead. > >> > > > > It depends on the interpretation of this text in sec 2.3: > > > > Scheme definitions define the presence, format, and semantics of a > > path component in URIs; all other specifications MUST NOT constrain, > > define structure or semantics for any path component. > > > > > > IMO RESTCONF does not really impose structure -- it maps arbitrary URI > paths > > to > > YANG statements. For any possible URI value, a YANG module could be > > defined which would map to the arbitrary URI. The RESTCONF server > > implementation > > only supports a subset of all possible URIs, just like a regular WEB > server. > > > > Ad-hoc APIs (e.g. OpenStack) put constraints on the structure of a > > particular URI > > when attempting to accomplish a specific task. RESTCONF is just > documenting > > data model constraints with YANG instead of ad-hoc examples. > > > > HATEOAS and URI discovery does not scale to the level of complexity that > > our customers need to model and manage networking devices. It is > impossible > > for the applications to do useful work with these complex models by > > discovering > > them on the fly. Instead, the API contract is carefully documented in > YANG, > > and applications are designed and coded in advance to work with specific > > YANG modules. > > Can we have some insight as to how that conclusion has been arrived > at? The REST (HATEOAS) pattern is found to work rather well in many > large scale web environments, often with much bigger scale than in > network device config CRUD... > In any case, based on the above, this work perhaps should refrain from > using the REST term as intended (and voiced) by the author of REST? > > Simplistic data models may work OK with this approach. It has been pointed out that YANG constraints do not align with trivial classifications (such as all leafs are mandatory and all lists are optional sub-resources). There is no value in pretending that an application that ignores YANG is something worth supporting with this protocol. http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven > > HTTPConf may be better... > I don't care what it is called. > /Wojciech. > Andy > > > > > > >> /js > > > > > > Andy > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c00434d4cd3e04f08cd047 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 22, 2014 at 1:49 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 21 January 2014 16:10, Andy Bierman <<= a href=3D"mailto:andy@yumaworks.com">andy@yumaworks.com> wrote:
>
>
>
> On Tue, Jan 21, 2014 at 4:53 AM, Juergen Schoenwaelder
> <j.schoenwa= elder@jacobs-university.de> wrote:
>>
>> On Tue, Jan 21, 2014 at 01:33:15PM +0100, Martin Bjorklund wrote:<= br> >> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: >> > > On Tue, Jan 21, 2014 at 08:27:37AM +0100, Martin Bjorklu= nd wrote:
>> > > > Andy Bierman <andy@yumaworks.com> wrote:
>> > > > > On Mon, Jan 20, 2014 at 4:00 PM, Benoit Claise= <bclaise@cisco.com>
>> > > > > wrote:
>> > > > > > What is actually the justification for RE= STCONF?
>> > > >
>> > > > [...]
>> > > >
>> > > > > HTTP tools that use REST concepts are needed.<= br> >> > > >
>> > > > I am not sure what this means. =A0IMO, RESTCONF in = its current shape
>> > > > really is about HTTP, not REST concepts.
>> > >
>> > > So, is this a bug or a feature? Where do you think does = RESTCONF
>> > > depart from REST concepts?
>> >
>> > Feature! =A0See section 1.2 of the draft.
>> >
>>
>> You may want to provide a pointer to what exactly you mean with >> HATEOAS. I think it is useful to distinguish between having schema=
>> controlled 'resources' you manipulate and schema controlle= d URI
>> namespaces.
>>
>> It seems <draft-ietf-appsawg-uri-get-off-my-lawn-00> is argu= ing to be
>> cautious with the later. Will RESTCONF follow the recommendations<= br> >> given in this ID or not?
>>
>> I understand that you do not want excessive URI discovery overhead= .
>>
>
> It depends on the interpretation of this text in sec 2.3:
>
> =A0 =A0Scheme definitions define the presence, format, and semantics o= f a
> =A0 =A0path component in URIs; all other specifications MUST NOT const= rain,
> =A0 =A0define structure or semantics for any path component.
>
>
> IMO RESTCONF does not really impose structure -- it maps arbitrary URI= paths
> to
> YANG statements. =A0For any possible URI value, a YANG module could be=
> defined which would map to the arbitrary URI. =A0The RESTCONF server > implementation
> only supports a subset of all possible URIs, just like a regular WEB s= erver.
>
> Ad-hoc APIs (e.g. OpenStack) put constraints on the structure of a
> particular URI
> when attempting to accomplish a specific task. =A0RESTCONF is just doc= umenting
> data model constraints with YANG instead of ad-hoc examples.
>
> HATEOAS and URI discovery does not scale to the level of complexity th= at
> our customers need to model and manage networking devices. =A0It is im= possible
> for the applications to do useful work with these complex models by > discovering
> them on the fly. =A0Instead, the API contract is carefully documented = in YANG,
> and applications are designed and coded in advance to work with specif= ic
> YANG modules.

Can we have some insight as to how that conclusion has been arrived
at? The REST (HATEOAS) pattern is found to work rather well in many
large scale web environments, often with much bigger scale than in
network device config CRUD...
In any case, based on the above, this work perhaps should refrain from
using the REST term as intended (and voiced) by the author of REST?


Simplistic data models may work OK wit= h this approach.
It has been pointed out that YANG constraints do= not
align with trivial classifications (such as all leafs ar= e mandatory
and all lists are optional sub-resources). =A0There is no value
<= div>in pretending that an application that ignores YANG
is someth= ing worth supporting with this protocol.

http://roy.gbiv.com/untangled/2008/rest-apis-must-= be-hypertext-driven

HTTPConf may be better...

I don't c= are what it is called.


/Wojciech.

Andy
=A0

>
>
>> /js
>
>
> Andy
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a11c00434d4cd3e04f08cd047-- From bertietf@bwijnen.net Wed Jan 22 04:44:53 2014 Return-Path: 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 1D32B1A00C2 for ; Wed, 22 Jan 2014 04:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pj9m_mKCdvmz for ; Wed, 22 Jan 2014 04:44:51 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFF61A00A5 for ; Wed, 22 Jan 2014 04:44:51 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1W5xAn-0004w9-MA; Wed, 22 Jan 2014 13:44:50 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1W5xAn-0006vy-IB; Wed, 22 Jan 2014 13:44:49 +0100 Message-ID: <52DFBD41.4040208@bwijnen.net> Date: Wed, 22 Jan 2014 13:44:49 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Bierman , Benoit Claise References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd438c30073f685b3e71763829076220cd2 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 12:44:53 -0000 Inline On 21/01/14 01:56, Andy Bierman wrote: > IMO this "should not deviate" sentence needs to be replaced. > NETCONF has sessions and operations tuned for session-based management. > It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. > RESTCONF is going to deviate from that. RESTCONF imposes a resource > model on the content and NETCONF does not. Andy, the example you give here is easy to defend. I see it as an improvement and not so much as a deviation. But even if we (anyone) see(s) it as a deviation, then I think it is easy enough to point it out and justify it. So I see no issue with the text as in the latest charter proposal. The chairs and AD agree that this is not an issue if put into the charter. It avoids controversial discussion in the future but simplifies further decisions I believe we have WG consensus to move forward and get the charter approved by IESG. Bert From mehmet.ersue@nsn.com Wed Jan 22 05:23:07 2014 Return-Path: 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 E12FA1A00FC for ; Wed, 22 Jan 2014 05:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 IT4L59PpFbK8 for ; Wed, 22 Jan 2014 05:23:04 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B074E1A00DA for ; Wed, 22 Jan 2014 05:23:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s0MDN1xm012125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2014 14:23:01 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s0MDMxnu020820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jan 2014 14:22:59 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 22 Jan 2014 14:22:59 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Wed, 22 Jan 2014 14:22:59 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , Martin Bjorklund , "andy@yumaworks.com" , "netconf@ietf.org" Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: AQHPFrhaFRaHzhL1TkWz6TzvaCZ9xpqQpOcA Date: Wed, 22 Jan 2014 13:22:58 +0000 Message-ID: References: <20140121125310.GB47786@elstar.local> <20140121.142038.1028614918738288551.mbj@tail-f.com> <20140121133159.GA48038@elstar.local> <20140121.144130.263996160270161152.mbj@tail-f.com> <20140121140006.GB48100@elstar.local> <52DE898D.6080500@bwijnen.net> In-Reply-To: <52DE898D.6080500@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2903 X-purgate-ID: 151667::1390396981-000025D0-D1F3D28E/0-0/0-0 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:23:08 -0000 One of the solutions we discussed in Vancouver was to invite an APPS person= as co-author for the RESTCONF draft, which would be indeed very useful for= the development. Cheers,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Bert > Wijnen (IETF) > Sent: Tuesday, January 21, 2014 3:52 PM > To: Martin Bjorklund; andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] Netconf Charter update for approval >=20 > I am sure we can ask for an early technical review from the APSS > area. Let us do that as soon as we have the charter approved and > our forst WG document oin this space. >=20 > Bert (my opinion, I have not checked with my co-chair yet) >=20 > On 21/01/14 15:00, Juergen Schoenwaelder wrote: > > On Tue, Jan 21, 2014 at 02:41:30PM +0100, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: > >>> On Tue, Jan 21, 2014 at 02:20:38PM +0100, Martin Bjorklund wrote: > >>>> Juergen Schoenwaelder > wrote: > >>>>> It seems is arguing > to be > >>>>> cautious with the later. Will RESTCONF follow the recommendations > >>>>> given in this ID or not? > >>>>> > >>>>> I understand that you do not want excessive URI discovery > overhead. > >>>> > >>>> It seems to me that draft-ietf-appsawg-uri-get-off-my-lawn-00 > requires > >>>> us to use URI discovery. If this is a firm requirement on a > protocol > >>>> developed in the IETF, I think we should not do RESTCONF at all. > The > >>>> whole point of RESTCONF is to have a "quick" and "simple" > interface. > >>>> URI discovery puts an enormous burden on the client. > >>>> > >>>> Maybe it would be a good idea to get this design "approved" before > we > >>>> spend more time on this protocol. > >>>> > >>> > >>> I believe what is indeed called for here is an early review of this > >>> work by apps area experts. It is not about 'approving' this work, > it > >>> is about making sure that we get good technical advice on the > design > >>> of the protocol (and of course to avoid late surprises). In other > >>> words, I think we should try to find ways to work in a positive and > >>> constructive spirit with apps area experts here. > >> > >> Absolutely. How do we get this review? Do we do that *before* > >> charter update? > > > > This is something for the chairs to figure out. There is also the > > formal role of a 'technical advisor'. But what we need is a serious > > technical review, establishing a 'technical advisor' may be a means > > for this but there might be other ways of getting the input. > > > > /js > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bclaise@cisco.com Wed Jan 22 05:40:12 2014 Return-Path: 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 008BE1A00D6 for ; Wed, 22 Jan 2014 05:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 htUWQSyIh7Qv for ; Wed, 22 Jan 2014 05:40:10 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id C6ACB1A00F7 for ; Wed, 22 Jan 2014 05:40:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4692; q=dns/txt; s=iport; t=1390398009; x=1391607609; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=cgDmuTNDK3fEiZ4CyMI4P/3Y+l/igKawxYo46oaaN14=; b=Rn1JB7rnS9voIcRXgVjbG6JwtXyOH7PytxiCkh2lX9itpJqSq3dnXcgs QZec/sOHYUJD1AwbtLG0e9bzk999fCkrmE8FLlN1U5UZh2GlF0bN0RbSo afijl7VEvrRMk4bXjuUuOgMIvbpF13uQgY1IVACK42V8gjTgklxS9r87J o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAK3J31KQ/khR/2dsb2JhbABagws4iTGvfoMFgRIWdIIlAQEBBHgBEAsEFAkWDwkDAgECAUUGAQwBBwEBiAHCCBeOfAeEOASYIoZHi1GDLjs X-IronPort-AV: E=Sophos;i="4.95,699,1384300800"; d="scan'208,217";a="4013399" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 22 Jan 2014 13:40:08 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0MDe8pK024871; Wed, 22 Jan 2014 13:40:08 GMT Message-ID: <52DFCA38.6020708@cisco.com> Date: Wed, 22 Jan 2014 14:40:08 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Andy Bierman References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> In-Reply-To: <52DFBD41.4040208@bwijnen.net> Content-Type: multipart/alternative; boundary="------------040802000406060409000607" Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 13:40:12 -0000 This is a multi-part message in MIME format. --------------040802000406060409000607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, I believe I finally see a source of confusion. The proposal was: "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented" What was meant: "RESTCONF should not deviate from the _NETCONF capabilities_unless proper justification is provided and documented" Sure there are constraints related to REST and HTTP, but this sentence is not really meant to discuss "8 request/response pairs to accomplish 1 edit in NETCONF versus a different number in RESTCONF". However, this sentence is valid for a feature such as locking, if not provided by RESTCONF. Regards, Benoit > Inline > > On 21/01/14 01:56, Andy Bierman wrote: >> IMO this "should not deviate" sentence needs to be replaced. >> NETCONF has sessions and operations tuned for session-based management. >> It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. >> RESTCONF is going to deviate from that. RESTCONF imposes a resource >> model on the content and NETCONF does not. > > Andy, the example you give here is easy to defend. I see it as > an improvement and not so much as a deviation. > > But even if we (anyone) see(s) it as a deviation, then I think it is easy > enough to point it out and justify it. > > So I see no issue with the text as in the latest charter proposal. > > The chairs and AD agree that this is not an issue if put into the > charter. > It avoids controversial discussion in the future but simplifies > further decisions > > I believe we have WG consensus to move forward and get the charter > approved by IESG. > > Bert > . > --------------040802000406060409000607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

I believe I finally see a source of confusion.
The proposal was: "RESTCONF should not deviate from NETCONF unless proper justifications is provided and documented"
What was meant: "RESTCONF should not deviate from the NETCONF capabilities unless proper justification is
provided and documented"

Sure there are constraints related to REST and HTTP, but this sentence is not really meant to discuss "8 request/response pairs to accomplish 1 edit in NETCONF versus a different number in RESTCONF".  However, this sentence is valid for a feature such as locking, if not provided by RESTCONF.

Regards, Benoit
Inline

On 21/01/14 01:56, Andy Bierman wrote:
IMO this "should not deviate" sentence needs to be replaced.
NETCONF has sessions and operations tuned for session-based management.
It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF.
RESTCONF is going to deviate from that. RESTCONF imposes a resource
model on the content and NETCONF does not.

Andy, the example you give here is easy to defend. I see it as
an improvement and not so much as a deviation.

But even if we (anyone) see(s) it as a deviation, then I think it is easy
enough to point it out and justify it.

So I see no issue with the text as in the latest charter proposal.

The chairs and AD agree that this is not an issue if put into the charter.
It avoids controversial discussion in the future but simplifies further decisions

I believe we have WG consensus to move forward and get the charter approved by IESG.

Bert
.


--------------040802000406060409000607-- From wdec.ietf@gmail.com Wed Jan 22 06:14:09 2014 Return-Path: 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 05B651A00B6 for ; Wed, 22 Jan 2014 06:14:09 -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 CQnpHxLm3mj0 for ; Wed, 22 Jan 2014 06:14:06 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1C1A041F for ; Wed, 22 Jan 2014 06:14:06 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so428754pbc.41 for ; Wed, 22 Jan 2014 06:14:06 -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=v9Kphsp3nm3xEysOHGwBczfvdVtU897s7biqfdTQXPE=; b=wXoLl1k/+qGgojpccqJeSguDSVxPDlAjEXvXfUyp1ZKlTLoSRwMraviQc005tN0JMq b6KaEaqcGzEFmqJrmyszLfAPjtBZuNei5QTL+7ANMIPG41Ra0vy5zkixRq418XF2N5ys fYlRNcynDbi4UsuNiwBLGXS2p1sbdh3/Ix7g5FE/3lQs9QJQG8dmjJoXppOXzzxOw/uK 9le0PzCwcf6NPkkwzRIM+lOSTYmCuTC5MrB0BI4vqXHf22moQqA0WSW+vkaeZ+fUCNAE Jlsym12jpeoTvILcUzS821mL07dyYeLofcTNpk0d2fetI6+WgNi2HmcyNSJycbXMGf5u ccQw== MIME-Version: 1.0 X-Received: by 10.66.217.133 with SMTP id oy5mr2006635pac.46.1390400046473; Wed, 22 Jan 2014 06:14:06 -0800 (PST) Received: by 10.70.1.70 with HTTP; Wed, 22 Jan 2014 06:14:06 -0800 (PST) In-Reply-To: <52DFCA38.6020708@cisco.com> References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> Date: Wed, 22 Jan 2014 15:14:06 +0100 Message-ID: From: Wojciech Dec To: Benoit Claise Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 14:14:09 -0000 On 22 January 2014 14:40, Benoit Claise wrote: > Dear all, > > I believe I finally see a source of confusion. > The proposal was: "RESTCONF should not deviate from NETCONF unless proper > justifications is provided and documented" > What was meant: "RESTCONF should not deviate from the NETCONF capabilities > unless proper justification is > provided and documented" > > Sure there are constraints related to REST and HTTP, but this sentence is > not really meant to discuss "8 request/response pairs to accomplish 1 edit > in NETCONF versus a different number in RESTCONF". However, this sentence > is valid for a feature such as locking, if not provided by RESTCONF. That is one item. The other is "REST" or "RESTful". As noted on this thread, the motivation is really HTTP rather than REST design (at least as intended by those that coined the REST term). Accordingly, and to perhaps further lengthy discussions of hoe "RESTful" is the document or not, the charter should actually reflect that it is development of an "HTTP based interface". -Wojciech. > > Regards, Benoit > > Inline > > On 21/01/14 01:56, Andy Bierman wrote: > > IMO this "should not deviate" sentence needs to be replaced. > NETCONF has sessions and operations tuned for session-based management. > It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. > RESTCONF is going to deviate from that. RESTCONF imposes a resource > model on the content and NETCONF does not. > > > Andy, the example you give here is easy to defend. I see it as > an improvement and not so much as a deviation. > > But even if we (anyone) see(s) it as a deviation, then I think it is easy > enough to point it out and justify it. > > So I see no issue with the text as in the latest charter proposal. > > The chairs and AD agree that this is not an issue if put into the charter. > It avoids controversial discussion in the future but simplifies further > decisions > > I believe we have WG consensus to move forward and get the charter approved > by IESG. > > Bert > . > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Jan 22 07:20:29 2014 Return-Path: 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 D34111A0120 for ; Wed, 22 Jan 2014 07:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ufZR1Kr3p_rc for ; Wed, 22 Jan 2014 07:20:26 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5DB1A012E for ; Wed, 22 Jan 2014 07:20:21 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so566541qac.36 for ; Wed, 22 Jan 2014 07:20:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Ivst9uRou7lCN8lZ8DQAdjb9faKCr5ROMWqQFYhp00A=; b=mEYB5IxxdAzF9p9ZGMPqZA3YGdrkqyBeQ3u8eMguLpQwEICBtvHPtMwl+PjOZ6+B2B AdyDLrLBAJ7xSPr7QlfVN4DaR+cbkRJtPyXJtl0Ms76dUzSiSqKmWKlMEGp2qkOTc6h2 mh69hWCjouoGkdLH1PDdrAGF4tmkH5nvmTU34dPZyBSs1ub7oDcPYaXOrLIRNTrneNHC vXFXMNvsWZmFzFGGvHoWrZBEVxDUD9VbD7uk+knhr9LVrooce01lQLP810+Pnz/Z6v6w GnZoU+Xvh3EuW+GxEekBArQfxqGi3NgiiEh2o5wsVlEOKzLRyDGO8GT6ywlkU50a8tAp ocUQ== X-Gm-Message-State: ALoCoQmjhfy0Yb9hV7eFe0kTaQtz83oFdagwLlU9vHCAe3fWnRA/9QeuyMyVA2UxicfmXqovcjIt MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr3129151qgx.18.1390404020690; Wed, 22 Jan 2014 07:20:20 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 22 Jan 2014 07:20:20 -0800 (PST) In-Reply-To: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> Date: Wed, 22 Jan 2014 07:20:20 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=001a11c00434bf8ac304f090a908 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 15:20:30 -0000 --001a11c00434bf8ac304f090a908 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 22, 2014 at 6:14 AM, Wojciech Dec wrote: > On 22 January 2014 14:40, Benoit Claise wrote: > > Dear all, > > > > I believe I finally see a source of confusion. > > The proposal was: "RESTCONF should not deviate from NETCONF unless proper > > justifications is provided and documented" > > What was meant: "RESTCONF should not deviate from the NETCONF > capabilities > > unless proper justification is > > provided and documented" > > > > Sure there are constraints related to REST and HTTP, but this sentence is > > not really meant to discuss "8 request/response pairs to accomplish 1 > edit > > in NETCONF versus a different number in RESTCONF". However, this > sentence > > is valid for a feature such as locking, if not provided by RESTCONF. > > That is one item. > The other is "REST" or "RESTful". As noted on this thread, the > motivation is really HTTP rather than REST design (at least as > intended by those that coined the REST term). Accordingly, and to > perhaps further lengthy discussions of hoe "RESTful" is the document > or not, the charter should actually reflect that it is development of > an "HTTP based interface". > > We certainly need to reach consensus on the protocol mechanics and design assumptions. The content semantics and syntax are fully described by YANG. I agree with Kent that we are trying to allow YANG-aware applications to manage a device with HTTP. Maybe we had it right calling this YANG-API instead of RESTCONF. The authors discussed "RESTful features" such as returning a full URL _self link in every node that is retrieved. This increases payload sizes by about 10X, so we did not add that. We could also give every single data node its own resource type (and maybe not bother with YANG?). Then an app can look up the hard-wired code to handle the "interfaces.interface.if-type" resource type, etc. Can you point me to any REST-ful CM solutions that use models at least as complicated as the ietf-routing-cfg.yang module? Vendors are actually designing YANG modules for RESTCONF even more complicated than this module, We want to make sure we do not design a solution that works well with "Hello world" but cannot be used to manage a real router. -Wojciech. > > Andy > > > > Regards, Benoit > > > > Inline > > > > On 21/01/14 01:56, Andy Bierman wrote: > > > > IMO this "should not deviate" sentence needs to be replaced. > > NETCONF has sessions and operations tuned for session-based management. > > It takes up to 8 request/response pairs to accomplish 1 edit in NETCONF. > > RESTCONF is going to deviate from that. RESTCONF imposes a resource > > model on the content and NETCONF does not. > > > > > > Andy, the example you give here is easy to defend. I see it as > > an improvement and not so much as a deviation. > > > > But even if we (anyone) see(s) it as a deviation, then I think it is easy > > enough to point it out and justify it. > > > > So I see no issue with the text as in the latest charter proposal. > > > > The chairs and AD agree that this is not an issue if put into the > charter. > > It avoids controversial discussion in the future but simplifies further > > decisions > > > > I believe we have WG consensus to move forward and get the charter > approved > > by IESG. > > > > Bert > > . > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c00434bf8ac304f090a908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Jan 22, 2014 at 6:14 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 22 January 2014 14:40, Benoit Claise <= bclaise@cisco.com> wrote:
> Dear all,
>
> I believe I finally see a source of confusion.
> The proposal was: "RESTCONF should not deviate from NETCONF unles= s proper
> justifications is provided and documented"
> What was meant: "RESTCONF should not deviate from the NETCONF cap= abilities
> unless proper justification is
> provided and documented"
>
> Sure there are constraints related to REST and HTTP, but this sentence= is
> not really meant to discuss "8 request/response pairs to accompli= sh 1 edit
> in NETCONF versus a different number in RESTCONF". =A0However, th= is sentence
> is valid for a feature such as locking, if not provided by RESTCONF.
That is one item.
The other is "REST" or "RESTful". As noted on this thre= ad, the
motivation is really HTTP rather than REST design (at least as
intended by those that coined the REST term). Accordingly, and to
perhaps further lengthy discussions of hoe "RESTful" is the docum= ent
or not, the charter should actually reflect that it is development of
an "HTTP based interface".



We certainly need to re= ach consensus on the protocol mechanics and design assumptions.
T= he content semantics and syntax are fully described by YANG. I agree with K= ent that
we are trying to allow YANG-aware applications to manage a device with= HTTP.
Maybe we had it right calling this YANG-API instead of RES= TCONF.

The authors discussed "RESTful feature= s" such as returning a full URL _self link in
every node that is retrieved. =A0This increases payload sizes by about= 10X,
so we did not add that. We could also give every single dat= a node its own
resource type (and maybe not bother with YANG?). = =A0Then an app can look
up the hard-wired code to handle the "interfaces.interface.if-typ= e" resource type, etc.

Can you point me to an= y REST-ful CM solutions that use models at least as
complicated a= s the ietf-routing-cfg.yang module? Vendors are actually designing
YANG modules for RESTCONF even more complicated than this module,
We want to make sure we do not design a solution that works well with= "Hello world"
but cannot be used to manage a real rout= er.


-Wojciech.


Andy
=A0
>
> Regards, Benoit
>
> Inline
>
> On 21/01/14 01:56, Andy Bierman wrote:
>
> IMO this "should not deviate" sentence needs to be replaced.=
> NETCONF has sessions and operations tuned for session-based management= .
> It takes up to 8 request/response pairs to accomplish 1 edit in NETCON= F.
> RESTCONF is going to deviate from that. RESTCONF imposes a resource > model on the content and NETCONF does not.
>
>
> Andy, the example you give here is easy to defend. I see it as
> an improvement and not so much as a deviation.
>
> But even if we (anyone) see(s) it as a deviation, then I think it is e= asy
> enough to point it out and justify it.
>
> So I see no issue with the text as in the latest charter proposal.
>
> The chairs and AD agree that this is not an issue if put into the char= ter.
> It avoids controversial discussion in the future but simplifies furthe= r
> decisions
>
> I believe we have WG consensus to move forward and get the charter app= roved
> by IESG.
>
> Bert
> .
>
>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

--001a11c00434bf8ac304f090a908-- From talmi@marvell.com Wed Jan 22 22:56:17 2014 Return-Path: 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 A58C31A022C for ; Wed, 22 Jan 2014 22:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-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 D8k8jNQWJgRZ for ; Wed, 22 Jan 2014 22:56:15 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 436CA1A0125 for ; Wed, 22 Jan 2014 22:56:15 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s0N6sZeW020273; Wed, 22 Jan 2014 22:56:13 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1hhwkxnqpm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Jan 2014 22:56:12 -0800 Received: from YK-HUB02.marvell.com (10.4.102.52) by SC-OWA.marvell.com (10.93.76.28) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 22 Jan 2014 22:56:12 -0800 Received: from IL-MB01.marvell.com ([10.4.102.53]) by YK-HUB02.marvell.com ([10.4.102.52]) with mapi; Thu, 23 Jan 2014 08:56:08 +0200 From: Tal Mizrahi To: Joe Marcus Clarke , Tal Mizrahi , "netconf@ietf.org" Date: Thu, 23 Jan 2014 08:56:07 +0200 Thread-Topic: [Netconf] Updated draft-mm-netconf-time-capability-01 Thread-Index: Ac8VcGvNKKIBBO34SWO2GXEdU8wy3gCkS/Jg Message-ID: <74470498B659FA4687F0B0018C19A89C01D4391106DF@IL-MB01.marvell.com> References: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> <52D57BD7.7060006@cisco.com> <74470498B659FA4687F0B0018C19A89C01D4390857BE@IL-MB01.marvell.com> <52DC6362.6060509@cisco.com> In-Reply-To: <52DC6362.6060509@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-22_08:2014-01-22,2014-01-22,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401220283 Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 06:56:17 -0000 Hi Joe, Thanks again for the comments. > I don't get this. If I schedule something to run in one hour, I have to = wait an hour for the rpc-reply? That doesn't seem right. Okay, so this goes back to our comment that the current draft focuses on so= ft-real time scheduling (http://www.ietf.org/mail-archive/web/netconf/curre= nt/msg08549.html), but I should probably explain it a bit further. In this = context there is an implicit assumption that RPCs are scheduled to a *near = future* time. Here is an example (the numbers are just an example, so they = do not necessarily represent a real-life scenario). Let's say we have a cl= ient and two servers, and let's say that every RPC the client sends (a norm= al RPC, not a scheduled one) is executed within 3 seconds with a probabilit= y .999, i.e., the client receives an rpc-reply within 3 seconds. The client= can send a *scheduled* RPC to the two servers, with a tha= t is 3 seconds into the future; consequently, each of the two servers perfo= rms the RPC exactly 3 seconds afterwards with a probability .999 (each). Th= e client has to wait 3 seconds to get the rpc-reply, but that is not so bad= , since in the non-scheduled RPC the client may need to wait 3 seconds anyw= ay. And we should note that in this example each of the servers has a proba= bility of .001 not to perform the RPC on time, which is why we are emphasiz= ing that we have focused on addressing soft-real time scheduling. Indeed, the rpc-reply is received only after the RPC was scheduled, but we = are assuming that the scheduling time is not too far into the future (which= is one of the reasons this draft includes the ). I think the current draft is less targeted at far-future scheduling (e.g., = an hour in your example). Our thoughts were that approaches such as draft-k= watsen-conditional-enablement are a better fit for far-future scheduling. H= owever, if we come to the conclusion that we *do* need to address far-futur= e scheduling, it is possible to add the following functionality (this is a = tweak to something Andy suggested a couple of months ago): (i) When a serve= r receives a scheduled RPC, it can send a notification to the client, indic= ating that the scheduled RPC was received and added to the server's schedul= e. The rpc-reply itself is sent after the RPC was executed at the scheduled= time. (ii) The client can send a cancellation message if it does not recei= ve a notification, or if it receives an rpc-error from one of the servers.= =20 So an open question here is whether we should add the 2 features above (not= ification, cancellation) that would enable far-future scheduling as well. Regards, Tal. -----Original Message----- From: Joe Marcus Clarke [mailto:jclarke@cisco.com]=20 Sent: Monday, January 20, 2014 1:45 AM To: Tal Mizrahi; Tal Mizrahi; netconf@ietf.org Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 On 1/19/14, 8:57 AM, Tal Mizrahi wrote: > Hi Joe, > > Thanks for the comments. > >> However, the draft doesn't discuss how a client can retrieve the results= of a scheduled RPC. How would I go about ensuring that an RPC completed (= or not) at the scheduled time? > > If the client gets an rpc-reply with an element it knows the schedul= ed operation was performed successfully. > If the client wants to know whether the RPC was performed *on time* it ne= eds to include the element in the RPC (in addition to including = the element), causing the server to include the element in the rpc-reply. This allows the client to receive feedback= about the actual execution time of the RPC. This behavior is described in = section 3.1 of the draft. I don't get this. If I schedule something to run in one hour, I have to wa= it an hour for the rpc-reply? That doesn't seem right. My understanding from the initial read was that I would get an rpc-reply ri= ght away to indicate the request was scheduled successfully. > >> I think there should be a way to query the server's current time to make= sure the client and server agree. > > One way to do this is to use the element; the client can send = (any kind of) an RPC to the server which includes the element. C= onsequently, the server includes the in its rpc-reply. It = should be noted that this method allows a *very* rough indication about whe= ther the client and server are synchronized. > However, I believe the correct way to inquire about whether the server is= synchronized or not is at the clock synchronization protocol layer. For ex= ample, the NTP MIB (RFC 5907) includes a set of objects that allow you to c= heck the current status of NTP, including the offset to the current referen= ce time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes si= milar objects. > [One may ask whether NTP and PTP have a YANG module for NETCONF, but=20 > that is a completely different story...:) ] In terms of this draft should there be some text that explain this as a pot= ential concern with suggestions? Joe > > Thanks, > Tal Mizrahi. > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Joe=20 > Marcus Clarke > Sent: Tuesday, January 14, 2014 8:03 PM > To: Tal Mizrahi; netconf@ietf.org > Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 > > On 1/2/14, 10:56 AM, Tal Mizrahi wrote: >> >> Hi, >> >> We have posted an updated draft: >> http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 >> >> Thanks to all the people who reviewed and sent comments about draft 00. >> Here is a summary of the changes compared to draft 00: >> - We have added discussion about the scheduling tolerance: an upper >> bound on how far into the future/past an RPC can be scheduled. >> - The scheduled time now refers to the *start* time of the operation, >> rather than to its completion. >> - The time format has been changed to date-and-time. > > I read through the draft, Tal, and I have a few comments. > > Section 3.1: > > I think there should be a way to query the server's current time to make = sure the client and server agree. This should be part of the overall dialo= gue between the two when scheduling will be done. Even though the client m= ay be configured to use NTP, the server may not have had a chance to sync t= o its clock source. You talk about time sync, but I think this extra level= of checking will assure that the server doesn't do something the client di= dn't expect. At the very least, the client may decide to abort the schedul= ed operation. > > This goes outside of the time tolerance you define in Section 3.5. I=20 > could, for example, say I have a 10 second tolerance in either=20 > direction of time 2015-10-21T04:29:00.235. The server gets a chance=20 > to execute at > 2015-10-21T04:38:00.235 and does, but the actual time on the client is 20= 15-10-21T05:29:00.235. > > Section 3.4: > > You introduce time-interval here without really saying how it will be use= d. You do this later, but it seemed a bit disjointed to me. Maybe swap se= ctions 3.4 and 3.5 and mention time-interval in the new section 3.4. > > Section 4.5 > > You define the element but you reference it as : > > OLD TEXT: > > ...operation. Every message MAY include the ... > > NEW TEXT: > > ...operation. Every message MAY include the ... > > NIT: I would swap the order of and as the for= mer references the latter. > > Section 4.5.1: > > You have two leaf nodes with the name sched-max-past. They have two diff= erent descriptions. I think the first should be sched-max-future. > >> At this point, draft 01 is soft-real-time-oriented. We are interested=20 >> to hear feedback about whether there is an interest in the working=20 >> group to develop the hard real-time functionality as well. > > I think soft time is fine. However, the draft doesn't discuss how a clie= nt can retrieve the results of a scheduled RPC. How would I go about ensur= ing that an RPC completed (or not) at the scheduled time? > > Joe > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From kwatsen@juniper.net Thu Jan 23 09:59:53 2014 Return-Path: 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 A10231A0040 for ; Thu, 23 Jan 2014 09:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dgnhAnZregtH for ; Thu, 23 Jan 2014 09:59:51 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 86B861A000A for ; Thu, 23 Jan 2014 09:59:51 -0800 (PST) Received: from mail8-co1-R.bigfish.com (10.243.78.234) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.22; Thu, 23 Jan 2014 17:59:50 +0000 Received: from mail8-co1 (localhost [127.0.0.1]) by mail8-co1-R.bigfish.com (Postfix) with ESMTP id 76F919002DE; Thu, 23 Jan 2014 17:59:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h1155h) Received-SPF: pass (mail8-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(85852003)(83506001)(86362001)(56816005)(93136001)(90146001)(93516002)(83072002)(76796001)(76786001)(36756003)(69226001)(76482001)(53806001)(56776001)(54316002)(54356001)(74706001)(51856001)(92726001)(46102001)(16236675002)(81686001)(77096001)(2656002)(87936001)(80976001)(83322001)(4396001)(79102001)(74502001)(47446002)(65816001)(63696002)(74662001)(92566001)(31966008)(47736001)(74366001)(74876001)(81342001)(81816001)(59766001)(50986001)(80022001)(47976001)(85306002)(87266001)(49866001)(94316002)(77982001)(81542001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail8-co1 (localhost.localdomain [127.0.0.1]) by mail8-co1 (MessageSwitch) id 1390499987891704_21793; Thu, 23 Jan 2014 17:59:47 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.239]) by mail8-co1.bigfish.com (Postfix) with ESMTP id 1027CA0004D; Thu, 23 Jan 2014 17:59:28 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 23 Jan 2014 17:59:26 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 23 Jan 2014 17:59:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.859.15; Thu, 23 Jan 2014 17:59:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) with mapi id 15.00.0859.013; Thu, 23 Jan 2014 17:59:19 +0000 From: Kent Watsen To: Andy Bierman , Wojciech Dec Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHF39qA///0OICAAdlIAIAACgYAgAnd3YCAAA+GgIACWEuAgAAPdQCAAAl9AIAAEoIAgAFq7QA= Date: Thu, 23 Jan 2014 17:59:18 +0000 Message-ID: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 0100732B76 Content-Type: multipart/alternative; boundary="_000_CF06BFCE58D56kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 17:59:53 -0000 --_000_CF06BFCE58D56kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > We certainly need to reach consensus on the protocol mechanics and design > assumptions. The content semantics and syntax are fully described by YAN= G. > I agree with Kent that we are trying to allow YANG-aware applications to > manage a device with HTTP. Maybe we had it right calling this YANG-API > instead of RESTCONF. I'm ok to renaming RESTCONF if the apps-people agree that it's best. HTTPC= onf or whatever is fine by me. I wouldn't want to call it YANG-API, though= , because it's not descriptive enough; for instance, one could easily say t= hat YANG-API =3D=3D NETCONF (not RESTCONF)... Kent --_000_CF06BFCE58D56kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


> We certainly need to reach consensus on the protocol mechanics an= d design
> assumptions.  The content semantics and syntax are full= y described by YANG.
> I agree with Kent that we are trying to allow YANG-aware app= lications to 
> manage a device with HTTP.  Maybe we had it right calling th= is YANG-API 
> instead of RESTCONF.

I'm ok to renaming RESTCONF if the apps-people agree that it's best. &= nbsp;HTTPConf or whatever is fine by me.  I wouldn't want to call it Y= ANG-API, though, because it's not descriptive enough; for instance, on= e could easily say that YANG-API =3D=3D NETCONF (not RESTCONF)...

Kent

--_000_CF06BFCE58D56kwatsenjunipernet_-- From mehmet.ersue@nsn.com Thu Jan 23 10:05:40 2014 Return-Path: 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 39C9E1A0015 for ; Thu, 23 Jan 2014 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 qbD6NbTUbp3J for ; Thu, 23 Jan 2014 10:05:37 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4002C1A000A for ; Thu, 23 Jan 2014 10:05:37 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s0NI5YDx020942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2014 19:05:34 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s0NI5Y8r015100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 19:05:34 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 23 Jan 2014 19:05:34 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 19:05:33 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Kent Watsen , Andy Bierman , Wojciech Dec Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHF39qA///0OICAAdlIAIAACgYAgAnd3YCAAA+GgIACWEuAgAAPdQCAAAl9AIAAEoIAgAFq7QD//6ruoA== Date: Thu, 23 Jan 2014 18:05:33 +0000 Message-ID: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F82689BEDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8524 X-purgate-ID: 151667::1390500334-000025D0-DFF9432A/0-0/0-0 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:05:40 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F82689BEDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I as a technical contributor would suggest to let it as is, namely RESTConf= . A lot of folks in and outside of IETF know it already under this title. And obviously we are the only ones who are questioning it. Cheers, Mehmet From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent Watse= n Sent: Thursday, January 23, 2014 6:59 PM To: Andy Bierman; Wojciech Dec Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval > We certainly need to reach consensus on the protocol mechanics and design > assumptions. The content semantics and syntax are fully described by YAN= G. > I agree with Kent that we are trying to allow YANG-aware applications to > manage a device with HTTP. Maybe we had it right calling this YANG-API > instead of RESTCONF. I'm ok to renaming RESTCONF if the apps-people agree that it's best. HTTPC= onf or whatever is fine by me. I wouldn't want to call it YANG-API, though= , because it's not descriptive enough; for instance, one could easily say t= hat YANG-API =3D=3D NETCONF (not RESTCONF)... Kent --_000_E4DE949E6CE3E34993A2FF8AE79131F82689BEDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I as a technical contribu= tor would suggest to let it as is, namely RESTConf.

 <= /p>

A lot of folks in and out= side of IETF know it already under this title.

And obviously we are the = only ones who are questioning it.

 <= /p>

Cheers,
Mehmet

 <= /p>

From: Netconf = [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent Watsen
Sent: Thursday, January 23, 2014 6:59 PM
To: Andy Bierman; Wojciech Dec
Cc: Netconf
Subject: Re: [Netconf] Netconf Charter update for approval

 

 

 

> We certainly need to r= each consensus on the protocol mechanics and design

> assumptions. &nbs= p;The content semantics and syntax are fully described by YANG.<= /span>

> I agree with Kent that=  we are trying to allow YANG-aware applications to 

> manage a device with H= TTP.  Maybe we had it right calling this YANG-API 

> instead of RESTCONF.

 

I'm ok to renaming RESTCONF= if the apps-people agree that it's best.  HTTPConf or whatever is fin= e by me.  I wouldn't want to call it YANG-API, though, because it's not descriptive enough; for instance, one could easily say that = YANG-API =3D=3D NETCONF (not RESTCONF)...

 

Kent

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F82689BEDEMUMBX005nsnintr_-- From andy@yumaworks.com Thu Jan 23 10:38:34 2014 Return-Path: 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 1C8831A01AB for ; Thu, 23 Jan 2014 10:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 uYEYkF4wGB1N for ; Thu, 23 Jan 2014 10:38:29 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9ED1A01F5 for ; Thu, 23 Jan 2014 10:38:27 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so2959506qcz.41 for ; Thu, 23 Jan 2014 10:38:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a+Aam85WTZy6AdPPOHrs4CKAz+dr1rqrFErvuG8UfBY=; b=eg8OdKpCa69IiTyPdaRGPYfF+31+VItw1CLBaNkA56J16rpAluI3Hi9OFpjNzcYpTP xMMX4yVAbbaoZR9RTRfjGVnyevpy6uYNOGmmvSpBuLudkFd/nQky9xgAH13oD7heTIAF MQtG78QNAzKXX9hEIyNgylqvMAJEZMOls6h+X7E7Nd444xm/11S8GqDczQ4PZJD+j5de D96cUQMbasfPwyJxzWcwsjbGy6PqXzxhM0+eDD9aug1gnNzwxVhD0bGpz6nk0xfCgDJA I7te6Kd+KhFkmRhLIgt/xG+qqPZY4f+X1h4DGoUp1Xt1raIC881ruMTkd169+LgGoM7B 3CKA== X-Gm-Message-State: ALoCoQnKKjeiJycNTsVmQj6gyQdYkhr3+M9RJCe19Uq2t3tIP6k5LRB7q7BBzskQvqPuV0j55jvo MIME-Version: 1.0 X-Received: by 10.224.119.79 with SMTP id y15mr14065602qaq.16.1390502306193; Thu, 23 Jan 2014 10:38:26 -0800 (PST) Received: by 10.140.48.75 with HTTP; Thu, 23 Jan 2014 10:38:26 -0800 (PST) In-Reply-To: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> Date: Thu, 23 Jan 2014 10:38:26 -0800 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: multipart/alternative; boundary=047d7b6d7e0a0536fb04f0a78c26 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2014 18:38:34 -0000 --047d7b6d7e0a0536fb04f0a78c26 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 23, 2014 at 10:05 AM, Ersue, Mehmet (NSN - DE/Munich) < mehmet.ersue@nsn.com> wrote: > I as a technical contributor would suggest to let it as is, namely > RESTConf. > > > > A lot of folks in and outside of IETF know it already under this title. > > And obviously we are the only ones who are questioning it. > > > There is a fundamental design difference with RESTCONF that seems to be perceived as not REST-ful. With data-model driven solutions like RESTCONF, NETCONF, or SNMP, there is no point is sending redundant schema information over the wire in the protocol. All the semantics and validation rules are in the schema, and both client and server are expected to have access to the same schema definitions. This is done because the data model API contract is far too complex to discover or express on the fly. Applications need to be designed and coded to the API contract in advance. Cheers, > Mehmet > Andy > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *ext Kent > Watsen > *Sent:* Thursday, January 23, 2014 6:59 PM > *To:* Andy Bierman; Wojciech Dec > *Cc:* Netconf > *Subject:* Re: [Netconf] Netconf Charter update for approval > > > > > > > > > We certainly need to reach consensus on the protocol mechanics and > design > > > assumptions. The content semantics and syntax are fully described by > YANG. > > > I agree with Kent that we are trying to allow YANG-aware applications to > > > manage a device with HTTP. Maybe we had it right calling this YANG-API > > > instead of RESTCONF. > > > > I'm ok to renaming RESTCONF if the apps-people agree that it's best. > HTTPConf or whatever is fine by me. I wouldn't want to call it YANG-API, > though, because it's not descriptive enough; for instance, one could easily > say that YANG-API == NETCONF (not RESTCONF)... > > > > Kent > > > --047d7b6d7e0a0536fb04f0a78c26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Jan 23, 2014 at 10:05 AM, Ersue, Mehmet (NSN - DE/Munich) <= span dir=3D"ltr"><mehmet.ersue@nsn.com> wrote:

I as a technical contribu= tor would suggest to let it as is, namely RESTConf.

=A0<= /p>

A lot of folks in and out= side of IETF know it already under this title.

And obviously we are the = only ones who are questioning it.

=A0



There is a fundamen= tal design difference with RESTCONF that seems
to be perceived as not REST-ful. =A0With data-model driven solutions
like RESTCONF, NETCONF, or SNMP, there is no point is sending
redundant schema information over the wire in the protocol. All the
semantics and validation rules are in the schema, and both client
and server are expected to have access to the same schema definitions= .
This is done because the data model API contract is far too com= plex to
discover or express on the fly. =A0Applications need to be designed an= d coded
to the API contract in advance.

=

Cheers,
Mehmet


Andy
=A0

=A0<= /p>

From: Netconf = [mailto:netco= nf-bounces@ietf.org] On Behalf Of ext Kent Watsen
Sent: Thursday, January 23, 2014 6:59 PM
To: Andy Bierman; Wojciech Dec
Cc: Netconf
Subject: Re: [Netconf] Netconf Charter update for approval=

=A0

=A0

=A0

> We certainly need to reach consens= us on the protocol mechanics and design

>=A0assumptions. =A0The content sema= ntics and syntax are fully described by YANG.

> I agree with Kent that=A0we are tr= ying to allow YANG-aware applications to=A0

> manage a device with HTTP. =A0Mayb= e we had it right calling this YANG-API=A0

> instead of RESTCONF.=

=A0

I'm ok to renaming RESTCONF if the = apps-people agree that it's best. =A0HTTPConf or whatever is fine by me= . =A0I wouldn't want to call it YANG-API, though, because it's not descriptive enough;=A0for instance, one could easily say that= YANG-API =3D=3D NETCONF (not RESTCONF)...

=A0

Kent

=A0


--047d7b6d7e0a0536fb04f0a78c26-- From wdec.ietf@gmail.com Fri Jan 24 01:13:32 2014 Return-Path: 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 E37171A0214 for ; Fri, 24 Jan 2014 01:13:31 -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 x4h0i-W5_SRG for ; Fri, 24 Jan 2014 01:13:30 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 26D241A020D for ; Fri, 24 Jan 2014 01:13:30 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so3024662pad.36 for ; Fri, 24 Jan 2014 01:13:29 -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=xb7tYh5OYs9QUYttJhXQthxES0iwEa9sYogM8U4ts+s=; b=rYLd6dFFTmz27wtS9jBYlONynSGx0e08B3GukGSd7EleA4Efa8riVT76qdgmMkoHVZ jr6Bz5WQIiYBjni4fXjQbpCnBCKXFTJwYYug7NKJ87z219zmyDjKGQiwEZoiYpEhF5TL I/JUUoIrDBfqeAkeRyaRrAbnS4QTZzCj/ZcBEP3+MUxESAP3iVMxe6sN1lsTJQkg34iL X4RQZjl1I+i9vL4ptRicHE5vmJktA/adev7lkdc+IY5nFy7S8P9wicZPc8H7jLYVZAol qiZpe7nOzYAaNl7UUO1wJSZlIlSOP5LhcBk3/Y+xLKeVp5akpTcoSCI62iFb3uQILumO YIKg== MIME-Version: 1.0 X-Received: by 10.68.236.9 with SMTP id uq9mr13448962pbc.10.1390554809114; Fri, 24 Jan 2014 01:13:29 -0800 (PST) Received: by 10.70.1.70 with HTTP; Fri, 24 Jan 2014 01:13:29 -0800 (PST) In-Reply-To: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> Date: Fri, 24 Jan 2014 10:13:29 +0100 Message-ID: From: Wojciech Dec To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 09:13:32 -0000 On 23 January 2014 19:05, Ersue, Mehmet (NSN - DE/Munich) wrote: > I as a technical contributor would suggest to let it as is, namely RESTConf. > > > > A lot of folks in and outside of IETF know it already under this title. There is of course plenty of precedent for renaming and rescoping of individual drafts and protocols... Having been in a fair bit of "what's REST and what's not" discussions that sap time, I would suggest that going easy on describing the protocol scope with the term REST and RESTful is advisable. Of course none of this means that some of REST style cannot apply. An analogy from the IETF networking world: a few years ago some other body took to defining MPLS-TP, which then had little to do with MPLS as known at the IETF... Generally that was a hassle to deal with for all concerned... > > And obviously we are the only ones who are questioning it. Yes, and I suppose that is so because we are having a WG discussion. Cheers, > > > > Cheers, > Mehmet > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent Watsen > Sent: Thursday, January 23, 2014 6:59 PM > To: Andy Bierman; Wojciech Dec > Cc: Netconf > > > Subject: Re: [Netconf] Netconf Charter update for approval > > > > > > > >> We certainly need to reach consensus on the protocol mechanics and design > >> assumptions. The content semantics and syntax are fully described by >> YANG. > >> I agree with Kent that we are trying to allow YANG-aware applications to > >> manage a device with HTTP. Maybe we had it right calling this YANG-API > >> instead of RESTCONF. > > > > I'm ok to renaming RESTCONF if the apps-people agree that it's best. > HTTPConf or whatever is fine by me. I wouldn't want to call it YANG-API, > though, because it's not descriptive enough; for instance, one could easily > say that YANG-API == NETCONF (not RESTCONF)... > > > > Kent > > From wdec.ietf@gmail.com Fri Jan 24 01:37:46 2014 Return-Path: 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 38CD01A025F for ; Fri, 24 Jan 2014 01:37:46 -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 sojzJTpHRTLu for ; Fri, 24 Jan 2014 01:37:44 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6246B1A0259 for ; Fri, 24 Jan 2014 01:37:44 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so2948830pdj.3 for ; Fri, 24 Jan 2014 01:37:43 -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=HKV5034ymz7aAms7EYzFQ24HHOj9AKZWxk6Hev9C5sg=; b=XV+9Q1lkpuZSN24T1D4leAyC+Ma4W7QnxDkjzQDGLZPj6RazJtXxYXJCzt31YuTujn 62vUohcxaPVr4b+tw4wDvuJYEJ/HC+E1iua6HRM8vNV9TeaS+nmiP7MOQtMrmYOIU/bj uitG8V3tpbPQ9hp08Lk0iNq1cuVXVYZtYQgz5CN5l0/9v7juCQ1N9Z7wmTVH74dnVq0V hTcsl/xhpxwfvWtKib4ukGzBTq676MGn0ZTNfLGRs2NML7ZUA6DtexheS1WqoiXm7P5a DHHy6+fb9lwq+b9reE5FAy0lB8UB9G4U/SAFV4oTRkDF0cez3CsjzpsTaHzvL3j49h3k o8fQ== MIME-Version: 1.0 X-Received: by 10.66.26.236 with SMTP id o12mr13660694pag.15.1390556263382; Fri, 24 Jan 2014 01:37:43 -0800 (PST) Received: by 10.70.1.70 with HTTP; Fri, 24 Jan 2014 01:37:43 -0800 (PST) In-Reply-To: References: <52D3E647.9070000@cisco.com> <52D5696A.8040201@cisco.com> <52DDB8AB.10609@cisco.com> <52DFBD41.4040208@bwijnen.net> <52DFCA38.6020708@cisco.com> Date: Fri, 24 Jan 2014 10:37:43 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 09:37:46 -0000 On 23 January 2014 19:38, Andy Bierman wrote: > > > > On Thu, Jan 23, 2014 at 10:05 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> >> I as a technical contributor would suggest to let it as is, namely >> RESTConf. >> >> >> >> A lot of folks in and outside of IETF know it already under this title. >> >> And obviously we are the only ones who are questioning it. >> >> > > > > There is a fundamental design difference with RESTCONF that seems > to be perceived as not REST-ful. With data-model driven solutions > like RESTCONF, NETCONF, or SNMP, there is no point is sending > redundant schema information over the wire in the protocol. All the > semantics and validation rules are in the schema, and both client > and server are expected to have access to the same schema definitions. > This is done because the data model API contract is far too complex to > discover or express on the fly. Applications need to be designed and coded > to the API contract in advance. There is another REST derived constraint that, I'm not sure lines up with what is being scoped here in terms of Netconf functional equivalence: It is considered un RESTful for a server to to retain any client specific server context state. This would apply to resource locking (aka transactions) and also client event subscriptions. -W. > > >> Cheers, >> Mehmet > > > Andy > >> >> >> >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Kent >> Watsen >> Sent: Thursday, January 23, 2014 6:59 PM >> To: Andy Bierman; Wojciech Dec >> Cc: Netconf >> Subject: Re: [Netconf] Netconf Charter update for approval >> >> >> >> >> >> >> >> > We certainly need to reach consensus on the protocol mechanics and >> > design >> >> > assumptions. The content semantics and syntax are fully described by >> > YANG. >> >> > I agree with Kent that we are trying to allow YANG-aware applications to >> >> > manage a device with HTTP. Maybe we had it right calling this YANG-API >> >> > instead of RESTCONF. >> >> >> >> I'm ok to renaming RESTCONF if the apps-people agree that it's best. >> HTTPConf or whatever is fine by me. I wouldn't want to call it YANG-API, >> though, because it's not descriptive enough; for instance, one could easily >> say that YANG-API == NETCONF (not RESTCONF)... >> >> >> >> Kent >> >> > > From mbj@tail-f.com Fri Jan 24 01:41:32 2014 Return-Path: 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 9D6681A022A for ; Fri, 24 Jan 2014 01:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 JCNEi64lhD7r for ; Fri, 24 Jan 2014 01:41:30 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B0EBF1A0226 for ; Fri, 24 Jan 2014 01:41:30 -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 20A5B37C14D; Fri, 24 Jan 2014 10:41:29 +0100 (CET) Date: Fri, 24 Jan 2014 10:41:28 +0100 (CET) Message-Id: <20140124.104128.739402048375968628.mbj@tail-f.com> To: wdec.ietf@gmail.com From: Martin Bjorklund In-Reply-To: References: 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 Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 09:41:32 -0000 Wojciech Dec wrote: > There is another REST derived constraint that, I'm not sure lines up > with what is being scoped here in terms of Netconf functional > equivalence: It is considered un RESTful for a server to to retain > any client specific server context state. This would apply to resource > locking (aka transactions) Can you be more specific? AFAICT there are no such things in the draft (anymore). > and also client event subscriptions. Ok. /martin From wdec.ietf@gmail.com Fri Jan 24 02:22:30 2014 Return-Path: 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 B450B1A024D for ; Fri, 24 Jan 2014 02:22:30 -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 JNdngepCciQC for ; Fri, 24 Jan 2014 02:22:29 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 912B71A018D for ; Fri, 24 Jan 2014 02:22:29 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so2999355pde.27 for ; Fri, 24 Jan 2014 02:22:28 -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=GEU5T5YnTye3loWC/xrEwcr+WstHrdJzP7zDEtfbz0E=; b=0ZyOZbthqg8a5KqqqboK1RuHBClIi5MKku26h6gFNPWQWXA4LJBBzz9K1VzkrvOBI/ yN8UXl72jHMByDHJkgJ2nS/miQ8E1WnzF/fFkN1kxt/nnkgl5jm+CV49qfxjwokmUJUO g/yMZyMcXbLzAutoai43pTidjdU8uEdky4Vj11ZfCIV6lkCbyVctRBLh5/lbO/nOl339 FjF1jw9JjE1GcV/vNWEHx9olCwwYwBpjoiKoXXqvMScTWoERPDv5ec5oCMTo0N9/FtOx xy6FTqPqfXJcgTzQmYWVTGIMzyu1cq0bCrPzentMY4B9JMHnY74/XmBOGqVqL0UCUf3O GAsQ== MIME-Version: 1.0 X-Received: by 10.66.27.13 with SMTP id p13mr13360997pag.76.1390558948601; Fri, 24 Jan 2014 02:22:28 -0800 (PST) Received: by 10.70.1.70 with HTTP; Fri, 24 Jan 2014 02:22:28 -0800 (PST) In-Reply-To: <20140124.104128.739402048375968628.mbj@tail-f.com> References: <20140124.104128.739402048375968628.mbj@tail-f.com> Date: Fri, 24 Jan 2014 11:22:28 +0100 Message-ID: From: Wojciech Dec To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 10:22:30 -0000 On 24 January 2014 10:41, Martin Bjorklund wrote: > Wojciech Dec wrote: >> There is another REST derived constraint that, I'm not sure lines up >> with what is being scoped here in terms of Netconf functional >> equivalence: It is considered un RESTful for a server to to retain >> any client specific server context state. This would apply to resource >> locking (aka transactions) > > Can you be more specific? AFAICT there are no such things in the > draft (anymore). I'm not saying that it is there, but as per previous posts on this thread, maybe resource locking should be there. I.e. "RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented" . To me it appears that REST style is not a key requirement here, but rather HTTP. -W. > >> and also client event subscriptions. > > Ok. > > > /martin From andy@yumaworks.com Fri Jan 24 03:03:53 2014 Return-Path: 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 9EE191A022A for ; Fri, 24 Jan 2014 03:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zpRmek6mYxOh for ; Fri, 24 Jan 2014 03:03:51 -0800 (PST) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id B749A1A01D8 for ; Fri, 24 Jan 2014 03:03:51 -0800 (PST) Received: by mail-qc0-f169.google.com with SMTP id w7so4166122qcr.14 for ; Fri, 24 Jan 2014 03:03:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LAKlgnULY19tJiI+vdXAD82AyWW2uGlEGD48k4l3ENc=; b=KYxal8DRiWjSJ0PZ590pJZji+cJEc5a9qeLb0ICAp4Avfyz6mHNWpuSm6eQHvlq3bv P9feIU86x2VVWzyBG1zRCp39sgtUz1HjtY2M2cd4OVwjF9bXpf0bBhvCgMuCd15a1ilr 0ChlpXMvemJmFiQRpYhGijjJcKheh1BEGLFSVi10TSQb9Dq10Q0I51jtAjhxMrgW8yUo b8p6WDnU4b6vVEtqboS2AJSln83N0RxZiqdcjdWGymqUeIS2BN0uOFoHoePC532UqqwX 0G9LKFsN8QlBiQh9Io6giBHmnVUWEk6MAN6+3N2BeESvPboxLUp1Ok0jJXGg2rg4G4Qm nAvw== X-Gm-Message-State: ALoCoQnum5Yn7mvFNEPFy71/7l5JVdHU5eytx9psld8Ns7vp91TvkOYl1bHNZn780lqpDbY0Ho9a MIME-Version: 1.0 X-Received: by 10.224.136.10 with SMTP id p10mr855509qat.16.1390561430316; Fri, 24 Jan 2014 03:03:50 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 24 Jan 2014 03:03:50 -0800 (PST) In-Reply-To: References: <20140124.104128.739402048375968628.mbj@tail-f.com> Date: Fri, 24 Jan 2014 03:03:50 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=001a11c2a8b017f0ab04f0b5508e Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 11:03:53 -0000 --001a11c2a8b017f0ab04f0b5508e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec wrote: > On 24 January 2014 10:41, Martin Bjorklund wrote: > > Wojciech Dec wrote: > >> There is another REST derived constraint that, I'm not sure lines up > >> with what is being scoped here in terms of Netconf functional > >> equivalence: It is considered un RESTful for a server to to retain > >> any client specific server context state. This would apply to resource > >> locking (aka transactions) > > > > Can you be more specific? AFAICT there are no such things in the > > draft (anymore). > > I'm not saying that it is there, but as per previous posts on this > thread, maybe resource locking should be there. I.e. "RESTCONF should > not deviate from the NETCONF capabilities unless proper justification > is provided and documented" . > To me it appears that REST style is not a key requirement here, but rather > HTTP. > > I think the NETCONF WG is very likely to create NETCONF over HTTP, and it will end up just as bloated and over-engineered as NETCONF over SSH. I hope the temptation to expose all server complexity to the client is resisted. IMO it would be better to keep the RESTCONF API unified, rather than forcing the client to deal with all the server options in NETCONF. IMO these REST purity tests are a waste of time. > -W. > > > > >> and also client event subscriptions. > > > > Ok. > > > > > > /martin > Andy --001a11c2a8b017f0ab04f0b5508e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <= ;wdec.ietf@gmail.c= om> wrote:
On 24 January 2014 10:41, Martin Bjorklund &= lt;mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmai= l.com> wrote:
>> There is another REST derived constraint that, I'm not sure li= nes up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to =A0to ret= ain
>> any client specific server context state. This would apply to reso= urce
>> locking (aka transactions)
>
> Can you be more specific? =A0AFAICT there are no such things in the > draft (anymore).

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should<= br> not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather = HTTP.



I think the NETCONF WG = is very likely to create NETCONF over HTTP,
and it will end up ju= st as bloated and over-engineered as NETCONF over SSH.
I hope the= temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,<= /div>
rather than forcing the client to deal with all the server option= s in NETCONF.
IMO these REST purity tests are a waste of time.


=A0
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
=A0

--001a11c2a8b017f0ab04f0b5508e-- From bclaise@cisco.com Fri Jan 24 06:40:36 2014 Return-Path: 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 B76E81A0187 for ; Fri, 24 Jan 2014 06:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 WW8og0drkShd for ; Fri, 24 Jan 2014 06:40:34 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id D93791A00F2 for ; Fri, 24 Jan 2014 06:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9204; q=dns/txt; s=iport; t=1390574433; x=1391784033; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=BUMIz9hiOmgW8qINJEwcZaB8ToFl/DKq1zVtFilBhRY=; b=iMz/0MSwb39R5QqmsR3hsRAtNkn6BNDvbyUdzJtrqmjHnKLIy9w9Tism 9AG7txBI0UG8k0cmjVRijoiuwBsrLJfbalQ5iUlXkvV+z7PwLw9JKh5BS RNOy+EVY6Sge56BRy6gJESBoaS0BX/NdOJtIMXx5suAUbrD3oDLq0rwPx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAL9s4lKQ/khR/2dsb2JhbABagww4vD1PgQsWdIIlAQEBAwEBAQFrCgEQCxgJFggHCQMCAQIBDwYfEQYBDAEFAgEBh20DCQgNwjINhVYTBIx2gSoKEQFQB4Q4BJY7gWyGR4YWhUGDLjuBNQ X-IronPort-AV: E=Sophos;i="4.95,712,1384300800"; d="scan'208,217";a="4134170" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 24 Jan 2014 14:40:32 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OEeVR5008927; Fri, 24 Jan 2014 14:40:31 GMT Message-ID: <52E27B5F.5070908@cisco.com> Date: Fri, 24 Jan 2014 15:40:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Bierman , Wojciech Dec References: <20140124.104128.739402048375968628.mbj@tail-f.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070703040407060300030004" Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 14:40:37 -0000 This is a multi-part message in MIME format. --------------070703040407060300030004 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, [Taking the last email in the thread.] The current proposed charter says: 5. Develop a_RESTful interface_ (RESTCONF) for accessing YANG data using the datastores defined in NETCONF. draft-bierman-netconf-restconf says: RESTCONF Protocol draft-bierman-netconf-restconf-03 Abstract This document describes a_RESTful protocol_ that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. Considering that ... 1. The motivation is really HTTP rather than REST design 2. Some REST principles are not respected ... this should be reflected in the charter (and as a consequence in the draft) The way I now understand RESTCONF is: RESTCONF = a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with _some _REST characteristics. If this is the case, both the proposed charter and the draft abstract are misleading. This should be corrected. Regards, Benoit > > > > On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec > wrote: > > On 24 January 2014 10:41, Martin Bjorklund > wrote: > > Wojciech Dec > > wrote: > >> There is another REST derived constraint that, I'm not sure > lines up > >> with what is being scoped here in terms of Netconf functional > >> equivalence: It is considered un RESTful for a server to to retain > >> any client specific server context state. This would apply to > resource > >> locking (aka transactions) > > > > Can you be more specific? AFAICT there are no such things in the > > draft (anymore). > > I'm not saying that it is there, but as per previous posts on this > thread, maybe resource locking should be there. I.e. "RESTCONF should > not deviate from the NETCONF capabilities unless proper justification > is provided and documented" . > To me it appears that REST style is not a key requirement here, > but rather HTTP. > > > > I think the NETCONF WG is very likely to create NETCONF over HTTP, > and it will end up just as bloated and over-engineered as NETCONF over > SSH. > I hope the temptation to expose all server complexity to the client > is resisted. IMO it would be better to keep the RESTCONF API unified, > rather than forcing the client to deal with all the server options in > NETCONF. > IMO these REST purity tests are a waste of time. > > > -W. > > > > >> and also client event subscriptions. > > > > Ok. > > > > > > /martin > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------070703040407060300030004 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

[Taking the last email in the thread.]

The current proposed charter says:
5. Develop a RESTful interface (RESTCONF) for accessing YANG data using the
datastores defined in NETCONF.

draft-bierman-netconf-restconf says:
  RESTCONF Protocol
                   draft-bierman-netconf-restconf-03

Abstract

   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

Considering that ...
    1. The motivation is really HTTP rather than REST design
    2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the draft)

The way I now understand RESTCONF is:
    RESTCONF =  a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.

If this is the case, both the proposed charter and the draft abstract are misleading.
This should be corrected.

Regards, Benoit



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
On 24 January 2014 10:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> There is another REST derived constraint that, I'm not sure lines up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to  to retain
>> any client specific server context state. This would apply to resource
>> locking (aka transactions)
>
> Can you be more specific?  AFAICT there are no such things in the
> draft (anymore).

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.



I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in NETCONF.
IMO these REST purity tests are a waste of time.


 
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
 



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--------------070703040407060300030004-- From andy@yumaworks.com Fri Jan 24 07:40:59 2014 Return-Path: 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 D5EEC1A00BE for ; Fri, 24 Jan 2014 07:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Yk0dEqOiu1oP for ; Fri, 24 Jan 2014 07:40:57 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5471A0021 for ; Fri, 24 Jan 2014 07:40:57 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so4493603qcz.41 for ; Fri, 24 Jan 2014 07:40:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sGdwmVNv14vHO8WegE8uJsjFq18w2Jch0h2irGBKV6Y=; b=SXcloXWwihfUNtPsBZDgIa7rjHhqTAsG6/v/lWqZUuWaCe/gQJtaIEWtz/IB0VGhEL 4pn+wwH2lSITr2xenfG0UzE+5dKnN6WWU/RFYlfZJcMaxwNkIOGxtaFoNVShxNrbpX1Q 8Gd5f/uHsLzspTwqZuxMSHa8XixEfROd1bq990F8wCb2bHu7lUeQyU5PBO9O3YVD++Px 27QiynpWbIs6aDc5a5g4th8tDvlF60Pzo+HW73bfQksxkSY6tp6OG62sWpCHLUCfS6Zz h7Zgoe4Y/WfRoEzB2h4ZT7kUx2fY+YcB5PniGxnYBzLvLJ2KpKmpniZptLHn1CBPHZMy 3ckw== X-Gm-Message-State: ALoCoQlsvmCBvLhlscYCOW+d/7jgvFs8G42csbkIelRL1GB1JkKeDboZEUplpl8fRPc6BuzTPwPD MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr20276297qgo.25.1390578056090; Fri, 24 Jan 2014 07:40:56 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 24 Jan 2014 07:40:55 -0800 (PST) In-Reply-To: <52E27B5F.5070908@cisco.com> References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> Date: Fri, 24 Jan 2014 07:40:55 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c154b610e78104f0b92f02 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:41:00 -0000 --001a11c154b610e78104f0b92f02 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise wrote: > Dear all, > > [Taking the last email in the thread.] > > The current proposed charter says: > > 5. Develop a *RESTful interface* (RESTCONF) for accessing YANG data using the > datastores defined in NETCONF. > > > draft-bierman-netconf-restconf says: > > RESTCONF Protocol > draft-bierman-netconf-restconf-03 > Abstract > > This document describes a *RESTful protocol* that provides a > programmatic interface over HTTP for accessing data defined in YANG, > using the datastores defined in NETCONF. > > > Considering that ... > 1. The motivation is really HTTP rather than REST design > 2. Some REST principles are not respected > ... this should be reflected in the charter (and as a consequence in the > draft) > > The way I now understand RESTCONF is: > RESTCONF = a protocol almost similar to NETCONF in terms of > capabilities, to access YANG modules over HTTP, with *some *REST > characteristics. > > If this is the case, both the proposed charter and the draft abstract are > misleading. > This should be corrected. > IMO the term "RESTful" is used just as consistently here as in other solutions. (E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a client needs to know all the ad-hoc docs to know the resource model. It is not discovered inline at all). We could downgrade the term to "REST-like"? Would that make the purists happy? We could call the protocol RESTLESS. Would that help? ;-) > > Regards, Benoit > Andy > > > > On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec wrote: > >> On 24 January 2014 10:41, Martin Bjorklund wrote: >> > Wojciech Dec wrote: >> >> There is another REST derived constraint that, I'm not sure lines up >> >> with what is being scoped here in terms of Netconf functional >> >> equivalence: It is considered un RESTful for a server to to retain >> >> any client specific server context state. This would apply to resource >> >> locking (aka transactions) >> > >> > Can you be more specific? AFAICT there are no such things in the >> > draft (anymore). >> >> I'm not saying that it is there, but as per previous posts on this >> thread, maybe resource locking should be there. I.e. "RESTCONF should >> not deviate from the NETCONF capabilities unless proper justification >> is provided and documented" . >> To me it appears that REST style is not a key requirement here, but >> rather HTTP. >> >> > > I think the NETCONF WG is very likely to create NETCONF over HTTP, > and it will end up just as bloated and over-engineered as NETCONF over SSH. > I hope the temptation to expose all server complexity to the client > is resisted. IMO it would be better to keep the RESTCONF API unified, > rather than forcing the client to deal with all the server options in > NETCONF. > IMO these REST purity tests are a waste of time. > > > > >> -W. >> >> > >> >> and also client event subscriptions. >> > >> > Ok. >> > >> > >> > /martin >> > > Andy > > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > --001a11c154b610e78104f0b92f02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
=20 =20 =20
Dear all,

[Taking the last email in the thread.]

The current proposed charter says:
5. Develop a RESTful interface (RESTCONF) for accessing=
 YANG data using the
datastores defined in NETCONF.

draft-bierman-netconf-restconf says:
  RESTCONF Protocol
                   draft-bierman-netconf-restconf-03

Abstract

   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

Considering that ...
=A0=A0=A0 1. The motivation is really HTTP rather than REST design
=A0=A0=A0 2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the draft)

The way I now understand RESTCONF is:
=A0=A0=A0 RESTCONF =3D=A0 a protocol almost s= imilar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.

If this is the case, both the proposed charter and the draft abstract are misleading.
This should be corrected.

=
IMO the term "RESTful" is used just as consistently here as = in other solutions.
(E.g., are there any HATEOAS mechanisms in Op= enStack? Seems to me a
client needs to know all the ad-hoc docs to know the resource model. I= t is
not discovered inline at all).

We c= ould downgrade the term to "REST-like"? =A0Would that make the pu= rists happy?
We could call the protocol RESTLESS. Would that help? ;-)
=A0

Regards, Benoit

Andy<= /div>
=A0
=20



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
On 24 January 2014 10:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> There is another REST derived constraint that, I'm not sure lines up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to =A0to retain
>> any client specific server context state. This would apply to resource
>> locking (aka transactions)
>
> Can you be more specific? =A0AFAICT there are no such things in the
> draft (anymore).

I'm not saying that it is there, but as per previous post= s on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.



I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in NETCONF.
IMO these REST purity tests are a waste of time.


=A0
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
=A0



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


--001a11c154b610e78104f0b92f02-- From bclaise@cisco.com Fri Jan 24 07:54:07 2014 Return-Path: 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 381B31A0021 for ; Fri, 24 Jan 2014 07:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 paYD-MbpxLlN for ; Fri, 24 Jan 2014 07:54:04 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5621A001E for ; Fri, 24 Jan 2014 07:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15225; q=dns/txt; s=iport; t=1390578843; x=1391788443; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=TV+FuL2o/iGEEwg8ufOiOk9PoR+2uQXGOqhvfko84SE=; b=hceAL5JSVTF2kTYmWn0smLkhUBBhJKsJzyaxD7lL7+w/rVOVra2ayte3 GXOgrvUzNWAx9NAQt+1MadKI9rKrJkPjREDAMXOvXFxQnQnM4Yugb1Jnx M+usre1+Id3RN53pyl8gABcbvduHQWv7YGOhoLo8z2j5knaCjE4pwzDvU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGyM4lKQ/khM/2dsb2JhbABagww4vD1PgQsWdIIlAQEBAwEBAQFrAQkBEAsYCRYIBwkDAgECAQ8GHxEGDQEFAgEBF4dWAwkIDcJODYVWEwSMdoEqChEBUAeEOASWO4FshkeGFoVBgy47gTU X-IronPort-AV: E=Sophos;i="4.95,713,1384300800"; d="scan'208,217";a="3467485" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 24 Jan 2014 15:53:54 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0OFrsU3029393; Fri, 24 Jan 2014 15:53:54 GMT Message-ID: <52E28C91.6040301@cisco.com> Date: Fri, 24 Jan 2014 16:53:53 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Bierman References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000808020207040501000803" Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 15:54:07 -0000 This is a multi-part message in MIME format. --------------000808020207040501000803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andy, You have to understand one part of my job, as OPS AD: defending your work in front the IESG, whether this is at the charter time, or at the document approval time. So I'm trying to see which questions will arise. I would hate it if somebody would say in a year from now: "hey, you're not actually defining a RESTful as specified in your charter. RESTful is specified according to principles XYZ, you're not compliant, you're out. Personally, I'm not married to any marketing names. Regards, Benoit > > > > On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise > wrote: > > Dear all, > > [Taking the last email in the thread.] > > The current proposed charter says: > > 5. Develop a_RESTful interface_ (RESTCONF) for accessing YANG data using the > datastores defined in NETCONF. > > > draft-bierman-netconf-restconf says: > > RESTCONF Protocol > draft-bierman-netconf-restconf-03 > > Abstract > > This document describes a_RESTful protocol_ that provides a > programmatic interface over HTTP for accessing data defined in YANG, > using the datastores defined in NETCONF. > > > Considering that ... > 1. The motivation is really HTTP rather than REST design > 2. Some REST principles are not respected > ... this should be reflected in the charter (and as a consequence > in the draft) > > The way I now understand RESTCONF is: > RESTCONF = a protocol almost similar to NETCONF in terms of > capabilities, to access YANG modules over HTTP, with _some _REST > characteristics. > > If this is the case, both the proposed charter and the draft > abstract are misleading. > This should be corrected. > > > IMO the term "RESTful" is used just as consistently here as in other > solutions. > (E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a > client needs to know all the ad-hoc docs to know the resource model. It is > not discovered inline at all). > > We could downgrade the term to "REST-like"? Would that make the > purists happy? > We could call the protocol RESTLESS. Would that help? ;-) > > > Regards, Benoit > > > Andy > >> >> >> >> On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec >> > wrote: >> >> On 24 January 2014 10:41, Martin Bjorklund > > wrote: >> > Wojciech Dec > > wrote: >> >> There is another REST derived constraint that, I'm not >> sure lines up >> >> with what is being scoped here in terms of Netconf functional >> >> equivalence: It is considered un RESTful for a server to >> to retain >> >> any client specific server context state. This would apply >> to resource >> >> locking (aka transactions) >> > >> > Can you be more specific? AFAICT there are no such things >> in the >> > draft (anymore). >> >> I'm not saying that it is there, but as per previous posts on >> this >> thread, maybe resource locking should be there. I.e. >> "RESTCONF should >> not deviate from the NETCONF capabilities unless proper >> justification >> is provided and documented" . >> To me it appears that REST style is not a key requirement >> here, but rather HTTP. >> >> >> >> I think the NETCONF WG is very likely to create NETCONF over HTTP, >> and it will end up just as bloated and over-engineered as NETCONF >> over SSH. >> I hope the temptation to expose all server complexity to the client >> is resisted. IMO it would be better to keep the RESTCONF API unified, >> rather than forcing the client to deal with all the server >> options in NETCONF. >> IMO these REST purity tests are a waste of time. >> >> >> -W. >> >> > >> >> and also client event subscriptions. >> > >> > Ok. >> > >> > >> > /martin >> >> >> Andy >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > --------------000808020207040501000803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Andy,

You have to understand one part of my job, as OPS AD: defending your work in front the IESG, whether this is at the charter time, or at the document approval time.
So I'm trying to see which questions will arise. I would hate it if somebody would say in a year from now: "hey, you're not actually defining a RESTful as specified in your charter. RESTful is specified according to principles XYZ, you're not compliant, you're out.

Personally, I'm not married to any marketing names.

Regards, Benoit






On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

[Taking the last email in the thread.]

The current proposed charter says:
5. Develop a RESTful interface (RESTCONF) for accessing YANG data using the
datastores defined in NETCONF.

draft-bierman-netconf-restconf says:
  RESTCONF Protocol
                   draft-bierman-netconf-restconf-03

Abstract

   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

Considering that ...
    1. The motivation is really HTTP rather than REST design
    2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the draft)

The way I now understand RESTCONF is:
    RESTCONF =  a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.

If this is the case, both the proposed charter and the draft abstract are misleading.
This should be corrected.

IMO the term "RESTful" is used just as consistently here as in other solutions.
(E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a
client needs to know all the ad-hoc docs to know the resource model. It is
not discovered inline at all).

We could downgrade the term to "REST-like"?  Would that make the purists happy?
We could call the protocol RESTLESS. Would that help? ;-)

 

Regards, Benoit

Andy
 



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
On 24 January 2014 10:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> There is another REST derived constraint that, I'm not sure lines up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to  to retain
>> any client specific server context state. This would apply to resource
>> locking (aka transactions)
>
> Can you be more specific?  AFAICT there are no such things in the
> draft (anymore).

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.



I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in NETCONF.
IMO these REST purity tests are a waste of time.


 
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
 



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



--------------000808020207040501000803-- From andy@yumaworks.com Fri Jan 24 08:08:48 2014 Return-Path: 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 0F3F51A03EF for ; Fri, 24 Jan 2014 08:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 1acnTZP-fyKC for ; Fri, 24 Jan 2014 08:08:45 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7450E1A001E for ; Fri, 24 Jan 2014 08:08:45 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so4649271qcz.27 for ; Fri, 24 Jan 2014 08:08:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HnJhnLA4FbaKhGEJEwcowzGJnbwxH+UJsB+Qp2xY9Ks=; b=U/El73J+muhdxFcpJp0mIFREn3Ka/fuRlFDXOAIarTTBGhaqg7gOvq+JLCW/2M+bDZ 1QhjnGCqxteuRWb+G19mh/6RKktr0+GiIldYdrRoEZPV1VuTuADO3oKVogwu+Ig81MU0 YPGhi75JVTmxf+Ar/RQfBxlr0NeecXz/bxB3ofASelmICnZrUkICmIZmqDrVPNtfmLr3 N4cfYNPPzEhQPG9rNw5oKnAUB5mHPESiqfvCAtIwOYwN/focdBjZtgtE56LEZNiJ5aja OBV6IOH+ZeKGC370v7bVi/3KZmFd9qeDYyiUaTJ1OhJAxx1TXLo/a4mDNl7j9tMW6OiH 173w== X-Gm-Message-State: ALoCoQkfQ+ANMH/aPnuSf9uVi8s9E8EIFIbu1vhGwERWbvU/pchfHqyPrZNQ5Ri6nb8FhluD1d/o MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr20503610qgo.25.1390579723886; Fri, 24 Jan 2014 08:08:43 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 24 Jan 2014 08:08:43 -0800 (PST) In-Reply-To: <52E28C91.6040301@cisco.com> References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <52E28C91.6040301@cisco.com> Date: Fri, 24 Jan 2014 08:08:43 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c154b6796bc304f0b9924f Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 16:08:48 -0000 --001a11c154b6796bc304f0b9924f Content-Type: text/plain; charset=ISO-8859-1 Hi, I understand. However, when it was called YANG-API, many people commented "Why isn't it called RESTCONF? You are doing REST" IMO, all REST will use schema-based content eventually. There seems to be a growing realization that hand-crafted code based on ad-hoc API documentation is not as desirable as auto-generated code based on an easy-to-use schema language. So what is the new name if RESTCONF is out? Andy On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise wrote: > Andy, > > You have to understand one part of my job, as OPS AD: defending your work > in front the IESG, whether this is at the charter time, or at the document > approval time. > So I'm trying to see which questions will arise. I would hate it if > somebody would say in a year from now: "hey, you're not actually defining a > RESTful as specified in your charter. RESTful is specified according to > principles XYZ, you're not compliant, you're out. > > Personally, I'm not married to any marketing names. > > Regards, Benoit > > > > > > > On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise wrote: > >> Dear all, >> >> [Taking the last email in the thread.] >> >> The current proposed charter says: >> >> 5. Develop a *RESTful interface* (RESTCONF) for accessing YANG data using the >> datastores defined in NETCONF. >> >> >> draft-bierman-netconf-restconf says: >> >> RESTCONF Protocol >> draft-bierman-netconf-restconf-03 >> Abstract >> >> This document describes a *RESTful protocol* that provides a >> programmatic interface over HTTP for accessing data defined in YANG, >> using the datastores defined in NETCONF. >> >> >> Considering that ... >> 1. The motivation is really HTTP rather than REST design >> 2. Some REST principles are not respected >> ... this should be reflected in the charter (and as a consequence in the >> draft) >> >> The way I now understand RESTCONF is: >> RESTCONF = a protocol almost similar to NETCONF in terms of >> capabilities, to access YANG modules over HTTP, with *some *REST >> characteristics. >> >> If this is the case, both the proposed charter and the draft abstract are >> misleading. >> This should be corrected. >> > > IMO the term "RESTful" is used just as consistently here as in other > solutions. > (E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a > client needs to know all the ad-hoc docs to know the resource model. It is > not discovered inline at all). > > We could downgrade the term to "REST-like"? Would that make the purists > happy? > We could call the protocol RESTLESS. Would that help? ;-) > > > >> >> Regards, Benoit >> > > Andy > > >> >> >> >> On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec wrote: >> >>> On 24 January 2014 10:41, Martin Bjorklund wrote: >>> > Wojciech Dec wrote: >>> >> There is another REST derived constraint that, I'm not sure lines up >>> >> with what is being scoped here in terms of Netconf functional >>> >> equivalence: It is considered un RESTful for a server to to retain >>> >> any client specific server context state. This would apply to resource >>> >> locking (aka transactions) >>> > >>> > Can you be more specific? AFAICT there are no such things in the >>> > draft (anymore). >>> >>> I'm not saying that it is there, but as per previous posts on this >>> thread, maybe resource locking should be there. I.e. "RESTCONF should >>> not deviate from the NETCONF capabilities unless proper justification >>> is provided and documented" . >>> To me it appears that REST style is not a key requirement here, but >>> rather HTTP. >>> >>> >> >> I think the NETCONF WG is very likely to create NETCONF over HTTP, >> and it will end up just as bloated and over-engineered as NETCONF over >> SSH. >> I hope the temptation to expose all server complexity to the client >> is resisted. IMO it would be better to keep the RESTCONF API unified, >> rather than forcing the client to deal with all the server options in >> NETCONF. >> IMO these REST purity tests are a waste of time. >> >> >> >> >>> -W. >>> >>> > >>> >> and also client event subscriptions. >>> > >>> > Ok. >>> > >>> > >>> > /martin >>> >> >> Andy >> >> >> >> >> _______________________________________________ >> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >> >> >> > > --001a11c154b6796bc304f0b9924f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I understand.
However, wh= en it was called YANG-API, many people commented
"Why isn= 9;t it called RESTCONF? You are doing REST"

IMO, all REST will use schema-based content eventually.
There see= ms to be a growing realization that hand-crafted code
based on ad= -hoc API documentation is not as desirable as
auto-generated code= based on an easy-to-use schema language.

So what is the new name if RESTCONF is out?
<= br>

Andy


<= br>


On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise <bclaise@cisco.com><= /span> wrote:
=20 =20 =20
Andy,

You have to understand one part of my job, as OPS AD: defending your work in front the IESG, whether this is at the charter time, or at the document approval time.
So I'm trying to see which questions will arise. I would hate it if somebody would say in a year from now: "hey, you're not actually defining a RESTful as specified in your charter. RESTful is specified according to principles XYZ, you're not compliant, you're out.

Personally, I'm not married to any marketing names.

Regards, Benoit



=20



On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

[Taking the last email in the thread.]

The current proposed charter says:
5. Develop a RESTful interface (RESTCONF) f=
or accessing YANG data using the
datastores defined in NETCONF.

draft-bierman-netconf-restconf says:
  RESTCONF Protocol
                   draft-bierman-netconf-restconf-03

Abstract

   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

Considering that ...
=A0=A0=A0 1. The motivation is really HTTP rather than RE= ST design
=A0=A0=A0 2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the draft)

The way I now understand RESTCONF is:
=A0=A0=A0 RESTCONF =3D=A0 a proto= col almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.

If this is the case, both the proposed charter and the draft abstract are misleading.
This should be corrected.

IMO the term "RESTful" is used just as consisten= tly here as in other solutions.
(E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a
client needs to know all the ad-hoc docs to know the resource model. It is
not discovered inline at all).

We could downgrade the term to "REST-like"? =A0W= ould that make the purists happy?
We could call the protocol RESTLESS. Would that help? ;-)

=A0

Regards, Benoit

Andy
=A0



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <wdec.ietf@gmail.com&g= t; wrote:
On 24 January 2014 10:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> There is another REST derived constraint that, I'm not sure lines up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to =A0to retain
>> any client specific server context state. This would apply to resource
>> locking (aka transactions)
>
> Can you be more specific? =A0AFAICT there are no such things in the
> draft (anymore).

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.



I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in NETCONF.
IMO these REST purity tests are a waste of time.


=A0
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
=A0



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf




--001a11c154b6796bc304f0b9924f-- From j.schoenwaelder@jacobs-university.de Fri Jan 24 09:21:18 2014 Return-Path: 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 87AD31A004B for ; Fri, 24 Jan 2014 09:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 ptt6e3U2pjgU for ; Fri, 24 Jan 2014 09:21:17 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C71EE1A0047 for ; Fri, 24 Jan 2014 09:21:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 622832003A; Fri, 24 Jan 2014 18:21:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HZ4vBCrOiDl3; Fri, 24 Jan 2014 18:21:15 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6429C20064; Fri, 24 Jan 2014 18:21:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id ACA292ACD59B; Fri, 24 Jan 2014 18:21:12 +0100 (CET) Date: Fri, 24 Jan 2014 18:21:12 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140124172112.GA63277@elstar.local> Mail-Followup-To: Andy Bierman , Benoit Claise , Netconf References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:21:18 -0000 On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote: > We could downgrade the term to "REST-like"? Would that make the > purists happy? I would indeed find that more appropriate. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Fri Jan 24 09:25:10 2014 Return-Path: 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 470ED1A0069 for ; Fri, 24 Jan 2014 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 MCamtkpKTSfm for ; Fri, 24 Jan 2014 09:25:08 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id A12421A0045 for ; Fri, 24 Jan 2014 09:25:08 -0800 (PST) Received: from mail190-ch1-R.bigfish.com (10.43.68.231) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 17:25:07 +0000 Received: from mail190-ch1 (localhost [127.0.0.1]) by mail190-ch1-R.bigfish.com (Postfix) with ESMTP id 3C2ED3E021A; Fri, 24 Jan 2014 17:25:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h1155h) Received-SPF: pass (mail190-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(479174003)(377454003)(24454002)(189002)(199002)(4396001)(47446002)(79102001)(65816001)(31966008)(74502001)(2656002)(92566001)(80976001)(19580405001)(83322001)(87936001)(19580395003)(81686001)(81816001)(50986001)(47976001)(80022001)(77982001)(66066001)(47736001)(85306002)(81542001)(94316002)(87266001)(59766001)(63696002)(74662001)(74366001)(49866001)(81342001)(74876001)(69226001)(36756003)(86362001)(76796001)(76786001)(93516002)(85852003)(83072002)(93136001)(90146001)(56816005)(51856001)(92726001)(77096001)(83506001)(46102001)(54316002)(53806001)(76482001)(54356001)(56776001)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail190-ch1 (localhost.localdomain [127.0.0.1]) by mail190-ch1 (MessageSwitch) id 1390584305955181_25942; Fri, 24 Jan 2014 17:25:05 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.254]) by mail190-ch1.bigfish.com (Postfix) with ESMTP id DB22D340047; Fri, 24 Jan 2014 17:25:05 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 17:25:05 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 17:25:05 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.859.15; Fri, 24 Jan 2014 17:25:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) with mapi id 15.00.0859.013; Fri, 24 Jan 2014 17:25:02 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Andy Bierman Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHF39qA///0OICAAdlIAIAACgYAgAnd3YCAAA+GgIACWEuAgAAPdQCAAAl9AIAAEoIAgAFq7QD//6ruoIAAs9MAgAD7QYCAAAENAIAAC3QAgAALjwCAADyKgIAAEOCAgAAcBQD//607gA== Date: Fri, 24 Jan 2014 17:25:02 +0000 Message-ID: References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <20140124172112.GA63277@elstar.local> In-Reply-To: <20140124172112.GA63277@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.13] x-forefront-prvs: 01018CB5B3 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 17:25:10 -0000 On 1/24/14 12:21 PM, "Juergen Schoenwaelder" wrote: >On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote: >=20 >> We could downgrade the term to "REST-like"? Would that make the >> purists happy? > >I would indeed find that more appropriate. +1 if only to help put this to rest - get it, rest ;) K. From andy@yumaworks.com Fri Jan 24 10:03:31 2014 Return-Path: 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 2C9891A00AF for ; Fri, 24 Jan 2014 10:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 LftCbB0O_RQu for ; Fri, 24 Jan 2014 10:03:28 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 973F21A0047 for ; Fri, 24 Jan 2014 10:03:28 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id n7so4810966qcx.16 for ; Fri, 24 Jan 2014 10:03:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2xoLUihBce+ZJQPrVs3vqv4mrsLfPhnG9wOaysqSlkU=; b=TCsybPpLf0qECqza6ukodswY1GlHluP2LrPCeGJAuTIgXkqw9TkUdY8LFYC/rRwE1B NyE0fH2scX4Peh68ItNR6+7gZtBVr/kCcuY+7H+uGQfyc5css6KOK79ckFx8TJHlSk4U vl/2JaCvTH9vYtxRsi4nUR7vR8+E/cqcotCCIx2i3Bk+i82FOmHN+k137YL77F77Yay8 AJ0kzXUo5lp8yRfQk1aps/ZVN4X1iOT575YbU8bGu++5HvXW+Xdb3muQa4TyuCp0drkG 3MUm6M+V/qEk2I1UNfLROPZD1Gp/Rjg5rca/t2MYy1nvYQBihEE97DwI3r930IsQgyZr eZ0Q== X-Gm-Message-State: ALoCoQltVTWk46R3uYx+zprY2Nf3QgzjCSYFrUlkmiyf7rQsuIRSU7iYmc+AlW2c6nNBS/8qTJL1 MIME-Version: 1.0 X-Received: by 10.140.36.107 with SMTP id o98mr21417193qgo.25.1390586607305; Fri, 24 Jan 2014 10:03:27 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 24 Jan 2014 10:03:27 -0800 (PST) In-Reply-To: References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <20140124172112.GA63277@elstar.local> Date: Fri, 24 Jan 2014 10:03:27 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c154b6c2183604f0bb2c60 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:03:31 -0000 --001a11c154b6c2183604f0bb2c60 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 24, 2014 at 9:25 AM, Kent Watsen wrote: > > > > On 1/24/14 12:21 PM, "Juergen Schoenwaelder" > wrote: > > >On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote: > > > >> We could downgrade the term to "REST-like"? Would that make the > >> purists happy? > > > >I would indeed find that more appropriate. > > > +1 if only to help put this to rest - get it, rest ;) > > I updated the draft in the SVN repo -- s/RESTful/REST-like/ K. > > Andy --001a11c154b6c2183604f0bb2c60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Jan 24, 2014 at 9:25 AM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:



On 1/24/14 12:21 PM, "Juergen Schoenwaelder"
<j.schoenwaelder= @jacobs-university.de> wrote:

>On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote:
>
>> We could downgrade the term to "REST-like"? =A0Would tha= t make the
>> purists happy?
>
>I would indeed find that more appropriate.


+1 if only to help put this to rest =A0 - get it, rest =A0;)


I updated the draft in the SVN repo -- s/RESTful/RES= T-like/=A0


K.


Andy
=A0=
--001a11c154b6c2183604f0bb2c60-- From alex@cisco.com Fri Jan 24 10:40:59 2014 Return-Path: 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 38AF71A0028 for ; Fri, 24 Jan 2014 10:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 yk_9p1tFEcj2 for ; Fri, 24 Jan 2014 10:40:56 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B01A0015 for ; Fri, 24 Jan 2014 10:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8813; q=dns/txt; s=iport; t=1390588855; x=1391798455; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=70MMDJoUo9zR6FZ2jxZRKwj18XAcogvuE5IXe8vqogY=; b=OtM/cfxlv6ZMKc156mQICihosu+i/KnLzYvnNTOvWoi1g36Evi/rhReI Y5jiwDimZlXo9C6cxDRphyoehk0CzrgtJILrlmxa+UtlcBBvPnovVMng9 ijK8rA2wZnegF2YGwDM0rIeLp4/wzZ7/84fxAh3CGoLkWLNnTMeXokd0u I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFABez4lKtJV2Y/2dsb2JhbABagkhEOFa8NYENFnSCJQEBAQQtTBACAQgQAQQBAQEKHQcyFAkIAgQBDQUIDIdxyEQXjlsxBgGDJIEUBKpFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208,217";a="15335041" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 24 Jan 2014 18:40:54 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0OIesM7022708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 Jan 2014 18:40:54 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 24 Jan 2014 12:40:54 -0600 From: "Alexander Clemm (alex)" To: Andy Bierman , Kent Watsen Thread-Topic: [Netconf] Netconf Charter update for approval Thread-Index: Ac8JSaLfpP6VhgTaTqqEeO6YJvQi8AHScoCAAAkAnYAAMK97AAABQKwAATu7oIAAAfDOgABLCWOAAAHukQAAAS+wAAACUCwAADfX4AAAADfhgAABJgAAAB9oOYAAACGHAAABbpEAAAFx2QAAB5FNgAACHASAAAOAmwAAACJGAAABV3iAAAuWQnA= Date: Fri, 24 Jan 2014 18:40:54 +0000 Message-ID: References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <20140124172112.GA63277@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.212.14] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571866A8A3xmbrcdx05ciscoc_" MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 18:40:59 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571866A8A3xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rereading the charter again, I have one question re the 5th bullet point, = specifically "and also allow more precise client control of the transaction= procedure than existing mechanisms" What is meant by that? "Existing mechanisms" presumably refers to Netconf -= why not call it out? "More precise client control" - does this mean addit= ional capabilities not provided by Netconf - i.e. not ReST, not Netconf Lit= e, but actually Netconf++ / Heavy? I don't think this is what is meant, an= d it does mean in fact "lighter than Netconf, with more responsibilities to= control transactions (if that is needed) shifted to clients". However, it= could be interpreted this way, and is ambiguous. The goals of RESTconf, n= ot very clear to begin with (address different community of (Web) developer= s? Add another transport to Netconf operations? Provide a subset of servi= ces for lighterweight agent implementations in more constrained environment= s?) gets obscured a little further. I would suggest rephrasing to clarify = and disambiguate. --- Alex From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Friday, January 24, 2014 10:03 AM To: Kent Watsen Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval On Fri, Jan 24, 2014 at 9:25 AM, Kent Watsen > wrote: On 1/24/14 12:21 PM, "Juergen Schoenwaelder" > wrote: >On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote: > >> We could downgrade the term to "REST-like"? Would that make the >> purists happy? > >I would indeed find that more appropriate. +1 if only to help put this to rest - get it, rest ;) I updated the draft in the SVN repo -- s/RESTful/REST-like/ K. Andy --_000_DBC595ED2346914F9F81D17DD5C32B571866A8A3xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Rereading the charter again, I have one que=
stion re  the 5th bullet point, specifically “=
and also allow more precise client control of the transaction procedure tha=
n existing mechanisms”

 


What is meant by that? “Existing mech=
anisms” presumably refers to Netconf – why not call it out?&nbs=
p; “More precise client control” – does this mean additio=
nal capabilities not provided by Netconf – i.e. not ReST, not Netconf=
 Lite, but actually Netconf++ / Heavy?  I don’t think th=
is is what is meant, and it does mean in fact “lighter than Netconf, =
with more responsibilities to control transactions (if that is needed) shif=
ted to clients”.  However, it could be interpreted this way, and=
 is ambiguous.  The goals of RESTconf, not very clear to begin with (a=
ddress different community of (Web) developers?  Add another transport=
 to Netconf operations?  Provide a subset of services for lighterweigh=
t agent implementations in more constrained environments?) gets obscured a =
little further.  I would suggest rephrasing to clarify and disambiguat=
e.  


 


--- Alex


 <=
/p>

From: Netconf =
[mailto:netconf-bounces@ietf.org]
On Behalf Of Andy Bierman

Sent: Friday, January 24, 2014 10:03 AM

To: Kent Watsen

Cc: Netconf

Subject: Re: [Netconf] Netconf Charter update for approval


 




 




 




On Fri, Jan 24, 2014 at 9:25 AM, Kent Watsen <kwatsen@juniper.net> wrote:








On 1/24/14 12:21 PM, "Juergen Schoenwaelder"

<j.schoenwaelder=
@jacobs-university.de> wrote:



>On Fri, Jan 24, 2014 at 07:40:55AM -0800, Andy Bierman wrote:

>

>> We could downgrade the term to "REST-like"?  Would =
that make the

>> purists happy?

>

>I would indeed find that more appropriate.





+1 if only to help put this to rest   - get it, rest  ;)=





 






I updated the draft in the SVN repo -- s/RESTful/RES=
T-like/ 






 






 






K.






 






Andy






 
--_000_DBC595ED2346914F9F81D17DD5C32B571866A8A3xmbrcdx05ciscoc_-- From andy@yumaworks.com Fri Jan 24 11:45:50 2014 Return-Path: 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 1B5381A0033 for ; Fri, 24 Jan 2014 11:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ZSigHycLGfCC for ; Fri, 24 Jan 2014 11:45:48 -0800 (PST) Received: from mail-gg0-f177.google.com (mail-gg0-f177.google.com [209.85.161.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFFB1A001A for ; Fri, 24 Jan 2014 11:45:48 -0800 (PST) Received: by mail-gg0-f177.google.com with SMTP id f4so1227087ggn.22 for ; Fri, 24 Jan 2014 11:45:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZhjidW+N44VLe7tWAUmsFAWdOo2tCboCcKnLIgi+pvQ=; b=V26pdqPjnTrnUR1LAwSflsqmsgqIvipBMf0XkwMBcgeujyGV3OBsL5xVHG/dmYDQq5 qHVjfsOMg0sX+CpYxntsKyth3I5IYEGhG2h1EPrD/qs/1Ma2eqUz6mdtvgC8IK2pZYkX +KsGkOqZvMaXCMuULmAlz5ZROR3rbYC2Zz7ITcwjU5NxZsKEHJexKFiG0AxCVogApfW5 8b2uB3PkDB8YTYg9ODelLOGpXFO0wsioyDbPMgmKlq7FqW7OsREB+xqsOdznkMp1mmbF TuWgOYZdSqwd50j0DOtKPiCsLQboV0yOjnJ/ErbaqRMduTayxFC513Ziii/1+PHEf74p KiBQ== X-Gm-Message-State: ALoCoQnPOek3JTqfE4aikiXTT5wKsXHRRsNdYkJNp+pnOrnhwECVF6drOrbBGQWig1F5JcQqjchU MIME-Version: 1.0 X-Received: by 10.236.150.45 with SMTP id y33mr1593606yhj.124.1390592746547; Fri, 24 Jan 2014 11:45:46 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 24 Jan 2014 11:45:46 -0800 (PST) In-Reply-To: References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <20140124172112.GA63277@elstar.local> Date: Fri, 24 Jan 2014 11:45:46 -0800 Message-ID: From: Andy Bierman To: "Alexander Clemm (alex)" Content-Type: multipart/alternative; boundary=20cf303a3231afbb3604f0bc9abb Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 19:45:50 -0000 --20cf303a3231afbb3604f0bc9abb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Fri, Jan 24, 2014 at 10:40 AM, Alexander Clemm (alex) wr= ote: > Rereading the charter again, I have one question re the 5th bullet poin= t, specifically =93and also allow more precise client control of the transa= ction procedure than existing mechanisms=94 > > > > What is meant by that? =93Existing mechanisms=94 presumably refers to Net= conf =96 why not call it out? =93More precise client control=94 =96 does t= his mean additional capabilities not provided by Netconf =96 i.e. not ReST,= not Netconf Lite, but actually Netconf++ / Heavy? I don=92t think this is= what is meant, and it does mean in fact =93lighter than Netconf, with more= responsibilities to control transactions (if that is needed) shifted to cl= ients=94. However, it could be interpreted this way, and is ambiguous. Th= e goals of RESTconf, not very clear to begin with (address different commun= ity of (Web) developers? Add another transport to Netconf operations? Pro= vide a subset of services for lighterweight agent implementations in more c= onstrained environments?) gets obscured a little further. I would suggest = rephrasing to clarify and disambiguate. > > > > This might refer to YANG Patch. It has: * an explicit operation for "move" that do not require a clone of the entire subtree being moved. * an ordered list of edits. NETCONF subtrees can be processed in any order by the server. RESTCONF has: * if-match entity-matching to help prevent edit collision problems I hope NETCONF-EX will be standardized so NETCONF will also have these features. --- Alex > > Andy --20cf303a3231afbb3604f0bc9abb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

On Fri, Jan 24, 2014 at 10:40 AM, Alexander Clemm (alex)= <= alex@cisco.com> wrote:
Rereading the charter again, I have one question re =A0the 5th bullet point, specifically =93and also allow more precis=
e client control of the transaction procedure than existing mechanisms=94
=A0
What is meant by that? =93Existing mechanisms=94 presumably re=
fers to Netconf =96 why not call it out?=A0 =93More precise client control=
=94 =96 does this mean additional capabilities not provided by Netconf =96 =
i.e. not ReST, not Netconf Lite, but actually Netconf++ / Heavy?=A0 I don=
=92t think this is what is meant, and it does mean in fact =93lighter than =
Netconf, with more responsibilities to control transactions (if that is nee=
ded) shifted to clients=94.=A0 However, it could be interpreted this way, a=
nd is ambiguous.=A0 The goals of RESTconf, not very clear to begin with (ad=
dress different community of (Web) developers?=A0 Add another transport to =
Netconf operations?=A0 Provide a subset of services for lighterweight agent=
 implementations in more constrained environments?) gets obscured a little =
further.=A0 I would suggest rephrasing to clarify and disambiguate.=A0 <=
/u>
=A0

This might refer to YANG Patch. It has:
=A0 =A0* an explici= t operation for "move" that do not require
=A0 =A0 =A0a clone of the entire subtree being moved.
=A0 = =A0* an ordered list of edits. =A0NETCONF <config> subtrees can
=
=A0 =A0 =A0be processed in any order by the server.

RESTCONF has:
=A0 =A0* if-match entity-matching to help prevent edit collision probl= ems

I ho= pe NETCONF-EX will be standardized so NETCONF will also
=A0have these features.

--- Alex

<= div>Andy
=A0
--20cf303a3231afbb3604f0bc9abb-- From bclaise@cisco.com Mon Jan 27 02:14:59 2014 Return-Path: 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 586081A01E1 for ; Mon, 27 Jan 2014 02:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 L0vvVy2Qq12t for ; Mon, 27 Jan 2014 02:14:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD891A0186 for ; Mon, 27 Jan 2014 02:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21774; q=dns/txt; s=iport; t=1390817693; x=1392027293; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=yexnIwHqAd4KZbMCNh3o3Swlcg0UAlca3VZ+Noj4mag=; b=mk8KwOJkW9H6rye4YQVXly16r/ELdToc4Py0UZiByL6GNoPZFpKBju4e +MwE+rpjt4Doc/BavhrpYF4l3E56lYMzIulKctACU6Co/zGHJZR45JF5e tV2TpKCFlBCDrA/OB4204tVxBFixS7FkgbQqiWMZltWLfpsWibmMkc5tS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FADgx5lKQ/khM/2dsb2JhbABZgww4vFpPgQoWdIIlAQEBAwEBAQFrAQkBEAsYCRYBBwcJAwIBAgEPBh8RBg0BBQIBAReHVgMJCA3CRw2FVhMEjHeBKgoRAVAHhDgEljuBbIZHhhaFQYMuO4E1 X-IronPort-AV: E=Sophos;i="4.95,728,1384300800"; d="scan'208,217";a="3567304" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 27 Jan 2014 10:14:52 +0000 Received: from [10.61.172.28] ([10.61.172.28]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0RAEpsg007374; Mon, 27 Jan 2014 10:14:52 GMT Message-ID: <52E6319C.7080502@cisco.com> Date: Mon, 27 Jan 2014 11:14:52 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andy Bierman References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <52E28C91.6040301@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020301000408080402080006" Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 10:14:59 -0000 This is a multi-part message in MIME format. --------------020301000408080402080006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 24/01/2014 17:08, Andy Bierman wrote: > Hi, > > I understand. > However, when it was called YANG-API, many people commented > "Why isn't it called RESTCONF? You are doing REST" > > IMO, all REST will use schema-based content eventually. > There seems to be a growing realization that hand-crafted code > based on ad-hoc API documentation is not as desirable as > auto-generated code based on an easy-to-use schema language. > > So what is the new name if RESTCONF is out? Personally, I have no problem with the RESTCONF name, as long as we make clear in charter and drafts, stressing "some" RESTCONF = a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with _some _REST characteristics. Regards, Benoit > > > Andy > > > > > > On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise > wrote: > > Andy, > > You have to understand one part of my job, as OPS AD: defending > your work in front the IESG, whether this is at the charter time, > or at the document approval time. > So I'm trying to see which questions will arise. I would hate it > if somebody would say in a year from now: "hey, you're not > actually defining a RESTful as specified in your charter. RESTful > is specified according to principles XYZ, you're not compliant, > you're out. > > Personally, I'm not married to any marketing names. > > Regards, Benoit > > > >> >> >> >> On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise > > wrote: >> >> Dear all, >> >> [Taking the last email in the thread.] >> >> The current proposed charter says: >> >> 5. Develop a_RESTful interface_ (RESTCONF) for accessing YANG data using the >> datastores defined in NETCONF. >> >> >> draft-bierman-netconf-restconf says: >> >> RESTCONF Protocol >> draft-bierman-netconf-restconf-03 >> >> Abstract >> >> This document describes a_RESTful protocol_ that provides a >> programmatic interface over HTTP for accessing data defined in YANG, >> using the datastores defined in NETCONF. >> >> >> Considering that ... >> 1. The motivation is really HTTP rather than REST design >> 2. Some REST principles are not respected >> ... this should be reflected in the charter (and as a >> consequence in the draft) >> >> The way I now understand RESTCONF is: >> RESTCONF = a protocol almost similar to NETCONF in terms of >> capabilities, to access YANG modules over HTTP, with _some >> _REST characteristics. >> >> If this is the case, both the proposed charter and the draft >> abstract are misleading. >> This should be corrected. >> >> >> IMO the term "RESTful" is used just as consistently here as in >> other solutions. >> (E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a >> client needs to know all the ad-hoc docs to know the resource >> model. It is >> not discovered inline at all). >> >> We could downgrade the term to "REST-like"? Would that make the >> purists happy? >> We could call the protocol RESTLESS. Would that help? ;-) >> >> >> Regards, Benoit >> >> >> Andy >> >>> >>> >>> >>> On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec >>> > wrote: >>> >>> On 24 January 2014 10:41, Martin Bjorklund >>> > wrote: >>> > Wojciech Dec >> > wrote: >>> >> There is another REST derived constraint that, I'm >>> not sure lines up >>> >> with what is being scoped here in terms of Netconf >>> functional >>> >> equivalence: It is considered un RESTful for a server >>> to to retain >>> >> any client specific server context state. This would >>> apply to resource >>> >> locking (aka transactions) >>> > >>> > Can you be more specific? AFAICT there are no such >>> things in the >>> > draft (anymore). >>> >>> I'm not saying that it is there, but as per previous >>> posts on this >>> thread, maybe resource locking should be there. I.e. >>> "RESTCONF should >>> not deviate from the NETCONF capabilities unless proper >>> justification >>> is provided and documented" . >>> To me it appears that REST style is not a key >>> requirement here, but rather HTTP. >>> >>> >>> >>> I think the NETCONF WG is very likely to create NETCONF over >>> HTTP, >>> and it will end up just as bloated and over-engineered as >>> NETCONF over SSH. >>> I hope the temptation to expose all server complexity to the >>> client >>> is resisted. IMO it would be better to keep the RESTCONF API >>> unified, >>> rather than forcing the client to deal with all the server >>> options in NETCONF. >>> IMO these REST purity tests are a waste of time. >>> >>> >>> -W. >>> >>> > >>> >> and also client event subscriptions. >>> > >>> > Ok. >>> > >>> > >>> > /martin >>> >>> >>> Andy >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> > > --------------020301000408080402080006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 24/01/2014 17:08, Andy Bierman wrote:
Hi,

I understand.
However, when it was called YANG-API, many people commented
"Why isn't it called RESTCONF? You are doing REST"

IMO, all REST will use schema-based content eventually.
There seems to be a growing realization that hand-crafted code
based on ad-hoc API documentation is not as desirable as
auto-generated code based on an easy-to-use schema language.

So what is the new name if RESTCONF is out?
Personally, I have no problem with the RESTCONF name, as long as we make clear in charter and drafts, stressing "some"
RESTCONF =  a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.
Regards, Benoit



Andy





On Fri, Jan 24, 2014 at 7:53 AM, Benoit Claise <bclaise@cisco.com> wrote:
Andy,

You have to understand one part of my job, as OPS AD: defending your work in front the IESG, whether this is at the charter time, or at the document approval time.
So I'm trying to see which questions will arise. I would hate it if somebody would say in a year from now: "hey, you're not actually defining a RESTful as specified in your charter. RESTful is specified according to principles XYZ, you're not compliant, you're out.

Personally, I'm not married to any marketing names.

Regards, Benoit






On Fri, Jan 24, 2014 at 6:40 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

[Taking the last email in the thread.]

The current proposed charter says:
5. Develop a RESTful interface (RESTCONF) for accessing YANG data using the
datastores defined in NETCONF.

draft-bierman-netconf-restconf says:
  RESTCONF Protocol
                   draft-bierman-netconf-restconf-03

Abstract

   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.

Considering that ...
    1. The motivation is really HTTP rather than REST design
    2. Some REST principles are not respected
... this should be reflected in the charter (and as a consequence in the draft)

The way I now understand RESTCONF is:
    RESTCONF =  a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.

If this is the case, both the proposed charter and the draft abstract are misleading.
This should be corrected.

IMO the term "RESTful" is used just as consistently here as in other solutions.
(E.g., are there any HATEOAS mechanisms in OpenStack? Seems to me a
client needs to know all the ad-hoc docs to know the resource model. It is
not discovered inline at all).

We could downgrade the term to "REST-like"?  Would that make the purists happy?
We could call the protocol RESTLESS. Would that help? ;-)

 

Regards, Benoit

Andy
 



On Fri, Jan 24, 2014 at 2:22 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
On 24 January 2014 10:41, Martin Bjorklund <mbj@tail-f.com> wrote:
> Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> There is another REST derived constraint that, I'm not sure lines up
>> with what is being scoped here in terms of Netconf functional
>> equivalence: It is considered un RESTful for a server to  to retain
>> any client specific server context state. This would apply to resource
>> locking (aka transactions)
>
> Can you be more specific?  AFAICT there are no such things in the
> draft (anymore).

I'm not saying that it is there, but as per previous posts on this
thread, maybe resource locking should be there. I.e. "RESTCONF should
not deviate from the NETCONF capabilities unless proper justification
is provided and documented" .
To me it appears that REST style is not a key requirement here, but rather HTTP.



I think the NETCONF WG is very likely to create NETCONF over HTTP,
and it will end up just as bloated and over-engineered as NETCONF over SSH.
I hope the temptation to expose all server complexity to the client
is resisted. IMO it would be better to keep the RESTCONF API unified,
rather than forcing the client to deal with all the server options in NETCONF.
IMO these REST purity tests are a waste of time.


 
-W.

>
>> and also client event subscriptions.
>
> Ok.
>
>
> /martin

Andy
 



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf





--------------020301000408080402080006-- From andy@yumaworks.com Mon Jan 27 08:45:11 2014 Return-Path: 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 C48CC1A0357 for ; Mon, 27 Jan 2014 08:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 kevM4esbqNfT for ; Mon, 27 Jan 2014 08:45:08 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id C84B61A0275 for ; Mon, 27 Jan 2014 08:45:07 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id k4so7735924qaq.1 for ; Mon, 27 Jan 2014 08:45:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yq+FLhyj4pcooAn/JB8mGClYtgFfFBSj0CUz+oAnFUg=; b=Knmb9NTduA1ynd3CsXuqt9F/ms0lE1EinaMLVqBvWpaT1lifuhyMxgNaG0Dhim3aZV OwBIgi2beTIQiOY27wEphvrAhAniKv/YLZrV+tYHa2S5LM3cSckNbl+iEuRIn/PoGRBz h+13V6hYZVdY/puGfom6OR5bgeDJUv51kr/pHXhzKbEhag3RAZlI3Q3jDWBjs+3Z1TxC 13S+GmpiQWSh1tXRoti/qeR4T6T0EZgdq0XtXwZuAJrvVBop7grH1ZoE6pXHqokqPVJh bCPe4fEPBaMuRYxxJrQtc9LWmh8+VCtcRNaVeEBfPElSCAK/LYLZUv4a0+iOWCl7w469 vI6g== X-Gm-Message-State: ALoCoQkazYzxd/RYW3RAN9r9a2iBpKmsl0+faBJ1F1D24w9yI4hGheF8Dnd8uxa4n9rhqL7a/nGZ MIME-Version: 1.0 X-Received: by 10.140.92.65 with SMTP id a59mr41296100qge.34.1390841105452; Mon, 27 Jan 2014 08:45:05 -0800 (PST) Received: by 10.140.48.75 with HTTP; Mon, 27 Jan 2014 08:45:05 -0800 (PST) In-Reply-To: <52E6319C.7080502@cisco.com> References: <20140124.104128.739402048375968628.mbj@tail-f.com> <52E27B5F.5070908@cisco.com> <52E28C91.6040301@cisco.com> <52E6319C.7080502@cisco.com> Date: Mon, 27 Jan 2014 08:45:05 -0800 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113ab29e07a08904f0f66e6f Cc: Netconf Subject: Re: [Netconf] Netconf Charter update for approval X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 16:45:12 -0000 --001a113ab29e07a08904f0f66e6f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 27, 2014 at 2:14 AM, Benoit Claise wrote: > On 24/01/2014 17:08, Andy Bierman wrote: > > Hi, > > I understand. > However, when it was called YANG-API, many people commented > "Why isn't it called RESTCONF? You are doing REST" > > IMO, all REST will use schema-based content eventually. > There seems to be a growing realization that hand-crafted code > based on ad-hoc API documentation is not as desirable as > auto-generated code based on an easy-to-use schema language. > > So what is the new name if RESTCONF is out? > > Personally, I have no problem with the RESTCONF name, as long as we make > clear in charter and drafts, stressing "some" > > RESTCONF = a protocol almost similar to NETCONF in terms of capabilities, > to access YANG modules over HTTP, with *some *REST characteristics. > > OK with me. It occurred to me that we have already done some "NETCONF alignment", such as removing the "optional-key" YANG extension. It may be RESTful to have the server control all the key values, but NETCONF does not support it. IMO, arbitrary keys are useful sometimes, but they are extremely inefficient. With YANG it is up to the designer whether list keys have any semantics. > Regards, Benoit > Andy --001a113ab29e07a08904f0f66e6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jan 27, 2014 at 2:14 AM, Benoit Claise &l= t;bclaise@cisco.com<= /a>> wrote:
=20 =20 =20
On 24/01/2014 17:08, Andy Bierman wrote:
=20
Hi,

I understand.
However, when it was called YANG-API, many people commented
"Why isn't it called RESTCONF? You are doing REST&quo= t;

IMO, all REST will use schema-based content eventually.
There seems to be a growing realization that hand-crafted code
based on ad-hoc API documentation is not as desirable as
auto-generated code based on an easy-to-use schema language.

So what is the new name if RESTCONF is out?
Personally, I have no problem with the RESTCONF name, as long as we make clear in charter and drafts, stressing "some"
RESTCONF =3D=A0 a protocol almost similar to NETCONF in terms of capabilities, to access YANG modules over HTTP, with some REST characteristics.


OK with me.=

It occurred to me that we have already done some = "NETCONF alignment",
such as removing the "optional-key" YANG extension. =A0It ma= y be RESTful
to have the server control all the key values, but N= ETCONF does not support it.
IMO, arbitrary keys are useful someti= mes, but they are extremely inefficient.
With YANG it is up to the designer whether list keys have any semantic= s.


Regards, Benoit

Andy

--001a113ab29e07a08904f0f66e6f-- From kwatsen@juniper.net Mon Jan 27 11:27:22 2014 Return-Path: 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 170131A0264 for ; Mon, 27 Jan 2014 11:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xACUovllvZFE for ; Mon, 27 Jan 2014 11:27:20 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id D74FF1A0341 for ; Mon, 27 Jan 2014 11:27:19 -0800 (PST) Received: from mail243-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Mon, 27 Jan 2014 19:27:17 +0000 Received: from mail243-tx2 (localhost [127.0.0.1]) by mail243-tx2-R.bigfish.com (Postfix) with ESMTP id 698EE17001E9 for ; Mon, 27 Jan 2014 19:27:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h1155h) Received-SPF: pass (mail243-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(479174003)(377454003)(199002)(24454002)(189002)(377424004)(164054003)(63696002)(74662001)(47446002)(74502001)(93516002)(86362001)(92726001)(93136001)(69226001)(36756003)(76786001)(76796001)(15202345003)(77096001)(49866001)(54356001)(51856001)(53806001)(76482001)(47976001)(50986001)(47736001)(81342001)(54316002)(56776001)(19580405001)(83322001)(83506001)(81686001)(2656002)(74876001)(19580395003)(83072002)(85852003)(59766001)(77982001)(46102001)(79102001)(80976001)(4396001)(81542001)(85306002)(74366001)(65816001)(80022001)(66066001)(31966008)(90146001)(87936001)(15975445006)(56816005)(92566001)(94316002)(74706001)(81816001)(87266001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail243-tx2 (localhost.localdomain [127.0.0.1]) by mail243-tx2 (MessageSwitch) id 1390850834852482_4190; Mon, 27 Jan 2014 19:27:14 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.233]) by mail243-tx2.bigfish.com (Postfix) with ESMTP id BC6E9148004D for ; Mon, 27 Jan 2014 19:27:14 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 27 Jan 2014 19:27:11 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 27 Jan 2014 19:27:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 19:27:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.71]) with mapi id 15.00.0859.020; Mon, 27 Jan 2014 19:27:06 +0000 From: Kent Watsen To: NetConf Thread-Topic: New Version Notification for draft-kwatsen-netconf-server-00.txt Thread-Index: AQHPG4rqTEUUxewGtk+TQtRrRJaQlZqYoJoA Date: Mon, 27 Jan 2014 19:27:06 +0000 Message-ID: References: <20140127180904.19263.37636.idtracker@ietfa.amsl.com> In-Reply-To: <20140127180904.19263.37636.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0104247462 Content-Type: text/plain; charset="us-ascii" Content-ID: <3F90013D17EAF64BB2561DB4CD564544@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Netconf] FW: New Version Notification for draft-kwatsen-netconf-server-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2014 19:27:22 -0000 All, Per the consensus of the working group, Juergen and I created a common configuration data model for both the TLS and reverse-SSH drafts, which is defined draft-kwatsen-netconf-server. Please review and provide comments. A separate update is still needed for both the TLS and reverse-SSH drafts, to reference this draft for the configuration model. Thanks, Kent On 1/27/14 1:09 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kwatsen-netconf-server-00.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-kwatsen-netconf-server >Revision: 00 >Title: A YANG Data Model for NETCONF Server Configuration >Document date: 2014-01-27 >Group: Individual Submission >Pages: 25 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kwatsen-netconf-server-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kwatsen-netconf-server/ >Htmlized: http://tools.ietf.org/html/draft-kwatsen-netconf-server-00 > > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > > > From internet-drafts@ietf.org Wed Jan 29 08:46:44 2014 Return-Path: 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 4E6001A03E9; Wed, 29 Jan 2014 08:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QOphjUzWwfVZ; Wed, 29 Jan 2014 08:46:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6683C1A03A7; Wed, 29 Jan 2014 08:46:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140129164641.24485.86505.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2014 08:46:41 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-05.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2014 16:46:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Using the NETCONF Protocol over Transport Layer S= ecurity (TLS) Authors : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-05.txt Pages : 13 Date : 2014-01-29 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This document obsoletes RFC 5539 and it adds an optional mechanism to establish the underlying TCP connection from the NETCONF server to the NETCONF client (call home). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/