From wdec.ietf@gmail.com Tue Dec 3 07:39:45 2013 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 0BD931AE187 for ; Tue, 3 Dec 2013 07:39:45 -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 KzpfTdkm4rC4 for ; Tue, 3 Dec 2013 07:39:43 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F18481AE15E for ; Tue, 3 Dec 2013 07:39:42 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so21096654pbc.25 for ; Tue, 03 Dec 2013 07:39:40 -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=ToHgf7kO9gjjdd8txWbrD/LBkqvdELtvDLT08y54T3I=; b=fBLDGPOILMBlPILltCRc8X6qvapCLXyWqTv23bo6ulQG7BmV1P201kRXp/DehXD4XR ql33P5IMviPNtB0A7CRgQ1mkIt42+BQFoERK4DbCqa2eZmcrKNDWhkO5dk+ysFoAGlm/ TOJR8pPbZJMlODDOa4YUKUqt7fpjHiieLEnEOOZ8I1aM0Aeky1uREYT/7McCo+PTX8a3 1GhBPVSB6iw8Z8VEXsAof8epnD2aNbPQK/CjjBdbOr/ibt7/J6U5/GO6ZkrpiR2ZPTyQ qvYbA4/lGJpmwN4QyaDxXwL6nStG3MJz1F/6ZH+4jOL0nl1qCA9zRvl+sV/hwkrfn/ce ZsnA== MIME-Version: 1.0 X-Received: by 10.69.31.65 with SMTP id kk1mr24669991pbd.126.1386085180369; Tue, 03 Dec 2013 07:39:40 -0800 (PST) Received: by 10.70.57.163 with HTTP; Tue, 3 Dec 2013 07:39:40 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 16:39:40 +0100 Message-ID: From: Wojciech Dec To: Andy Bierman Content-Type: text/plain; charset=ISO-8859-1 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:39:45 -0000 Following up some of my earlier questions... Inline... On 29 November 2013 16:59, Andy Bierman wrote: > > > > On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec wrote: >> >> Hello Restconf authors, >> >> I would like to ask a few questions and seek your thoughts on the topic of >> URL representation in the API >> Currently Yang allows two forms by which one could seek to have URI data >> be represented in a model: >> >> A. >> leaf someUri { >> type instance-identifier; >> //some Xpath expression to a node >> } >> >> B. >> leaf anotherUri { >> type yang:uri; >> default "/my_uri/is/here" >> } >> >> Now, while the above is perhaps sufficient for some well known absolute >> paths, there appear to be a couple of problems in terms of a Restful API: >> >> 1. Based on the current Restconf spec, both A and B above when faced with >> a GET would appear to expose a URI, which the client would have to do some >> manipulation magic on it before use. What a Restful API would be more likely >> to expose instead is a URL, eg in JSON: >> { >> "url" : "http://example.com/files/v1/documents/abc123" >> } > > > > I do not understand the concern. > One leaf is //restconf/config/someUri and the other is > /restconf/config/anotherUri. > What is the manipulation magic? Constructing /path/to/data/node based on > YANG? > That is the point of RESTCONF. There are already plenty of solutions for > using > REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF for > clients that want to ignore YANG. There are already have plenty of choices > for that. > > >> >> >> It would appear to be sensible to add to the Restconf spec a URL >> generation capability. I.e. have Restconf transform URIs into canonical >> URLs. Thoughts? > > > Can you describe the solution you have in mind? > >> >> >> 2. A URL to a data-model specific method >> Suppose that the model was also defining an RPC, along the lines of the >> "play" RPC in the Jukebox example. Now, as part of the song resource access >> API, it would be natural to have such a method returned in a URL. That would >> also be much more Resful than the currently implicit "/operations" resource >> listing. >> While it may be possible to use B. above to some degree, that is still >> below par as it is not validated in the model. >> Use of A. appears, to me at least, not possible since the RPC is not a >> node. >> Thus, is there a way to have Restconf return an RPC/services list for the >> data? Eg: >> >> { >> "songs": >> [ >> a list of songs, 1, 2, etc >> ], >> "rpc": >> { >> "play": [ "http://example.com/operations/example-jukebox:play"] >> } >> } >> > > The API already has /restconf/operations/. > > YANG is not object-oriented, so /restconf/config/routing/ > is not how the RPC is defined. You are describing a proprietary > extension. > >> 3. Use of current() function as predicate in URIs/URLs >> >> It would be useful to be able to use the "current()" function to construct >> URIs/URLs returned in Restconf. The spec does not make it clear on whether >> this would actually work in A or B above. Would it, or is there some other >> way? >> > > > The URI is not an XPath expression. There are no predicates allowed, > I don't think current() is allowed outside a predicate. Ok, so what is the way in Yang to have a predicate (e.g. current()) based expression that ends up being represented as a URI in Restconf? Use of the current() predicate in the instance-identifier appears not to be supported (at least by pyang). Thanks, Wojciech. > >> >> Thanks, >> Wojciech. >> > > Andy > From andy@yumaworks.com Tue Dec 3 07:56:05 2013 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 0E8F81AE05B for ; Tue, 3 Dec 2013 07:56: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 j11ltgJoThK1 for ; Tue, 3 Dec 2013 07:56:00 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE15F1A1F4C for ; Tue, 3 Dec 2013 07:55:58 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id o15so5675423qap.4 for ; Tue, 03 Dec 2013 07:55: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=jw5aGFeW1B9sW6VICd7Z2D0FnazfBJxBXnTXpGfQh2I=; b=aRr9zFY5aGb0/F0EFcfuw2g8dPv1f9OSjyglbUvjGAh+ABbTBhMe7vJdkAAE4n8d6/ +ln+8Py8w/9POk0zv7VHYn02fSBzMtTnqy1eCGGQd+3yl0gsO1S0vwEWQ1GKZK0OdZbV twlpaG345x9nxMZ5bjAOhMes2PUx+ltbhqcoEsFCjc6lZVN6fNVHYvgG87w3JQ1ec78D SxDbqj5ft9dTuAbrSjiQmHSNYP6PGcmbiUy11hB+rxd1fcUX2hXj77rtE5D4eACpNbI/ F71EZnjQCNiwMvj+t9gSqd/Q2VZC+03l75BcSg/6bJYAhuOKNTrSNaUPOnTm/fZf8INM ipJQ== X-Gm-Message-State: ALoCoQnVNjpDtb0YI7Qtd/wbCmaUMJarOMFtm+BMn3eIMsAAXWhZJBU7ghTi9lOhIQ90Tr+dWbdV MIME-Version: 1.0 X-Received: by 10.49.38.37 with SMTP id d5mr52259330qek.17.1386086155915; Tue, 03 Dec 2013 07:55:55 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 3 Dec 2013 07:55:55 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 07:55:55 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bb043b0f3a8b404eca354d4 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:56:05 -0000 --047d7bb043b0f3a8b404eca354d4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 3, 2013 at 7:39 AM, Wojciech Dec wrote: > Following up some of my earlier questions... Inline... > ... > >> 3. Use of current() function as predicate in URIs/URLs > >> > >> It would be useful to be able to use the "current()" function to > construct > >> URIs/URLs returned in Restconf. The spec does not make it clear on > whether > >> this would actually work in A or B above. Would it, or is there some > other > >> way? > >> > > > > > > The URI is not an XPath expression. There are no predicates allowed, > > I don't think current() is allowed outside a predicate. > > Ok, so what is the way in Yang to have a predicate (e.g. current()) > based expression that ends up being represented as a URI in Restconf? > Use of the current() predicate in the instance-identifier appears not > to be supported (at least by pyang). > > There is none. An instance identifier is the absolution path from root to the specific node being identified. It cannot be used for another purpose. The ietf-yang-types module has an xpath1.0 typedef that allows current() in a predicate. Here is the ABNF from RFC 6020: node-identifier = [prefix ":"] identifier ;; Instance Identifiers instance-identifier = 1*("/" (node-identifier *predicate)) predicate = "[" *WSP (predicate-expr / pos) *WSP "]" predicate-expr = (node-identifier / ".") *WSP "=" *WSP ((DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)) pos = non-negative-integer-value > Thanks, > Wojciech. > > Andy --047d7bb043b0f3a8b404eca354d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 3, 2013 at 7:39 AM, Wojciech Dec <= wdec.ietf@gmail.co= m> wrote:
Following up some of my earlier questions... Inline...
...
>> 3. Use of current() function as predicate in URIs/URLs
>>
>> It would be useful to be able to use the "current()" fun= ction to construct
>> URIs/URLs returned in Restconf. The spec does not make it clear on= whether
>> this would actually work in A or B above. Would it, or is there so= me other
>> way?
>>
>
>
> The URI is not an XPath expression. There are no predicates allowed, > I don't think current() is allowed outside a predicate.

Ok, so what is the way in Yang to have a predicate (e.g. current())
based expression that ends up being represented as a URI in Restconf?
Use of the current() predicate in the instance-identifier appears not
to be supported (at least by pyang).


There is none. An instance identifier = is the absolution path from root
to the specific node being ident= ified. =A0It cannot be used for another
purpose. =A0The ietf-yang= -types module has an xpath1.0 typedef
that allows current() in a predicate.

Here is= the ABNF from RFC 6020:

 node-identifier     =3D [=
prefix ":"] identifier
 ;; Instance Identifiers

   instance-identifier =3D 1*("/" (node-identifier *predicate))

   predicate           =3D "[" *WSP (predicate-expr / pos) *WSP &=
quot;]"

   predicate-expr      =3D (node-identifier / ".") *WSP "=3D=
" *WSP
                         ((DQUOTE string DQUOTE) /
                          (SQUOTE string SQUOTE))

   pos                 =3D non-negative-integer-value


=A0
Thanks,
Wojciech.


Andy
=A0
--047d7bb043b0f3a8b404eca354d4-- From lhotka@nic.cz Tue Dec 3 07:58:51 2013 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 31A4D1AE05B for ; Tue, 3 Dec 2013 07:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 c7vbRI8ZqR6V for ; Tue, 3 Dec 2013 07:58:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9C01A1F4C for ; Tue, 3 Dec 2013 07:58:48 -0800 (PST) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 45F7D13F6A0; Tue, 3 Dec 2013 16:58:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386086325; bh=2FkVSc7rcljGYCVYekGIQLp9mzpGZ+YNJb8jS1kSy+A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=caw4eUSuZLg6muKz7MK2c7zedZbl70Onvr1pm3Rg+vVzJPNJfSGqtlfLYcqSnhC+m BtFv3vJHVHlzvQFevKvG5u3MFXprhovYcxYoGBLI8AUN9GFE1cn7C7tWtt8cFIlehA ELN+RKYtbA/axDhcIrL1/F5y98AAWuYHfx8sb5Sw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 3 Dec 2013 16:58:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Wojciech Dec X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:58:51 -0000 On 03 Dec 2013, at 16:39, Wojciech Dec wrote: > Following up some of my earlier questions... Inline... >=20 > On 29 November 2013 16:59, Andy Bierman wrote: >>=20 >>=20 >>=20 >> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = wrote: >>>=20 >>> Hello Restconf authors, >>>=20 >>> I would like to ask a few questions and seek your thoughts on the = topic of >>> URL representation in the API >>> Currently Yang allows two forms by which one could seek to have URI = data >>> be represented in a model: >>>=20 >>> A. >>> leaf someUri { >>> type instance-identifier; >>> //some Xpath expression to a node >>> } >>>=20 >>> B. >>> leaf anotherUri { >>> type yang:uri; >>> default "/my_uri/is/here" >>> } >>>=20 >>> Now, while the above is perhaps sufficient for some well known = absolute >>> paths, there appear to be a couple of problems in terms of a = Restful API: >>>=20 >>> 1. Based on the current Restconf spec, both A and B above when faced = with >>> a GET would appear to expose a URI, which the client would have to = do some >>> manipulation magic on it before use. What a Restful API would be = more likely >>> to expose instead is a URL, eg in JSON: >>> { >>> "url" : "http://example.com/files/v1/documents/abc123" >>> } >>=20 >>=20 >>=20 >> I do not understand the concern. >> One leaf is //restconf/config/someUri and the other is >> /restconf/config/anotherUri. >> What is the manipulation magic? Constructing /path/to/data/node = based on >> YANG? >> That is the point of RESTCONF. There are already plenty of solutions = for >> using >> REST APIs for ad-hoc data. I do not see any reason to develop = RESTCONF for >> clients that want to ignore YANG. There are already have plenty of = choices >> for that. >>=20 >>=20 >>>=20 >>>=20 >>> It would appear to be sensible to add to the Restconf spec a URL >>> generation capability. I.e. have Restconf transform URIs into = canonical >>> URLs. Thoughts? >>=20 >>=20 >> Can you describe the solution you have in mind? >>=20 >>>=20 >>>=20 >>> 2. A URL to a data-model specific method >>> Suppose that the model was also defining an RPC, along the lines of = the >>> "play" RPC in the Jukebox example. Now, as part of the song resource = access >>> API, it would be natural to have such a method returned in a URL. = That would >>> also be much more Resful than the currently implicit "/operations" = resource >>> listing. >>> While it may be possible to use B. above to some degree, that is = still >>> below par as it is not validated in the model. >>> Use of A. appears, to me at least, not possible since the RPC is not = a >>> node. >>> Thus, is there a way to have Restconf return an RPC/services list = for the >>> data? Eg: >>>=20 >>> { >>> "songs": >>> [ >>> a list of songs, 1, 2, etc >>> ], >>> "rpc": >>> { >>> "play": [ = "http://example.com/operations/example-jukebox:play"] >>> } >>> } >>>=20 >>=20 >> The API already has /restconf/operations/. >>=20 >> YANG is not object-oriented, so /restconf/config/routing/ >> is not how the RPC is defined. You are describing a proprietary >> extension. >>=20 >>> 3. Use of current() function as predicate in URIs/URLs >>>=20 >>> It would be useful to be able to use the "current()" function to = construct >>> URIs/URLs returned in Restconf. The spec does not make it clear on = whether >>> this would actually work in A or B above. Would it, or is there some = other >>> way? >>>=20 >>=20 >>=20 >> The URI is not an XPath expression. There are no predicates allowed, >> I don't think current() is allowed outside a predicate. >=20 > Ok, so what is the way in Yang to have a predicate (e.g. current()) > based expression that ends up being represented as a URI in Restconf? > Use of the current() predicate in the instance-identifier appears not > to be supported (at least by pyang). Predicates in instance-identifiers can be used only for matching list = keys against constant strings, see sec. 9.13 in RFC 6020. Can you give an example of an effect you would like to achieve? Lada >=20 > Thanks, > Wojciech. >=20 >>=20 >>>=20 >>> Thanks, >>> Wojciech. >>>=20 >>=20 >> Andy >>=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wdec.ietf@gmail.com Tue Dec 3 09:47:46 2013 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 E44F91ACC91 for ; Tue, 3 Dec 2013 09:47: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 X2lXSsWjShBJ for ; Tue, 3 Dec 2013 09:47: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 83C051A82E2 for ; Tue, 3 Dec 2013 09:47:44 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id g10so20608517pdj.3 for ; Tue, 03 Dec 2013 09:47:41 -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=KpzcNtBItZaZthIC1L4jAszUfFRiw1AHuwl166VH0ys=; b=YEu1AVQrrn83jdsOLBq+sE3rJKFpSEVZb26hWL8QdX1akC0Dw82Xi2s/JcvilQW+Hy QmDrcOgjd0gPM/dbxrhi8HYJ3KkVTwMzNZGFT/W/gbzcwsCzG29OF1P3Ev2ItibgJzeV iGQ2xK8Q1Uwc3ywx+0p6FwOpvgTGKAv8guIrQsrmqOux0VI5s4KF7N0cKzKJOn2L+sJx LHOhE+wUWF6wShgrm9R9Wzy/coR8T06Lxgya4p9W1X7cIlFTzCTin/rfYHOeu0i9g2Z0 WRXLUt5hoN3UR56mn5Ud1rTJehhZVxb0k+ckKW4U6GJR7D8iWL7K/cQpCVzTCMqRSNFl D27w== MIME-Version: 1.0 X-Received: by 10.69.31.65 with SMTP id kk1mr25416616pbd.126.1386092861909; Tue, 03 Dec 2013 09:47:41 -0800 (PST) Received: by 10.70.57.163 with HTTP; Tue, 3 Dec 2013 09:47:41 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 18:47:41 +0100 Message-ID: From: Wojciech Dec To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:47:47 -0000 On 3 December 2013 16:58, Ladislav Lhotka wrote: > > On 03 Dec 2013, at 16:39, Wojciech Dec wrote: > >> Following up some of my earlier questions... Inline... >> >> On 29 November 2013 16:59, Andy Bierman wrote: >>> >>> >>> >>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec wrote: >>>> >>>> Hello Restconf authors, >>>> >>>> I would like to ask a few questions and seek your thoughts on the topic of >>>> URL representation in the API >>>> Currently Yang allows two forms by which one could seek to have URI data >>>> be represented in a model: >>>> >>>> A. >>>> leaf someUri { >>>> type instance-identifier; >>>> //some Xpath expression to a node >>>> } >>>> >>>> B. >>>> leaf anotherUri { >>>> type yang:uri; >>>> default "/my_uri/is/here" >>>> } >>>> >>>> Now, while the above is perhaps sufficient for some well known absolute >>>> paths, there appear to be a couple of problems in terms of a Restful API: >>>> >>>> 1. Based on the current Restconf spec, both A and B above when faced with >>>> a GET would appear to expose a URI, which the client would have to do some >>>> manipulation magic on it before use. What a Restful API would be more likely >>>> to expose instead is a URL, eg in JSON: >>>> { >>>> "url" : "http://example.com/files/v1/documents/abc123" >>>> } >>> >>> >>> >>> I do not understand the concern. >>> One leaf is //restconf/config/someUri and the other is >>> /restconf/config/anotherUri. >>> What is the manipulation magic? Constructing /path/to/data/node based on >>> YANG? >>> That is the point of RESTCONF. There are already plenty of solutions for >>> using >>> REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF for >>> clients that want to ignore YANG. There are already have plenty of choices >>> for that. >>> >>> >>>> >>>> >>>> It would appear to be sensible to add to the Restconf spec a URL >>>> generation capability. I.e. have Restconf transform URIs into canonical >>>> URLs. Thoughts? >>> >>> >>> Can you describe the solution you have in mind? >>> >>>> >>>> >>>> 2. A URL to a data-model specific method >>>> Suppose that the model was also defining an RPC, along the lines of the >>>> "play" RPC in the Jukebox example. Now, as part of the song resource access >>>> API, it would be natural to have such a method returned in a URL. That would >>>> also be much more Resful than the currently implicit "/operations" resource >>>> listing. >>>> While it may be possible to use B. above to some degree, that is still >>>> below par as it is not validated in the model. >>>> Use of A. appears, to me at least, not possible since the RPC is not a >>>> node. >>>> Thus, is there a way to have Restconf return an RPC/services list for the >>>> data? Eg: >>>> >>>> { >>>> "songs": >>>> [ >>>> a list of songs, 1, 2, etc >>>> ], >>>> "rpc": >>>> { >>>> "play": [ "http://example.com/operations/example-jukebox:play"] >>>> } >>>> } >>>> >>> >>> The API already has /restconf/operations/. >>> >>> YANG is not object-oriented, so /restconf/config/routing/ >>> is not how the RPC is defined. You are describing a proprietary >>> extension. >>> >>>> 3. Use of current() function as predicate in URIs/URLs >>>> >>>> It would be useful to be able to use the "current()" function to construct >>>> URIs/URLs returned in Restconf. The spec does not make it clear on whether >>>> this would actually work in A or B above. Would it, or is there some other >>>> way? >>>> >>> >>> >>> The URI is not an XPath expression. There are no predicates allowed, >>> I don't think current() is allowed outside a predicate. >> >> Ok, so what is the way in Yang to have a predicate (e.g. current()) >> based expression that ends up being represented as a URI in Restconf? >> Use of the current() predicate in the instance-identifier appears not >> to be supported (at least by pyang). > > Predicates in instance-identifiers can be used only for matching list keys against constant strings, see sec. 9.13 in RFC 6020. > > Can you give an example of an effect you would like to achieve? Starting with a basic example: In a data-model for interfaces/x/y, I would like the ability to actually have a reference to another node in the model, that in Restconf ends up shwoing up as a URI. Eg. getting at the URI /interfaces/x/y, would return data which would also give me a URI for "/line-cards/foo/serial-number". A hypothetical Yang data-model for this could be: list interfaces { key some; leaf some { type string; } list details; key id; leaf id { type string; } Other stuff leaf someUri { type instance-identifier; // Xpath expression to the line-cards/foo } } } In the instance-identifier, having a leafref like current() restriction/replacement would appear to be useful in cases where wants to construct such a URI by using as a piece the context of the current node. Open to your suggestions. Thanks, Wojciech. > > Lada > >> >> Thanks, >> Wojciech. >> >>> >>>> >>>> Thanks, >>>> Wojciech. >>>> >>> >>> Andy >>> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Tue Dec 3 11:40:35 2013 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 A60771AE1A4 for ; Tue, 3 Dec 2013 11:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 s3zlijXthLVc for ; Tue, 3 Dec 2013 11:40:33 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4711AC404 for ; Tue, 3 Dec 2013 11:40:32 -0800 (PST) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 8600213F6A0; Tue, 3 Dec 2013 20:40:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386099628; bh=TBYl7dKOjo969nlloi15YaT/xsf7D8XaGYgJlqYRJxw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=e991m7f/YrQ7ErxqmIuO5yJBVozdZRUIjObRi7z4mAjog8oxZh+QRgJQP5WAS1SFI cVlk7LiHpBVbKY4Zav12VR5tEcona7MCarkC2G3eik2LbWHThUmjUaOSYpjbmza2P5 b6bnqRgCSnmyL7T0vBqSq6MbkoFH/DXBeons7ETE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 3 Dec 2013 20:40:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> References: To: Wojciech Dec X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 19:40:35 -0000 On 03 Dec 2013, at 18:47, Wojciech Dec wrote: > On 3 December 2013 16:58, Ladislav Lhotka wrote: >>=20 >> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: >>=20 >>> Following up some of my earlier questions... Inline... >>>=20 >>> On 29 November 2013 16:59, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = wrote: >>>>>=20 >>>>> Hello Restconf authors, >>>>>=20 >>>>> I would like to ask a few questions and seek your thoughts on the = topic of >>>>> URL representation in the API >>>>> Currently Yang allows two forms by which one could seek to have = URI data >>>>> be represented in a model: >>>>>=20 >>>>> A. >>>>> leaf someUri { >>>>> type instance-identifier; >>>>> //some Xpath expression to a node >>>>> } >>>>>=20 >>>>> B. >>>>> leaf anotherUri { >>>>> type yang:uri; >>>>> default "/my_uri/is/here" >>>>> } >>>>>=20 >>>>> Now, while the above is perhaps sufficient for some well known = absolute >>>>> paths, there appear to be a couple of problems in terms of a = Restful API: >>>>>=20 >>>>> 1. Based on the current Restconf spec, both A and B above when = faced with >>>>> a GET would appear to expose a URI, which the client would have to = do some >>>>> manipulation magic on it before use. What a Restful API would be = more likely >>>>> to expose instead is a URL, eg in JSON: >>>>> { >>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>> } >>>>=20 >>>>=20 >>>>=20 >>>> I do not understand the concern. >>>> One leaf is //restconf/config/someUri and the other is >>>> /restconf/config/anotherUri. >>>> What is the manipulation magic? Constructing /path/to/data/node = based on >>>> YANG? >>>> That is the point of RESTCONF. There are already plenty of = solutions for >>>> using >>>> REST APIs for ad-hoc data. I do not see any reason to develop = RESTCONF for >>>> clients that want to ignore YANG. There are already have plenty of = choices >>>> for that. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> It would appear to be sensible to add to the Restconf spec a URL >>>>> generation capability. I.e. have Restconf transform URIs into = canonical >>>>> URLs. Thoughts? >>>>=20 >>>>=20 >>>> Can you describe the solution you have in mind? >>>>=20 >>>>>=20 >>>>>=20 >>>>> 2. A URL to a data-model specific method >>>>> Suppose that the model was also defining an RPC, along the lines = of the >>>>> "play" RPC in the Jukebox example. Now, as part of the song = resource access >>>>> API, it would be natural to have such a method returned in a URL. = That would >>>>> also be much more Resful than the currently implicit "/operations" = resource >>>>> listing. >>>>> While it may be possible to use B. above to some degree, that is = still >>>>> below par as it is not validated in the model. >>>>> Use of A. appears, to me at least, not possible since the RPC is = not a >>>>> node. >>>>> Thus, is there a way to have Restconf return an RPC/services list = for the >>>>> data? Eg: >>>>>=20 >>>>> { >>>>> "songs": >>>>> [ >>>>> a list of songs, 1, 2, etc >>>>> ], >>>>> "rpc": >>>>> { >>>>> "play": [ = "http://example.com/operations/example-jukebox:play"] >>>>> } >>>>> } >>>>>=20 >>>>=20 >>>> The API already has /restconf/operations/. >>>>=20 >>>> YANG is not object-oriented, so /restconf/config/routing/ >>>> is not how the RPC is defined. You are describing a proprietary >>>> extension. >>>>=20 >>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>=20 >>>>> It would be useful to be able to use the "current()" function to = construct >>>>> URIs/URLs returned in Restconf. The spec does not make it clear on = whether >>>>> this would actually work in A or B above. Would it, or is there = some other >>>>> way? >>>>>=20 >>>>=20 >>>>=20 >>>> The URI is not an XPath expression. There are no predicates = allowed, >>>> I don't think current() is allowed outside a predicate. >>>=20 >>> Ok, so what is the way in Yang to have a predicate (e.g. current()) >>> based expression that ends up being represented as a URI in = Restconf? >>> Use of the current() predicate in the instance-identifier appears = not >>> to be supported (at least by pyang). >>=20 >> Predicates in instance-identifiers can be used only for matching list = keys against constant strings, see sec. 9.13 in RFC 6020. >>=20 >> Can you give an example of an effect you would like to achieve? >=20 > Starting with a basic example: In a data-model for interfaces/x/y, I > would like the ability to actually have a reference to another node in > the model, that in Restconf ends up shwoing up as a URI. Eg. getting > at the URI /interfaces/x/y, would return data which would also give me > a URI for "/line-cards/foo/serial-number". >=20 > A hypothetical Yang data-model for this could be: > list interfaces { > key some; > leaf some { > type string; > } > list details; > key id; > leaf id { > type string; > } > Other stuff > leaf someUri { > type instance-identifier; > // Xpath expression to the line-cards/foo > } > } > } Assuming that line-cards also appear somewhere in the data tree, a = leafref would be a more natural way of representing the reference - and = then you can use current(), too. I have myself never used an instance-identifier in any data model yet, = presumably they are mainly useful in notifications. Lada =20 >=20 > In the instance-identifier, having a leafref like current() > restriction/replacement would appear to be useful in cases where wants > to construct such a URI by using as a piece the context of the current > node. >=20 >=20 > Open to your suggestions. >=20 > Thanks, > Wojciech. >=20 >>=20 >> Lada >>=20 >>>=20 >>> Thanks, >>> Wojciech. >>>=20 >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Wojciech. >>>>>=20 >>>>=20 >>>> Andy >>>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From albertgo@cisco.com Tue Dec 3 13:37:15 2013 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 DED171ADED6 for ; Tue, 3 Dec 2013 13:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 5S6QPOvCgUxE for ; Tue, 3 Dec 2013 13:37:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 097F21AD942 for ; Tue, 3 Dec 2013 13:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3526; q=dns/txt; s=iport; t=1386106631; x=1387316231; h=from:to:subject:date:message-id:mime-version; bh=6Btzn6/GoGVkvo8RjawWFGt3HuJyKQrsjQHqdIdgeQ0=; b=WcLZ0DPDpw9arFheWDZAdFA1LVFBAx0ltwdisvost9uKfrxgMykkRzNZ iHg7vm1XWs7npblOEnX7ZXkFhRnCTvgcfJIq1sswPwTIrxi2LYOgZXcOB 4omgi50bYNbAsWYgRjISgsXxhjMnb3w/QklODW3qY/jJLQJUVVXkTftn5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMlOnlKtJV2Z/2dsb2JhbABagkNEgQu6AxZ0giyBCwEMdCcEiBSiNJ88kzgDmBSSE4Mpgio X-IronPort-AV: E=Sophos;i="4.93,819,1378857600"; d="scan'208,217";a="288974064" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 03 Dec 2013 21:36:57 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB3LauIE030671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Dec 2013 21:36:56 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 15:36:55 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: Netconf Thread-Topic: "depth" parameter: nest-level semantics Thread-Index: AQHO8G/JHFyrNhD7hUyEToIqJC/K0g== Date: Tue, 3 Dec 2013 21:36:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.28] Content-Type: multipart/alternative; boundary="_000_CEC38EF43AC41albertgociscocom_" MIME-Version: 1.0 Subject: [Netconf] "depth" parameter: nest-level semantics 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, 03 Dec 2013 21:37:16 -0000 --_000_CEC38EF43AC41albertgociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I wanted to confirm my understanding of the semantics of a nest-level. I understand that a nest-level is composed of a resource + its children. Data resources are: containers and lists. Children of a data resource are: leaves, leaf-lists, anyxml. How about pres= ence containers? 1) In the example of 3.8.1, for a depth of 2, the response includes 2 cont= ainers (I.e., jukebox and library) and 1 list (I.e., artist). Would that ma= ke it 3 resources, and therefore 3 nest-levels? 2) I am assuming that choice and case nodes are "transparent" wrt nest-lev= els. Is this the case? That is, for the following resource Container alpha { choice interface-type { case a { leaf foo { ... } } case b { container bar { ...} } } } For a get for "alpha" and depth =3D 1, the leaf "foo" should be returned if= it existed. "Bar" would not be returned if it existed. Thanks, Alberto --_000_CEC38EF43AC41albertgociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <23B54BBE8A5C384A835A049A73788230@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello, 

I wanted to confirm my understanding of the semantics of a nest-level.=

I understand that a nest-level is composed of a resource + its chi= ldren.
Data resources are: containers and lists.
Children of a data resource are: leaves, leaf-lists, anyxml. How about= presence containers?


1) In the example of 3.8.1, for a depth of 2, the response includ= es  2 containers (I.e., jukebox and library) and 1 list (I.e., artist)= . Would that make it 3 resources, and therefore 3 nest-levels?

2) I am assuming that choice and case nodes are "transparent"= ;  wrt nest-levels. Is this the case?
That is, for the following resource

Container alpha {
     choice interface-type {    =20
         case a {
             leaf foo { ... }
         }
         case b {
             container bar { ...}
         }
     }

}


For a get for "alpha" and depth =3D 1, the leaf "foo&qu= ot; should be returned if it existed. "Bar" would not be returned= if it existed.

Thanks,

Alberto 



--_000_CEC38EF43AC41albertgociscocom_-- From andy@yumaworks.com Tue Dec 3 13:53:52 2013 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 39D371ADE8A for ; Tue, 3 Dec 2013 13:53:52 -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 Q0kwKP1QTPnX for ; Tue, 3 Dec 2013 13:53:48 -0800 (PST) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 212841ADEBF for ; Tue, 3 Dec 2013 13:53:48 -0800 (PST) Received: by mail-qe0-f42.google.com with SMTP id b4so14681651qen.15 for ; Tue, 03 Dec 2013 13:53:45 -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=XN46CN3jGT6DEe5v/b91wE0w7KxCh8hNvhXrPKafqCQ=; b=CdYc1o7J0EYFVKU3W2R9/J4pTS8o+PbNSsBlA+XCaWr53YHJN6Hl53B5Cs3lXofHgj x5RaLyzTaWBymLq5uxVHtHlt+Nzyxy048qDbYiWqOklFQQ9tpcukIXGLjB2W8uyVwQHM YCJHNQhJ1a3bw+MxBIPBDBggmoiVye19nm2ShRlEU0FfUW+vct5e0w27YVmxIfTY4XkE iNKCvQ7YfRgzAa/P/h52z1jwPEgKtk9r0OVGouH9+hY7mVVkGrYVEJURQAc/mmfOFuB2 ky0s9jFx5RAfJSJxT9QtVQi1YmQIuEKIX/q94+Enxp5xCfAJzkTwlh1V2n5K3T2LSg4O 6zhA== X-Gm-Message-State: ALoCoQnRP9gwQcAfXlZ3+kysr5Ptf2bgskvD8BcydxkwXyc6Jk0Jv9ctAnW44/KrFBvw1+Ei5CtY MIME-Version: 1.0 X-Received: by 10.224.39.15 with SMTP id d15mr50016367qae.36.1386107625125; Tue, 03 Dec 2013 13:53:45 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 3 Dec 2013 13:53:45 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 13:53:45 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a1134a56a9dcfd404eca8548a Cc: Netconf Subject: Re: [Netconf] "depth" parameter: nest-level semantics 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, 03 Dec 2013 21:53:52 -0000 --001a1134a56a9dcfd404eca8548a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Hello, > > I wanted to confirm my understanding of the semantics of a nest-level. > > I understand that a nest-level is composed of a resource + its children. > Data resources are: containers and lists. > Children of a data resource are: leaves, leaf-lists, anyxml. How about > presence containers? > > This is changing in restconf-03. In order to allow optional YANG terminals to be deleted without requiring implementation of YANG Patch, all YANG node types will be considered data resources. > 1) In the example of 3.8.1, for a depth of 2, the response includes 2 > containers (I.e., jukebox and library) and 1 list (I.e., artist). Would > that make it 3 resources, and therefore 3 nest-levels? > > 2) I am assuming that choice and case nodes are "transparent" wrt > nest-levels. Is this the case? > yes -- the depth applies to real nodes. That is, for the following resource > > Container alpha { > > choice interface-type { > case a { > leaf foo { ... } > } > case b { > container bar { ...} > } > } > > } > > > > For a get for "alpha" and depth = 1, the leaf "foo" should be returned > if it existed. "Bar" would not be returned if it existed. > Not in restconf-03. The approach above is kind of broken because there is no way for a client to just test for the existence of a container without retrieving all the leafs. depth=2 would return the leaf foo and an empty container bar. depth=3 would return the leaf foo, the container bar, and the children of bar. > Thanks, > > Alberto > > > Andy --001a1134a56a9dcfd404eca8548a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez Prieto (albertgo) = <albertgo@cisco.com> wrote:
Hello,=A0

I wanted to confirm my understanding of the semantics of a nest-level.=

I understand that a nest-level is composed of a resource + its childre= n.
Data resources are: containers and lists.
Children of a data resource are: leaves, leaf-lists, anyxml. How about= presence containers?


This is changin= g in restconf-03.
In order to allow optional YANG terminals to be= deleted without
requiring implementation of YANG Patch, all YANG= node types
will be considered data resources.


=

1) In the example of=A03.8.1, for a depth of 2, the response includes = =A02 containers (I.e., jukebox and library) and 1 list (I.e., artist). Woul= d that make it 3 resources, and therefore 3 nest-levels?

2) I am assuming that choice and case nodes are "transparent"= ; =A0wrt nest-levels. Is this the case?
=

yes -- the depth applies to real nodes.


That is, for the following resource

Container alp=
ha {
     choice i=
nterface-type {    =20
         case a {
             leaf foo { ... }
         }
         case b {
             container bar { ...}
         }
     }

}


For a get for "alpha" and depth =3D 1, the leaf "foo&qu= ot; should be returned if it existed. "Bar" would not be returned= if it existed.

Not in restconf= -03. =A0The approach above is kind of broken
because there is no way for a client to just test for the existence
of a container without retrieving all the leafs.

depth=3D2 would return the leaf foo and an empty container bar.
depth=3D3 would return the leaf foo, the container bar, and the childr= en of bar.


Thanks,

Alberto=A0




Andy

--001a1134a56a9dcfd404eca8548a-- From albertgo@cisco.com Tue Dec 3 14:09:26 2013 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 E879C1AC7EE for ; Tue, 3 Dec 2013 14:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 VQWx0f6SN5bq for ; Tue, 3 Dec 2013 14:09:24 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1C1ADD9D for ; Tue, 3 Dec 2013 14:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9505; q=dns/txt; s=iport; t=1386108561; x=1387318161; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=J+w0RDu4FNnYkm8Ik2M3gB7bEwcbBD7Dgw6u+xNYfZo=; b=WiV+WpyJGL8wB6FSt4UvFoNdlwSHqREJsEbzw+Cz3DndU0m3yLUlw68J JJC2QEqLIANLnuROvIPNzp+toFs/f+L+wOUFyZscby3BfCyGn6QPqqaQ8 rV2iwXOZF8EQwkaf6fUsWtfn3cav2x5WrWP9L4m56+pe6nsLFepe6HoR7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAH1VnlKtJXHA/2dsb2JhbABagkNEgQu4aIEbFnSCJQECBHkSAQgRAwECKDkUCQgCBA4FiAHBSReObREHhDMDlDGDY5ITgymCKg X-IronPort-AV: E=Sophos;i="4.93,820,1378857600"; d="scan'208,217";a="289168231" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 03 Dec 2013 22:09:21 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rB3M9KgR010207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 22:09:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 16:09:19 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman Thread-Topic: [Netconf] "depth" parameter: nest-level semantics Thread-Index: AQHO8G/JHFyrNhD7hUyEToIqJC/K0ppDZ/yA//9+OIA= Date: Tue, 3 Dec 2013 22:09:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.28] Content-Type: multipart/alternative; boundary="_000_CEC3942D3AC4Balbertgociscocom_" MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] "depth" parameter: nest-level semantics 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, 03 Dec 2013 22:09:26 -0000 --_000_CEC3942D3AC4Balbertgociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andy, So I understand that (in the context of data resources) a nest level is com= posed by all the "real" nodes that share parent. I.e., container, list, lea= f, leaf-list, anyxml. Two follow-up questions. Two use cases: * a GET for a container w/ depth =3D1, * should it just return an empty container if it exists? This makes = sense for presence containers. How about non-presence ones? Would it return= an empty container it the containers contains data? * a GET for a list w/ depth =3D1, * should it return just an empty list if it exists (I.e., if the lis= t has at least 1 element) ? Thanks, Alberto From: Andy Bierman > Date: Tuesday, December 3, 2013 1:53 PM To: Alberto Gonzalez Prieto > Cc: Netconf > Subject: Re: [Netconf] "depth" parameter: nest-level semantics On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez Prieto (albertgo) > wrote: Hello, I wanted to confirm my understanding of the semantics of a nest-level. I understand that a nest-level is composed of a resource + its children. Data resources are: containers and lists. Children of a data resource are: leaves, leaf-lists, anyxml. How about pres= ence containers? This is changing in restconf-03. In order to allow optional YANG terminals to be deleted without requiring implementation of YANG Patch, all YANG node types will be considered data resources. 1) In the example of 3.8.1, for a depth of 2, the response includes 2 cont= ainers (I.e., jukebox and library) and 1 list (I.e., artist). Would that ma= ke it 3 resources, and therefore 3 nest-levels? 2) I am assuming that choice and case nodes are "transparent" wrt nest-lev= els. Is this the case? yes -- the depth applies to real nodes. That is, for the following resource Container alpha { choice interface-type { case a { leaf foo { ... } } case b { container bar { ...} } } } For a get for "alpha" and depth =3D 1, the leaf "foo" should be returned if= it existed. "Bar" would not be returned if it existed. Not in restconf-03. The approach above is kind of broken because there is no way for a client to just test for the existence of a container without retrieving all the leafs. depth=3D2 would return the leaf foo and an empty container bar. depth=3D3 would return the leaf foo, the container bar, and the children of= bar. Thanks, Alberto Andy --_000_CEC3942D3AC4Balbertgociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7656DD9DE8813B46852A7315CED53A56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thanks Andy,

So I understand that (in the context of data resources) a nest level i= s composed by all the "real" nodes that share parent. I.e., conta= iner, list, leaf, leaf-list, anyxml.
Two follow-up questions. Two use cases:
  • a GET for a container w/ depth =3D1, 
    • should it just return an empty container if it exists? This makes sense= for presence containers. How about non-presence ones? Would it return an e= mpty container it the containers contains data?
  • a GET for a list w/ depth =3D1, 
    • should it return just an empty list if it exists (I.e., if the lis= t has at least 1 element) ?
Thanks,


Alberto


From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, December 3, 2013 1:5= 3 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] "depth&= quot; parameter: nest-level semantics




On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez= Prieto (albertgo) <albertgo@cisco.com> wrote:
Hello, 

I wanted to confirm my understanding of the semantics of a nest-level.=

I understand that a nest-level is composed of a resource + its chi= ldren.
Data resources are: containers and lists.
Children of a data resource are: leaves, leaf-lists, anyxml. How about= presence containers?


This is changing in restconf-03.
In order to allow optional YANG terminals to be deleted without
requiring implementation of YANG Patch, all YANG node types
will be considered data resources.



1) In the example of 3.8.1, for a depth of 2, the response includ= es  2 containers (I.e., jukebox and library) and 1 list (I.e., artist)= . Would that make it 3 resources, and therefore 3 nest-levels?

2) I am assuming that choice and case nodes are "transparent"= ;  wrt nest-levels. Is this the case?


yes -- the depth applies to real nodes.


That is, for the following resource

Container alp=
ha {
     choice i=
nterface-type {    =20
         case a {
             leaf foo { ... }
         }
         case b {
             container bar { ...}
         }
     }

}


For a get for "alpha" and depth =3D 1, the leaf "foo&qu= ot; should be returned if it existed. "Bar" would not be returned= if it existed.

Not in restconf-03.  The approach above is kind of broken
because there is no way for a client to just test for the existence
of a container without retrieving all the leafs.

depth=3D2 would return the leaf foo and an empty container bar.
depth=3D3 would return the leaf foo, the container bar, and the childr= en of bar.


Thanks,

Alberto 




Andy

 --_000_CEC3942D3AC4Balbertgociscocom_-- From andy@yumaworks.com Tue Dec 3 14:14:07 2013 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 C25821AE1AF for ; Tue, 3 Dec 2013 14:14:07 -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 EpoAGmjuUsXc for ; Tue, 3 Dec 2013 14:14:05 -0800 (PST) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 68F891AE1A3 for ; Tue, 3 Dec 2013 14:14:05 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id ne12so15592829qeb.11 for ; Tue, 03 Dec 2013 14:14:02 -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=6guGAHnovANtKtyGFd9e/bOlKQ5xJrSm9Jgo7ueycpI=; b=NK9LqnTlVyD7r7EbCqlIIYttXWkCTHFycSPsgzL9L0h46LnZh+PccgplaNusRYadXg pg50DA8nAg1m8XVy9BTXkbQcEVtI6j1TtIkBZXVvV5HIfNJYTZovfmNIth7iIbWBQy6h CpAlYhevO2RRh1eDMHBRamXaua/hnffIpPpxxbQZIq8HzZq0DrPBdoMs5LyAaJFPUF49 809x6j9uHmyGkrKB160/tuid7ubaLZcOh7cGb0pRZVvFnsVyhtkaoDlTYTHHqTomCd7w HeoTXPBmvg0A0qRzJmu9sRpB0wAOnlMqnOh9qzKuiF+LT26C4sd8BbChrqreTUDyneOD eptg== X-Gm-Message-State: ALoCoQn//JLsLWoJUbgByK53Qwsu8AF3vjf+pIkwYrI906c+picKjU3x8FUsYxDSFio+zFkU03sc MIME-Version: 1.0 X-Received: by 10.229.5.4 with SMTP id 4mr129092838qct.2.1386108842383; Tue, 03 Dec 2013 14:14:02 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 3 Dec 2013 14:14:02 -0800 (PST) In-Reply-To: References: Date: Tue, 3 Dec 2013 14:14:02 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a1135fd7a2bc7a004eca89d3a Cc: Netconf Subject: Re: [Netconf] "depth" parameter: nest-level semantics 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, 03 Dec 2013 22:14:07 -0000 --001a1135fd7a2bc7a004eca89d3a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 3, 2013 at 2:09 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Thanks Andy, > > So I understand that (in the context of data resources) a nest level is > composed by all the "real" nodes that share parent. I.e., container, list, > leaf, leaf-list, anyxml. > Two follow-up questions. Two use cases: > > - a GET for a container w/ depth =1, > - should it just return an empty container if it exists? This makes > sense for presence containers. How about non-presence ones? Would it return > an empty container it the containers contains data? > > It would return an empty container no matter how many children it had > > - > - a GET for a list w/ depth =1, > - should it return just an empty list if it exists (I.e., if the > list has at least 1 element) ? > > One empty list node (no keys) would be returned if there are 1 or more instances. (I wanted a keys-only parameter but it got left out. depth=2 will return more than the keys with each list instance.) > > - > > Thanks, > > > Alberto > > Andy > > > On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez Prieto (albertgo) < > albertgo@cisco.com> wrote: > >> Hello, >> >> I wanted to confirm my understanding of the semantics of a nest-level. >> >> I understand that a nest-level is composed of a resource + its children. >> Data resources are: containers and lists. >> Children of a data resource are: leaves, leaf-lists, anyxml. How about >> presence containers? >> >> > This is changing in restconf-03. > In order to allow optional YANG terminals to be deleted without > requiring implementation of YANG Patch, all YANG node types > will be considered data resources. > > > >> 1) In the example of 3.8.1, for a depth of 2, the response includes 2 >> containers (I.e., jukebox and library) and 1 list (I.e., artist). Would >> that make it 3 resources, and therefore 3 nest-levels? >> >> 2) I am assuming that choice and case nodes are "transparent" wrt >> nest-levels. Is this the case? >> > > > yes -- the depth applies to real nodes. > > > That is, for the following resource >> >> Container alpha { >> >> choice interface-type { >> case a { >> leaf foo { ... } >> } >> case b { >> container bar { ...} >> } >> } >> >> } >> >> >> >> For a get for "alpha" and depth = 1, the leaf "foo" should be returned >> if it existed. "Bar" would not be returned if it existed. >> > > Not in restconf-03. The approach above is kind of broken > because there is no way for a client to just test for the existence > of a container without retrieving all the leafs. > > depth=2 would return the leaf foo and an empty container bar. > depth=3 would return the leaf foo, the container bar, and the children of > bar. > > >> Thanks, >> >> Alberto >> >> >> > > Andy > > --001a1135fd7a2bc7a004eca89d3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 3, 2013 at 2:09 PM, Alberto Gonzalez Prieto (albertgo) = <albertgo@cisco.com> wrote:
Thanks Andy,

So I understand that (in the context of data resources) a nest level i= s composed by all the "real" nodes that share parent. I.e., conta= iner, list, leaf, leaf-list, anyxml.
Two follow-up questions. Two use cases:
  • a GET for a container w/ depth =3D1,=A0
    • should it just return an empty container if it exists? This makes sense= for presence containers. How about non-presence ones? Would it return an e= mpty container it the containers contains data?

It would return an empty container no matt= er how many children it had=A0
  • a GET for a list w/ depth =3D1,=A0
    • should it return just an empty list if it exists=A0(I.e., if the list h= as at least 1 element) ?

One empty list node (no keys) would be returned if there are 1 or m= ore instances.
(I wanted a keys-only parameter but it got left out. =A0depth=3D2 will= return more than
the keys with each list instance.)
=A0
Thanks,


Alberto



Andy
=A0


On Tue, Dec 3, 2013 at 1:36 PM, Alberto Gonzalez= Prieto (albertgo) <albertgo@cisco.com> wrote:
Hello,=A0

I wanted to confirm my understanding of the semantics of a nest-level.=

I understand that a nest-level is composed of a resource + its childre= n.
Data resources are: containers and lists.
Children of a data resource are: leaves, leaf-lists, anyxml. How about= presence containers?


This is changing in restconf-03.
In order to allow optional YANG terminals to be deleted without
requiring implementation of YANG Patch, all YANG node types
will be considered data resources.



1) In the example of=A03.8.1, for a depth of 2, the response includes = =A02 containers (I.e., jukebox and library) and 1 list (I.e., artist). Woul= d that make it 3 resources, and therefore 3 nest-levels?

2) I am assuming that choice and case nodes are "transparent"= ; =A0wrt nest-levels. Is this the case?


yes -- the depth applies to real nodes.


That is, for the following resource

Container alp=
ha {
     choice i=
nterface-type {    =20
         case a {
             leaf foo { ... }
         }
         case b {
             container bar { ...}
         }
     }

}


For a get for "alpha" and depth =3D 1, the leaf "foo&qu= ot; should be returned if it existed. "Bar" would not be returned= if it existed.

Not in restconf-03. =A0The approach above is kind of broken
because there is no way for a client to just test for the existence
of a container without retrieving all the leafs.

depth=3D2 would return the leaf foo and an empty container bar.
depth=3D3 would return the leaf foo, the container bar, and the childr= en of bar.


Thanks,

Alberto=A0




Andy

--001a1135fd7a2bc7a004eca89d3a-- From wdec.ietf@gmail.com Wed Dec 4 02:10:57 2013 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 CFACB1AE222 for ; Wed, 4 Dec 2013 02:10:57 -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 v2qqB4JOrzZf for ; Wed, 4 Dec 2013 02:10:55 -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 E07D21AE059 for ; Wed, 4 Dec 2013 02:10:54 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so23194298pbc.13 for ; Wed, 04 Dec 2013 02:10:52 -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=tVgGbQed3zO2VJZbcSSo+yeZjH0NJJEfGgkXYEPY9fE=; b=EnZuKi98g2H9Ind45AlloAyozBdwyLr+clcodzDtRRnrNNDr8wpHN5YsCCpP/7wPyD 6XRd2WrWoCrb4F6m0faBriM/fzFPnuWK8jGdBszOtsSVhJpivyeiZtDZxkMFJh3gGuVg KsIb3C2jN6gOMJd2CZlJOMS7B66eZTtPQUzeFUM9OFJCsEqhDDKdhyrCk3qX94c8vokO vm0mvaWlvCzgjZHYRHwhfkskINXc67YX4LzYIlhwdPCpim207W8lyynfz4wN7U7rojX6 gajxJst58uBOFZFE1k12AOIELRu0el1zdXQ2cjqOzMMaSWxV6F0T2oqEalkgEdcJVS2+ Wenw== MIME-Version: 1.0 X-Received: by 10.67.3.3 with SMTP id bs3mr80851116pad.46.1386151851973; Wed, 04 Dec 2013 02:10:51 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 4 Dec 2013 02:10:51 -0800 (PST) In-Reply-To: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> Date: Wed, 4 Dec 2013 11:10:51 +0100 Message-ID: From: Wojciech Dec To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:10:58 -0000 On 3 December 2013 20:40, Ladislav Lhotka wrote: > > On 03 Dec 2013, at 18:47, Wojciech Dec wrote: > >> On 3 December 2013 16:58, Ladislav Lhotka wrote: >>> >>> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: >>> >>>> Following up some of my earlier questions... Inline... >>>> >>>> On 29 November 2013 16:59, Andy Bierman wrote: >>>>> >>>>> >>>>> >>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec wrote: >>>>>> >>>>>> Hello Restconf authors, >>>>>> >>>>>> I would like to ask a few questions and seek your thoughts on the topic of >>>>>> URL representation in the API >>>>>> Currently Yang allows two forms by which one could seek to have URI data >>>>>> be represented in a model: >>>>>> >>>>>> A. >>>>>> leaf someUri { >>>>>> type instance-identifier; >>>>>> //some Xpath expression to a node >>>>>> } >>>>>> >>>>>> B. >>>>>> leaf anotherUri { >>>>>> type yang:uri; >>>>>> default "/my_uri/is/here" >>>>>> } >>>>>> >>>>>> Now, while the above is perhaps sufficient for some well known absolute >>>>>> paths, there appear to be a couple of problems in terms of a Restful API: >>>>>> >>>>>> 1. Based on the current Restconf spec, both A and B above when faced with >>>>>> a GET would appear to expose a URI, which the client would have to do some >>>>>> manipulation magic on it before use. What a Restful API would be more likely >>>>>> to expose instead is a URL, eg in JSON: >>>>>> { >>>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>>> } >>>>> >>>>> >>>>> >>>>> I do not understand the concern. >>>>> One leaf is //restconf/config/someUri and the other is >>>>> /restconf/config/anotherUri. >>>>> What is the manipulation magic? Constructing /path/to/data/node based on >>>>> YANG? >>>>> That is the point of RESTCONF. There are already plenty of solutions for >>>>> using >>>>> REST APIs for ad-hoc data. I do not see any reason to develop RESTCONF for >>>>> clients that want to ignore YANG. There are already have plenty of choices >>>>> for that. >>>>> >>>>> >>>>>> >>>>>> >>>>>> It would appear to be sensible to add to the Restconf spec a URL >>>>>> generation capability. I.e. have Restconf transform URIs into canonical >>>>>> URLs. Thoughts? >>>>> >>>>> >>>>> Can you describe the solution you have in mind? >>>>> >>>>>> >>>>>> >>>>>> 2. A URL to a data-model specific method >>>>>> Suppose that the model was also defining an RPC, along the lines of the >>>>>> "play" RPC in the Jukebox example. Now, as part of the song resource access >>>>>> API, it would be natural to have such a method returned in a URL. That would >>>>>> also be much more Resful than the currently implicit "/operations" resource >>>>>> listing. >>>>>> While it may be possible to use B. above to some degree, that is still >>>>>> below par as it is not validated in the model. >>>>>> Use of A. appears, to me at least, not possible since the RPC is not a >>>>>> node. >>>>>> Thus, is there a way to have Restconf return an RPC/services list for the >>>>>> data? Eg: >>>>>> >>>>>> { >>>>>> "songs": >>>>>> [ >>>>>> a list of songs, 1, 2, etc >>>>>> ], >>>>>> "rpc": >>>>>> { >>>>>> "play": [ "http://example.com/operations/example-jukebox:play"] >>>>>> } >>>>>> } >>>>>> >>>>> >>>>> The API already has /restconf/operations/. >>>>> >>>>> YANG is not object-oriented, so /restconf/config/routing/ >>>>> is not how the RPC is defined. You are describing a proprietary >>>>> extension. >>>>> >>>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>> >>>>>> It would be useful to be able to use the "current()" function to construct >>>>>> URIs/URLs returned in Restconf. The spec does not make it clear on whether >>>>>> this would actually work in A or B above. Would it, or is there some other >>>>>> way? >>>>>> >>>>> >>>>> >>>>> The URI is not an XPath expression. There are no predicates allowed, >>>>> I don't think current() is allowed outside a predicate. >>>> >>>> Ok, so what is the way in Yang to have a predicate (e.g. current()) >>>> based expression that ends up being represented as a URI in Restconf? >>>> Use of the current() predicate in the instance-identifier appears not >>>> to be supported (at least by pyang). >>> >>> Predicates in instance-identifiers can be used only for matching list keys against constant strings, see sec. 9.13 in RFC 6020. >>> >>> Can you give an example of an effect you would like to achieve? >> >> Starting with a basic example: In a data-model for interfaces/x/y, I >> would like the ability to actually have a reference to another node in >> the model, that in Restconf ends up shwoing up as a URI. Eg. getting >> at the URI /interfaces/x/y, would return data which would also give me >> a URI for "/line-cards/foo/serial-number". >> >> A hypothetical Yang data-model for this could be: >> list interfaces { >> key some; >> leaf some { >> type string; >> } >> list details; >> key id; >> leaf id { >> type string; >> } >> Other stuff >> leaf someUri { >> type instance-identifier; >> // Xpath expression to the line-cards/foo >> } >> } >> } > > Assuming that line-cards also appear somewhere in the data tree, a leafref would be a more natural way of representing the reference - and then you can use current(), too. > > I have myself never used an instance-identifier in any data model yet, presumably they are mainly useful in notifications. So leafrefs are great, but if I interpret them correctly in rfc6020 (http://tools.ietf.org/html/rfc6020#page-124), their usage in the context of Restconf would result not in a URI for the leaf being passed to a client (say after a GET), but rather the value of that leaf. It also does not appear to be suited to referencing a data node (eg container). Regards, Wojciech. > > Lada > >> >> In the instance-identifier, having a leafref like current() >> restriction/replacement would appear to be useful in cases where wants >> to construct such a URI by using as a piece the context of the current >> node. >> >> >> Open to your suggestions. >> >> Thanks, >> Wojciech. >> >>> >>> Lada >>> >>>> >>>> Thanks, >>>> Wojciech. >>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Wojciech. >>>>>> >>>>> >>>>> Andy >>>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From lhotka@nic.cz Wed Dec 4 04:33:57 2013 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 58AC61AE250 for ; Wed, 4 Dec 2013 04:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 8FivqAPAHBXg for ; Wed, 4 Dec 2013 04:33:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 751721AE122 for ; Wed, 4 Dec 2013 04:33:54 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A75F713F7CB; Wed, 4 Dec 2013 13:33:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386160431; bh=V6KDO9tJZOMiz3ctnOUaIZONJIhB4s/1K1U+UM3eLHM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=cdXfDZHvjW9/ndZBrocRsTsxGjhbBmwEY+CJ984D1DHepxQ1WKEb8SiC1JHxgWvOv 0IF1x6aB/Oz/h9h/Cw+SKOBYjXZ5lCG0R9UDApIt59Sr9i8BApFfR9/+XS8tixHfPT zOHNVgJW59HfD4uHg+dxbwfceQ7O0lypZ3jV+4UE= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 4 Dec 2013 13:33:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> To: Wojciech Dec X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:33:57 -0000 On 04 Dec 2013, at 11:10, Wojciech Dec wrote: > On 3 December 2013 20:40, Ladislav Lhotka wrote: >>=20 >> On 03 Dec 2013, at 18:47, Wojciech Dec wrote: >>=20 >>> On 3 December 2013 16:58, Ladislav Lhotka wrote: >>>>=20 >>>> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: >>>>=20 >>>>> Following up some of my earlier questions... Inline... >>>>>=20 >>>>> On 29 November 2013 16:59, Andy Bierman = wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = wrote: >>>>>>>=20 >>>>>>> Hello Restconf authors, >>>>>>>=20 >>>>>>> I would like to ask a few questions and seek your thoughts on = the topic of >>>>>>> URL representation in the API >>>>>>> Currently Yang allows two forms by which one could seek to have = URI data >>>>>>> be represented in a model: >>>>>>>=20 >>>>>>> A. >>>>>>> leaf someUri { >>>>>>> type instance-identifier; >>>>>>> //some Xpath expression to a node >>>>>>> } >>>>>>>=20 >>>>>>> B. >>>>>>> leaf anotherUri { >>>>>>> type yang:uri; >>>>>>> default "/my_uri/is/here" >>>>>>> } >>>>>>>=20 >>>>>>> Now, while the above is perhaps sufficient for some well known = absolute >>>>>>> paths, there appear to be a couple of problems in terms of a = Restful API: >>>>>>>=20 >>>>>>> 1. Based on the current Restconf spec, both A and B above when = faced with >>>>>>> a GET would appear to expose a URI, which the client would have = to do some >>>>>>> manipulation magic on it before use. What a Restful API would be = more likely >>>>>>> to expose instead is a URL, eg in JSON: >>>>>>> { >>>>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>>>> } >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> I do not understand the concern. >>>>>> One leaf is //restconf/config/someUri and the other is >>>>>> /restconf/config/anotherUri. >>>>>> What is the manipulation magic? Constructing /path/to/data/node = based on >>>>>> YANG? >>>>>> That is the point of RESTCONF. There are already plenty of = solutions for >>>>>> using >>>>>> REST APIs for ad-hoc data. I do not see any reason to develop = RESTCONF for >>>>>> clients that want to ignore YANG. There are already have plenty = of choices >>>>>> for that. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> It would appear to be sensible to add to the Restconf spec a URL >>>>>>> generation capability. I.e. have Restconf transform URIs into = canonical >>>>>>> URLs. Thoughts? >>>>>>=20 >>>>>>=20 >>>>>> Can you describe the solution you have in mind? >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> 2. A URL to a data-model specific method >>>>>>> Suppose that the model was also defining an RPC, along the lines = of the >>>>>>> "play" RPC in the Jukebox example. Now, as part of the song = resource access >>>>>>> API, it would be natural to have such a method returned in a = URL. That would >>>>>>> also be much more Resful than the currently implicit = "/operations" resource >>>>>>> listing. >>>>>>> While it may be possible to use B. above to some degree, that is = still >>>>>>> below par as it is not validated in the model. >>>>>>> Use of A. appears, to me at least, not possible since the RPC is = not a >>>>>>> node. >>>>>>> Thus, is there a way to have Restconf return an RPC/services = list for the >>>>>>> data? Eg: >>>>>>>=20 >>>>>>> { >>>>>>> "songs": >>>>>>> [ >>>>>>> a list of songs, 1, 2, etc >>>>>>> ], >>>>>>> "rpc": >>>>>>> { >>>>>>> "play": [ = "http://example.com/operations/example-jukebox:play"] >>>>>>> } >>>>>>> } >>>>>>>=20 >>>>>>=20 >>>>>> The API already has /restconf/operations/. >>>>>>=20 >>>>>> YANG is not object-oriented, so = /restconf/config/routing/ >>>>>> is not how the RPC is defined. You are describing a proprietary >>>>>> extension. >>>>>>=20 >>>>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>>>=20 >>>>>>> It would be useful to be able to use the "current()" function to = construct >>>>>>> URIs/URLs returned in Restconf. The spec does not make it clear = on whether >>>>>>> this would actually work in A or B above. Would it, or is there = some other >>>>>>> way? >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The URI is not an XPath expression. There are no predicates = allowed, >>>>>> I don't think current() is allowed outside a predicate. >>>>>=20 >>>>> Ok, so what is the way in Yang to have a predicate (e.g. = current()) >>>>> based expression that ends up being represented as a URI in = Restconf? >>>>> Use of the current() predicate in the instance-identifier appears = not >>>>> to be supported (at least by pyang). >>>>=20 >>>> Predicates in instance-identifiers can be used only for matching = list keys against constant strings, see sec. 9.13 in RFC 6020. >>>>=20 >>>> Can you give an example of an effect you would like to achieve? >>>=20 >>> Starting with a basic example: In a data-model for interfaces/x/y, I >>> would like the ability to actually have a reference to another node = in >>> the model, that in Restconf ends up shwoing up as a URI. Eg. getting >>> at the URI /interfaces/x/y, would return data which would also give = me >>> a URI for "/line-cards/foo/serial-number". >>>=20 >>> A hypothetical Yang data-model for this could be: >>> list interfaces { >>> key some; >>> leaf some { >>> type string; >>> } >>> list details; >>> key id; >>> leaf id { >>> type string; >>> } >>> Other stuff >>> leaf someUri { >>> type instance-identifier; >>> // Xpath expression to the line-cards/foo >>> } >>> } >>> } >>=20 >> Assuming that line-cards also appear somewhere in the data tree, a = leafref would be a more natural way of representing the reference - and = then you can use current(), too. >>=20 >> I have myself never used an instance-identifier in any data model = yet, presumably they are mainly useful in notifications. >=20 > So leafrefs are great, but if I interpret them correctly in rfc6020 > (http://tools.ietf.org/html/rfc6020#page-124), their usage in the > context of Restconf would result not in a URI for the leaf being > passed to a client (say after a GET), but rather the value of that > leaf. It also does not appear to be suited to referencing a data node > (eg container). In my view, the leafref value (such as a list key) can be passed in in a = GET response and then it should be easy for the client-side application = to construct the corresponding URI, XPath or whatever, because it has = access to the data model. I know this goes against REST catechism but I = am inclined to consider it a feature, not a bug. Lada >=20 > Regards, > Wojciech. >>=20 >> Lada >>=20 >>>=20 >>> In the instance-identifier, having a leafref like current() >>> restriction/replacement would appear to be useful in cases where = wants >>> to construct such a URI by using as a piece the context of the = current >>> node. >>>=20 >>>=20 >>> Open to your suggestions. >>>=20 >>> Thanks, >>> Wojciech. >>>=20 >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> Thanks, >>>>> Wojciech. >>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Wojciech. >>>>>>>=20 >>>>>>=20 >>>>>> Andy >>>>>>=20 >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From wdec.ietf@gmail.com Wed Dec 4 06:57:41 2013 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 5CB9C1AE26B for ; Wed, 4 Dec 2013 06:57:41 -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 xPaHQ4TFV2e2 for ; Wed, 4 Dec 2013 06:57:38 -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 9CA061AE237 for ; Wed, 4 Dec 2013 06:57:38 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so22562366pde.34 for ; Wed, 04 Dec 2013 06:57:35 -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:content-transfer-encoding; bh=GJplzu/ETbnTil02t0lW1F3wXRPy3XyKuDT5JfW5gbg=; b=SDj7jrccS4kGvcI6KUhz0+6/4PR4WeECEFnI3rIQaQC7CWTjDfOR0jp4Ie8thIwK71 WuBlejvLFuZv4IeVoBsLQEx+tp+8tC6VYJhzX7rk2/RYac6FFvoJ1zJVmNH9x5i3q/Tx eKl18YgrRxPwPH5MOqBOavy6sg/Qbj8Nc+iXBgDHZanoYV5k/7fHvShy/TLt6S6LBk3x cg6z+I7doDxqmIG6knQ+yM2iykJOzjY2h38qkxdZEOAOb1jx5plY3c9PgfeoOPpG3itc paWL6XOv+rLIwhnZPVXSSIorel+OVBMNjOffbVlYbxRSq1C0+VzxBg2/4H+WKGQmDDU8 B+ZA== MIME-Version: 1.0 X-Received: by 10.66.149.231 with SMTP id ud7mr83530627pab.8.1386169055694; Wed, 04 Dec 2013 06:57:35 -0800 (PST) Received: by 10.70.57.163 with HTTP; Wed, 4 Dec 2013 06:57:35 -0800 (PST) In-Reply-To: References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> Date: Wed, 4 Dec 2013 15:57:35 +0100 Message-ID: From: Wojciech Dec To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:57:41 -0000 On 4 December 2013 13:33, Ladislav Lhotka wrote: > > On 04 Dec 2013, at 11:10, Wojciech Dec wrote: > >> On 3 December 2013 20:40, Ladislav Lhotka wrote: >>> >>> On 03 Dec 2013, at 18:47, Wojciech Dec wrote: >>> >>>> On 3 December 2013 16:58, Ladislav Lhotka wrote: >>>>> >>>>> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: >>>>> >>>>>> Following up some of my earlier questions... Inline... >>>>>> >>>>>> On 29 November 2013 16:59, Andy Bierman wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = wrote: >>>>>>>> >>>>>>>> Hello Restconf authors, >>>>>>>> >>>>>>>> I would like to ask a few questions and seek your thoughts on the = topic of >>>>>>>> URL representation in the API >>>>>>>> Currently Yang allows two forms by which one could seek to have UR= I data >>>>>>>> be represented in a model: >>>>>>>> >>>>>>>> A. >>>>>>>> leaf someUri { >>>>>>>> type instance-identifier; >>>>>>>> //some Xpath expression to a node >>>>>>>> } >>>>>>>> >>>>>>>> B. >>>>>>>> leaf anotherUri { >>>>>>>> type yang:uri; >>>>>>>> default "/my_uri/is/here" >>>>>>>> } >>>>>>>> >>>>>>>> Now, while the above is perhaps sufficient for some well known abs= olute >>>>>>>> paths, there appear to be a couple of problems in terms of a Rest= ful API: >>>>>>>> >>>>>>>> 1. Based on the current Restconf spec, both A and B above when fac= ed with >>>>>>>> a GET would appear to expose a URI, which the client would have to= do some >>>>>>>> manipulation magic on it before use. What a Restful API would be m= ore likely >>>>>>>> to expose instead is a URL, eg in JSON: >>>>>>>> { >>>>>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> I do not understand the concern. >>>>>>> One leaf is //restconf/config/someUri and the other is >>>>>>> /restconf/config/anotherUri. >>>>>>> What is the manipulation magic? Constructing /path/to/data/node ba= sed on >>>>>>> YANG? >>>>>>> That is the point of RESTCONF. There are already plenty of solutio= ns for >>>>>>> using >>>>>>> REST APIs for ad-hoc data. I do not see any reason to develop REST= CONF for >>>>>>> clients that want to ignore YANG. There are already have plenty of= choices >>>>>>> for that. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It would appear to be sensible to add to the Restconf spec a URL >>>>>>>> generation capability. I.e. have Restconf transform URIs into cano= nical >>>>>>>> URLs. Thoughts? >>>>>>> >>>>>>> >>>>>>> Can you describe the solution you have in mind? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2. A URL to a data-model specific method >>>>>>>> Suppose that the model was also defining an RPC, along the lines o= f the >>>>>>>> "play" RPC in the Jukebox example. Now, as part of the song resour= ce access >>>>>>>> API, it would be natural to have such a method returned in a URL. = That would >>>>>>>> also be much more Resful than the currently implicit "/operations"= resource >>>>>>>> listing. >>>>>>>> While it may be possible to use B. above to some degree, that is s= till >>>>>>>> below par as it is not validated in the model. >>>>>>>> Use of A. appears, to me at least, not possible since the RPC is n= ot a >>>>>>>> node. >>>>>>>> Thus, is there a way to have Restconf return an RPC/services list = for the >>>>>>>> data? Eg: >>>>>>>> >>>>>>>> { >>>>>>>> "songs": >>>>>>>> [ >>>>>>>> a list of songs, 1, 2, etc >>>>>>>> ], >>>>>>>> "rpc": >>>>>>>> { >>>>>>>> "play": [ "http://example.com/operations/example-jukebox:play= "] >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>> >>>>>>> The API already has /restconf/operations/. >>>>>>> >>>>>>> YANG is not object-oriented, so /restconf/config/routing/ >>>>>>> is not how the RPC is defined. You are describing a proprietary >>>>>>> extension. >>>>>>> >>>>>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>>>> >>>>>>>> It would be useful to be able to use the "current()" function to c= onstruct >>>>>>>> URIs/URLs returned in Restconf. The spec does not make it clear on= whether >>>>>>>> this would actually work in A or B above. Would it, or is there so= me other >>>>>>>> way? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> The URI is not an XPath expression. There are no predicates allowed= , >>>>>>> I don't think current() is allowed outside a predicate. >>>>>> >>>>>> Ok, so what is the way in Yang to have a predicate (e.g. current()) >>>>>> based expression that ends up being represented as a URI in Restconf= ? >>>>>> Use of the current() predicate in the instance-identifier appears no= t >>>>>> to be supported (at least by pyang). >>>>> >>>>> Predicates in instance-identifiers can be used only for matching list= keys against constant strings, see sec. 9.13 in RFC 6020. >>>>> >>>>> Can you give an example of an effect you would like to achieve? >>>> >>>> Starting with a basic example: In a data-model for interfaces/x/y, I >>>> would like the ability to actually have a reference to another node in >>>> the model, that in Restconf ends up shwoing up as a URI. Eg. getting >>>> at the URI /interfaces/x/y, would return data which would also give me >>>> a URI for "/line-cards/foo/serial-number". >>>> >>>> A hypothetical Yang data-model for this could be: >>>> list interfaces { >>>> key some; >>>> leaf some { >>>> type string; >>>> } >>>> list details; >>>> key id; >>>> leaf id { >>>> type string; >>>> } >>>> Other stuff >>>> leaf someUri { >>>> type instance-identifier; >>>> // Xpath expression to the line-cards/foo >>>> } >>>> } >>>> } >>> >>> Assuming that line-cards also appear somewhere in the data tree, a leaf= ref would be a more natural way of representing the reference - and then yo= u can use current(), too. >>> >>> I have myself never used an instance-identifier in any data model yet, = presumably they are mainly useful in notifications. >> >> So leafrefs are great, but if I interpret them correctly in rfc6020 >> (http://tools.ietf.org/html/rfc6020#page-124), their usage in the >> context of Restconf would result not in a URI for the leaf being >> passed to a client (say after a GET), but rather the value of that >> leaf. It also does not appear to be suited to referencing a data node >> (eg container). > > In my view, the leafref value (such as a list key) can be passed in in a = GET response and then it should be easy for the client-side application to = construct the corresponding URI, XPath or whatever, because it has access t= o the data model. I know this goes against REST catechism but I am inclined= to consider it a feature, not a bug. It would be better to call it a missing feature. Leafref is fine as is, and does pass the value. The recipient though has no idea how to access the resource of that value unless the whole (sub) tree is conveyed. Using the example from 6020: leaf mgmt-interface { type leafref { path "../interface/name"; } } An example of a corresponding XML snippet: eth0 lo eth0 A client receiving eth0, has no idea about the URI of that resource. Assuming that the client is coded to the data model, or is fully Yang aware, and able to combine the "path ../interface/name" to make sense of it all, is not just going against REST principles; it forces a tight client-server coupling, even when one would not be required. I expect a good number of client applications wishing to access he data via Restconf, without necessarily having interest in the full data-models, or even in altering configurations (eg reading a topology). As I wrote previously, having the option of Yang aware clients vs pure REST would be a much stronger proposition. What can we do to get the missing feature? I would still see the "instance-identifier" either molded into a URI, or a new "instance-identifier" like data-type that allow that. Thoughts? -Wojciech. > > Lada > >> >> Regards, >> Wojciech. >>> >>> Lada >>> >>>> >>>> In the instance-identifier, having a leafref like current() >>>> restriction/replacement would appear to be useful in cases where wants >>>> to construct such a URI by using as a piece the context of the current >>>> node. >>>> >>>> >>>> Open to your suggestions. >>>> >>>> Thanks, >>>> Wojciech. >>>> >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> Thanks, >>>>>> Wojciech. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Wojciech. >>>>>>>> >>>>>>> >>>>>>> Andy >>>>>>> >>>>>> _______________________________________________ >>>>>> Netconf mailing list >>>>>> Netconf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>> >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: E74E8C0C >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From mbj@tail-f.com Wed Dec 4 07:13:17 2013 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 641EE1AE2B0 for ; Wed, 4 Dec 2013 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlfYNE4OGB-G for ; Wed, 4 Dec 2013 07:13:16 -0800 (PST) Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 303DF1AE2A3 for ; Wed, 4 Dec 2013 07:12:55 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 12CF537C001; Wed, 4 Dec 2013 16:12:51 +0100 (CET) Date: Wed, 04 Dec 2013 16:12:50 +0100 (CET) Message-Id: <20131204.161250.821204486523776419.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, draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:13:17 -0000 Wojciech Dec wrote: > On 4 December 2013 13:33, Ladislav Lhotka wrote: > > In my view, the leafref value (such as a list key) can be passed in in > > a GET response and then it should be easy for the client-side > > application to construct the corresponding URI, XPath or whatever, > > because it has access to the data model. I know this goes against REST > > catechism but I am inclined to consider it a feature, not a bug. > > It would be better to call it a missing feature. > Leafref is fine as is, and does pass the value. The recipient though > has no idea how to access the resource of that value unless the whole > (sub) tree is conveyed. > Using the example from 6020: > > leaf mgmt-interface { > type leafref { > path "../interface/name"; > } > } > > An example of a corresponding XML snippet: > > > eth0 > > > lo > > > eth0 > > A client receiving eth0, has no idea about the URI of that resource. > Assuming that the client is coded to the data model, or is fully Yang > aware, and able to combine the "path ../interface/name" to make sense > of it all, is not just going against REST principles; it forces a > tight client-server coupling, even when one would not be required. I > expect a good number of client applications wishing to access he data > via Restconf, without necessarily having interest in the full > data-models, or even in altering configurations (eg reading a > topology). > As I wrote previously, having the option of Yang aware clients vs pure > REST would be a much stronger proposition. > What can we do to get the missing feature? > > I would still see the "instance-identifier" either molded into a URI, > or a new "instance-identifier" like data-type that allow that. leafrefs are used when the "target" of the reference is defined in the data model instance-identifiers are used when the "target" of the reference can be any node in the data store. They are encoded in (NETCONF) XML as defined in 6020. They *could* be encoded differently for RESTCONF. But note that when you write a value to a leafref, it is not very elegant (or useful maybe) to write a complete URL. I strongly oppose encoding-specific references - how would a data model designer know which one to use? restconf-leafref or leafref or xxx-leafref? /martin From andy@yumaworks.com Wed Dec 4 07:23:28 2013 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 119F01AE2A2 for ; Wed, 4 Dec 2013 07:23: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 vZ5Wi-a-bvBY for ; Wed, 4 Dec 2013 07:23:23 -0800 (PST) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id AFB561AE273 for ; Wed, 4 Dec 2013 07:23:23 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id cy11so14551829qeb.13 for ; Wed, 04 Dec 2013 07:23: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=eeW6VDUddHnBZR6ju4cX0BJqc12tH6Imwm+ZyqDsFMg=; b=bZUx9+osSdEug+b1XyYH0TiMmwNbVGJjXt9cw8zWRk0fpi1BD9UamQ3OV+ImcpGME1 MH1ZRjVvFwm/lfqOS7OFsTfEgydLXnYB8KuuNfJBf5Aauxq5vTS9cCkofy2nnihKsH3N 9YzLXKMadifMQzooYavTzF7Cpl0a1BE+cXFqLZxDiCaSfqvM65S5zEF2nX8DM6b8vn4Q JBWKKRTTZvgCr/SeNpTApHnxGPWbablMjXptLxmLS6zK3ihYKz63U6S3SvJYXH4ywh7o 9BVVSd3fTAEi2P4ujth37Fo+Xnwrgqja/VSCy73SUxQdjE/3Tku/d0DI1JZW10kx/ivt jZdw== X-Gm-Message-State: ALoCoQnAmzmF3BMlo70cuTddRJaFSCy6uAFrrhbOxtLkcn6KBzDIjdvTfMKM5bgRVEx72/L61kwp MIME-Version: 1.0 X-Received: by 10.224.60.69 with SMTP id o5mr94614698qah.92.1386170600517; Wed, 04 Dec 2013 07:23:20 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 4 Dec 2013 07:23:20 -0800 (PST) In-Reply-To: References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> Date: Wed, 4 Dec 2013 07:23:20 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=001a11c3e4883e090e04ecb6fee8 Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:23:28 -0000 --001a11c3e4883e090e04ecb6fee8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 6:57 AM, Wojciech Dec wrote: > On 4 December 2013 13:33, Ladislav Lhotka wrote: > > > > On 04 Dec 2013, at 11:10, Wojciech Dec wrote: > > > >> On 3 December 2013 20:40, Ladislav Lhotka wrote: > >>> > >>> On 03 Dec 2013, at 18:47, Wojciech Dec wrote: > >>> > >>>> On 3 December 2013 16:58, Ladislav Lhotka wrote: > >>>>> > >>>>> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: > >>>>> > >>>>>> Following up some of my earlier questions... Inline... > >>>>>> > >>>>>> On 29 November 2013 16:59, Andy Bierman wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec > wrote: > >>>>>>>> > >>>>>>>> Hello Restconf authors, > >>>>>>>> > >>>>>>>> I would like to ask a few questions and seek your thoughts on the > topic of > >>>>>>>> URL representation in the API > >>>>>>>> Currently Yang allows two forms by which one could seek to have > URI data > >>>>>>>> be represented in a model: > >>>>>>>> > >>>>>>>> A. > >>>>>>>> leaf someUri { > >>>>>>>> type instance-identifier; > >>>>>>>> //some Xpath expression to a node > >>>>>>>> } > >>>>>>>> > >>>>>>>> B. > >>>>>>>> leaf anotherUri { > >>>>>>>> type yang:uri; > >>>>>>>> default "/my_uri/is/here" > >>>>>>>> } > >>>>>>>> > >>>>>>>> Now, while the above is perhaps sufficient for some well known > absolute > >>>>>>>> paths, there appear to be a couple of problems in terms of a > Restful API: > >>>>>>>> > >>>>>>>> 1. Based on the current Restconf spec, both A and B above when > faced with > >>>>>>>> a GET would appear to expose a URI, which the client would have > to do some > >>>>>>>> manipulation magic on it before use. What a Restful API would be > more likely > >>>>>>>> to expose instead is a URL, eg in JSON: > >>>>>>>> { > >>>>>>>> "url" : "http://example.com/files/v1/documents/abc123" > >>>>>>>> } > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I do not understand the concern. > >>>>>>> One leaf is //restconf/config/someUri and the other is > >>>>>>> /restconf/config/anotherUri. > >>>>>>> What is the manipulation magic? Constructing /path/to/data/node > based on > >>>>>>> YANG? > >>>>>>> That is the point of RESTCONF. There are already plenty of > solutions for > >>>>>>> using > >>>>>>> REST APIs for ad-hoc data. I do not see any reason to develop > RESTCONF for > >>>>>>> clients that want to ignore YANG. There are already have plenty > of choices > >>>>>>> for that. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> It would appear to be sensible to add to the Restconf spec a URL > >>>>>>>> generation capability. I.e. have Restconf transform URIs into > canonical > >>>>>>>> URLs. Thoughts? > >>>>>>> > >>>>>>> > >>>>>>> Can you describe the solution you have in mind? > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2. A URL to a data-model specific method > >>>>>>>> Suppose that the model was also defining an RPC, along the lines > of the > >>>>>>>> "play" RPC in the Jukebox example. Now, as part of the song > resource access > >>>>>>>> API, it would be natural to have such a method returned in a URL. > That would > >>>>>>>> also be much more Resful than the currently implicit > "/operations" resource > >>>>>>>> listing. > >>>>>>>> While it may be possible to use B. above to some degree, that is > still > >>>>>>>> below par as it is not validated in the model. > >>>>>>>> Use of A. appears, to me at least, not possible since the RPC is > not a > >>>>>>>> node. > >>>>>>>> Thus, is there a way to have Restconf return an RPC/services list > for the > >>>>>>>> data? Eg: > >>>>>>>> > >>>>>>>> { > >>>>>>>> "songs": > >>>>>>>> [ > >>>>>>>> a list of songs, 1, 2, etc > >>>>>>>> ], > >>>>>>>> "rpc": > >>>>>>>> { > >>>>>>>> "play": [ " > http://example.com/operations/example-jukebox:play"] > >>>>>>>> } > >>>>>>>> } > >>>>>>>> > >>>>>>> > >>>>>>> The API already has /restconf/operations/. > >>>>>>> > >>>>>>> YANG is not object-oriented, so /restconf/config/routing/ > >>>>>>> is not how the RPC is defined. You are describing a proprietary > >>>>>>> extension. > >>>>>>> > >>>>>>>> 3. Use of current() function as predicate in URIs/URLs > >>>>>>>> > >>>>>>>> It would be useful to be able to use the "current()" function to > construct > >>>>>>>> URIs/URLs returned in Restconf. The spec does not make it clear > on whether > >>>>>>>> this would actually work in A or B above. Would it, or is there > some other > >>>>>>>> way? > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The URI is not an XPath expression. There are no predicates > allowed, > >>>>>>> I don't think current() is allowed outside a predicate. > >>>>>> > >>>>>> Ok, so what is the way in Yang to have a predicate (e.g. current()) > >>>>>> based expression that ends up being represented as a URI in > Restconf? > >>>>>> Use of the current() predicate in the instance-identifier appears > not > >>>>>> to be supported (at least by pyang). > >>>>> > >>>>> Predicates in instance-identifiers can be used only for matching > list keys against constant strings, see sec. 9.13 in RFC 6020. > >>>>> > >>>>> Can you give an example of an effect you would like to achieve? > >>>> > >>>> Starting with a basic example: In a data-model for interfaces/x/y, I > >>>> would like the ability to actually have a reference to another node in > >>>> the model, that in Restconf ends up shwoing up as a URI. Eg. getting > >>>> at the URI /interfaces/x/y, would return data which would also give me > >>>> a URI for "/line-cards/foo/serial-number". > >>>> > >>>> A hypothetical Yang data-model for this could be: > >>>> list interfaces { > >>>> key some; > >>>> leaf some { > >>>> type string; > >>>> } > >>>> list details; > >>>> key id; > >>>> leaf id { > >>>> type string; > >>>> } > >>>> Other stuff > >>>> leaf someUri { > >>>> type instance-identifier; > >>>> // Xpath expression to the line-cards/foo > >>>> } > >>>> } > >>>> } > >>> > >>> Assuming that line-cards also appear somewhere in the data tree, a > leafref would be a more natural way of representing the reference - and > then you can use current(), too. > >>> > >>> I have myself never used an instance-identifier in any data model yet, > presumably they are mainly useful in notifications. > >> > >> So leafrefs are great, but if I interpret them correctly in rfc6020 > >> (http://tools.ietf.org/html/rfc6020#page-124), their usage in the > >> context of Restconf would result not in a URI for the leaf being > >> passed to a client (say after a GET), but rather the value of that > >> leaf. It also does not appear to be suited to referencing a data node > >> (eg container). > > > > In my view, the leafref value (such as a list key) can be passed in in a > GET response and then it should be easy for the client-side application to > construct the corresponding URI, XPath or whatever, because it has access > to the data model. I know this goes against REST catechism but I am > inclined to consider it a feature, not a bug. > > It would be better to call it a missing feature. > Leafref is fine as is, and does pass the value. The recipient though > has no idea how to access the resource of that value unless the whole > (sub) tree is conveyed. > Using the example from 6020: > > leaf mgmt-interface { > type leafref { > path "../interface/name"; > } > } > > An example of a corresponding XML snippet: > > > eth0 > > > lo > > > eth0 > > A client receiving eth0, has no idea about the URI of that resource. > Assuming that the client is coded to the data model, or is fully Yang > aware, and able to combine the "path ../interface/name" to make sense > of it all, is not just going against REST principles; it forces a > tight client-server coupling, even when one would not be required. I > expect a good number of client applications wishing to access he data > via Restconf, without necessarily having interest in the full > data-models, or even in altering configurations (eg reading a > topology). > As I wrote previously, having the option of Yang aware clients vs pure > REST would be a much stronger proposition. > What can we do to get the missing feature? > > I would still see the "instance-identifier" either molded into a URI, > or a new "instance-identifier" like data-type that allow that. > > Thoughts? > > The client has the YANG model, otherwise it would not be doing anything but attempt to render this leaf, since it doesn't know the semantics or even the derived type (i-i or leafref). If the client knows the YANG, then it knows the general path expression to the referenced leaf. These leafs are not required to be unique (e.g., point at if-type leaf). The leafref object must be set to 1 of the values that exist on the device. Your example points at a key leaf, but a keyref is just 1 form of a leafref. You seem to be assuming that the path-stmt nodeset must evaluate to a single instance, and the client must be able to retrieve this instance. However YANG leafref is not defined that way. The value is not tied to a specific referenced leaf instance, so the client cannot retrieve the instance-identifier of that leaf (or all matching leafs). > -Wojciech. > > > > > Lada > Andy --001a11c3e4883e090e04ecb6fee8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 4, 2013 at 6:57 AM, Wojciech Dec <= wdec.ietf@gmail.co= m> wrote:
On 4 December 2013 13:33, Ladislav Lhotka &l= t;lhotka@nic.cz> wrote:
>
> On 04 Dec 2013, at 11:10, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>
>> On 3 December 2013 20:40, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>
>>> On 03 Dec 2013, at 18:47, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>>>
>>>> On 3 December 2013 16:58, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>>>>
>>>>> On 03 Dec 2013, at 16:39, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>>>>>
>>>>>> Following up some of my earlier questions... Inlin= e...
>>>>>>
>>>>>> On 29 November 2013 16:59, Andy Bierman <andy@yumaworks.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = <wdec.ietf@gmail.com> wrot= e:
>>>>>>>>
>>>>>>>> Hello Restconf authors,
>>>>>>>>
>>>>>>>> I would like to ask a few questions and se= ek your thoughts on the topic of
>>>>>>>> URL representation in the API
>>>>>>>> Currently Yang allows two forms by which o= ne could seek to have URI data
>>>>>>>> be represented in a model:
>>>>>>>>
>>>>>>>> A.
>>>>>>>> leaf someUri {
>>>>>>>> =A0type instance-identifier;
>>>>>>>> //some Xpath expression to a node
>>>>>>>> }
>>>>>>>>
>>>>>>>> B.
>>>>>>>> leaf anotherUri {
>>>>>>>> =A0type yang:uri;
>>>>>>>> =A0default "/my_uri/is/here"
>>>>>>>> }
>>>>>>>>
>>>>>>>> Now, while the above is perhaps sufficient= for some well known absolute
>>>>>>>> paths, there appear to be a couple of prob= lems in terms of =A0a Restful API:
>>>>>>>>
>>>>>>>> 1. Based on the current Restconf spec, bot= h A and B above when faced with
>>>>>>>> a GET would appear to expose a URI, which = the client would have to do some
>>>>>>>> manipulation magic on it before use. What = a Restful API would be more likely
>>>>>>>> to expose instead is a URL, eg in JSON: >>>>>>>> {
>>>>>>>> =A0"url" : "http://example.= com/files/v1/documents/abc123"
>>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I do not understand the concern.
>>>>>>> One leaf is //restconf/config/someUri and the = other is
>>>>>>> /restconf/config/anotherUri.
>>>>>>> What is the manipulation magic? =A0Constructin= g /path/to/data/node based on
>>>>>>> YANG?
>>>>>>> That is the point of RESTCONF. =A0There are al= ready plenty of solutions for
>>>>>>> using
>>>>>>> REST APIs for ad-hoc data. =A0I do not see any= reason to develop RESTCONF for
>>>>>>> clients that want to ignore YANG. =A0There are= already have plenty of choices
>>>>>>> for that.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It would appear to be sensible to add to t= he Restconf spec a URL
>>>>>>>> generation capability. I.e. have Restconf = transform URIs into canonical
>>>>>>>> URLs. Thoughts?
>>>>>>>
>>>>>>>
>>>>>>> Can you describe the solution you have in mind= ?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2. A URL to a data-model specific method >>>>>>>> Suppose that the model was also defining a= n RPC, along the lines of the
>>>>>>>> "play" RPC in the Jukebox exampl= e. Now, as part of the song resource access
>>>>>>>> API, it would be natural to have such a me= thod returned in a URL. That would
>>>>>>>> also be much more Resful than the currentl= y implicit "/operations" resource
>>>>>>>> listing.
>>>>>>>> While it may be possible to use B. above t= o some degree, that is still
>>>>>>>> below par as it is not validated in the mo= del.
>>>>>>>> Use of A. appears, to me at least, not pos= sible since the RPC is not a
>>>>>>>> node.
>>>>>>>> Thus, is there a way to have Restconf retu= rn an RPC/services list for the
>>>>>>>> data? Eg:
>>>>>>>>
>>>>>>>> {
>>>>>>>> =A0"songs":
>>>>>>>> =A0[
>>>>>>>> =A0 =A0 =A0a list of songs, 1, 2, etc
>>>>>>>> =A0],
>>>>>>>> =A0"rpc":
>>>>>>>> =A0{
>>>>>>>> =A0 =A0 =A0"play": [ "http://example.com/operations/example-jukebox:play"]
>>>>>>>> =A0}
>>>>>>>> }
>>>>>>>>
>>>>>>>
>>>>>>> The API already has /restconf/operations/<Y= ANG-rpc-name>.
>>>>>>>
>>>>>>> YANG is not object-oriented, so /restconf/conf= ig/routing/<RPC-name>
>>>>>>> is not how the RPC is defined. =A0You are desc= ribing a proprietary
>>>>>>> extension.
>>>>>>>
>>>>>>>> 3. Use of current() function as predicate = in URIs/URLs
>>>>>>>>
>>>>>>>> It would be useful to be able to use the &= quot;current()" function to construct
>>>>>>>> URIs/URLs returned in Restconf. The spec d= oes not make it clear on whether
>>>>>>>> this would actually work in A or B above. = Would it, or is there some other
>>>>>>>> way?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The URI is not an XPath expression. There are = no predicates allowed,
>>>>>>> I don't think current() is allowed outside= a predicate.
>>>>>>
>>>>>> Ok, so what is the way in Yang to have a predicate= (e.g. current())
>>>>>> based expression that ends up being represented as= a URI in Restconf?
>>>>>> Use of the current() predicate in the instance-ide= ntifier appears not
>>>>>> to be supported (at least by pyang).
>>>>>
>>>>> Predicates in instance-identifiers can be used only fo= r matching list keys against constant strings, see sec. 9.13 in RFC 6020. >>>>>
>>>>> Can you give an example of an effect you would like to= achieve?
>>>>
>>>> Starting with a basic example: In a data-model for interfa= ces/x/y, I
>>>> would like the ability to actually have a reference to ano= ther node in
>>>> the model, that in Restconf ends up shwoing up as a URI. E= g. getting
>>>> at the URI /interfaces/x/y, would return data which would = also give me
>>>> a URI for "/line-cards/foo/serial-number".
>>>>
>>>> A hypothetical Yang data-model for this could be:
>>>> list interfaces {
>>>> =A0 key some;
>>>> =A0 leaf some {
>>>> =A0 =A0 =A0type string;
>>>> =A0 }
>>>> =A0 list details;
>>>> =A0 =A0 key id;
>>>> =A0 =A0 leaf id {
>>>> =A0 =A0 =A0 type string;
>>>> =A0 =A0 }
>>>> =A0 =A0Other stuff
>>>> =A0 =A0leaf someUri {
>>>> =A0 =A0 =A0 =A0type instance-identifier;
>>>> =A0 =A0// Xpath expression to the line-cards/foo
>>>> =A0 =A0}
>>>> =A0}
>>>> }
>>>
>>> Assuming that line-cards also appear somewhere in the data tre= e, a leafref would be a more natural way of representing the reference - an= d then you can use current(), too.
>>>
>>> I have myself never used an instance-identifier in any data mo= del yet, presumably they are mainly useful in notifications.
>>
>> So leafrefs are great, but if I interpret them correctly in rfc602= 0
>> (http://tools.ietf.org/html/rfc6020#page-124), their usage in t= he
>> context of Restconf would result not in a URI for the leaf being >> passed to a client (say after a GET), but rather the value of that=
>> leaf. It also does not appear to be suited to referencing a data n= ode
>> (eg container).
>
> In my view, the leafref value (such as a list key) can be passed in in= a GET response and then it should be easy for the client-side application = to construct the corresponding URI, XPath or whatever, because it has acces= s to the data model. I know this goes against REST catechism but I am incli= ned to consider it a feature, not a bug.

It would be better to call it a missing feature.
Leafref is fine as is, and does pass the value. The recipient though
has no idea how to access the resource of that value unless the whole
(sub) tree is conveyed.
Using the example from 6020:

=A0 leaf mgmt-interface {
=A0 =A0 =A0 =A0 =A0type leafref {
=A0 =A0 =A0 =A0 =A0 =A0 =A0path "../interface/name";
=A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0}

=A0 =A0An example of a corresponding XML snippet:

=A0 =A0 =A0<interface>
=A0 =A0 =A0 =A0<name>eth0</name>
=A0 =A0 =A0</interface>
=A0 =A0 =A0<interface>
=A0 =A0 =A0 =A0<name>lo</name>
=A0 =A0 =A0</interface>

=A0 =A0 =A0<mgmt-interface>eth0</mgmt-interface>

A client receiving eth0, has no idea about the URI of that resource.
Assuming that the client is coded to the data model, or is fully Yang
aware, and able to combine the "path ../interface/name" to make s= ense
of it all, is not just going against REST principles; it forces a
tight client-server coupling, even when one would not be required. I
expect a good number of client applications wishing to access he data
via Restconf, without necessarily having interest in the full
data-models, or even in altering configurations (eg reading a
topology).
As I wrote previously, having the option of Yang aware clients vs pure
REST would be a much stronger proposition.
What can we do to get the missing feature?

I would still see the "instance-identifier" either molded into a = URI,
or a new "instance-identifier" like data-type that allow that.
Thoughts?




The clie= nt has the YANG model, otherwise it would not be
doing anything b= ut attempt to render this leaf, since it doesn't
know the sem= antics or even the derived type (i-i or leafref).

If the client knows the YANG, then it knows the general=
path expression to the referenced leaf. =A0These leafs are not
required to be unique (e.g., point at if-type leaf). =A0The leafre= f
object must be set to 1 of the values that exist on the device.
<= div>Your example points at a key leaf, but a keyref is just 1 form
of a leafref.
=A0
You seem to be assuming that the pa= th-stmt nodeset must evaluate
to a single instance, and the client must be able to retrieve this ins= tance.
However YANG leafref is not defined that way. =A0The value= is not tied
to a specific referenced leaf instance, so the clien= t cannot retrieve the
instance-identifier of that leaf (or all matching leafs).


=A0
-Wojciech.

>
> Lada

Andy

--001a11c3e4883e090e04ecb6fee8-- From mbj@tail-f.com Wed Dec 4 07:39:04 2013 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 168EB1AE272 for ; Wed, 4 Dec 2013 07:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fuq24hPuUNj for ; Wed, 4 Dec 2013 07:39:02 -0800 (PST) Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5917C1ADF0F for ; Wed, 4 Dec 2013 07:39:02 -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 E92B337C002; Wed, 4 Dec 2013 16:38:58 +0100 (CET) Date: Wed, 04 Dec 2013 16:38:58 +0100 (CET) Message-Id: <20131204.163858.1984524724480280969.mbj@tail-f.com> To: andy@yumaworks.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, draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:39:04 -0000 Andy Bierman wrote: > On Wed, Dec 4, 2013 at 6:57 AM, Wojciech Dec wrote: > > > On 4 December 2013 13:33, Ladislav Lhotka wrote: > > > > > > On 04 Dec 2013, at 11:10, Wojciech Dec wrote: > > > > > >> On 3 December 2013 20:40, Ladislav Lhotka wrote: > > >>> > > >>> On 03 Dec 2013, at 18:47, Wojciech Dec wrote: > > >>> > > >>>> On 3 December 2013 16:58, Ladislav Lhotka wrote: > > >>>>> > > >>>>> On 03 Dec 2013, at 16:39, Wojciech Dec wrote: > > >>>>> > > >>>>>> Following up some of my earlier questions... Inline... > > >>>>>> > > >>>>>> On 29 November 2013 16:59, Andy Bierman wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec > > wrote: > > >>>>>>>> > > >>>>>>>> Hello Restconf authors, > > >>>>>>>> > > >>>>>>>> I would like to ask a few questions and seek your thoughts on the > > topic of > > >>>>>>>> URL representation in the API > > >>>>>>>> Currently Yang allows two forms by which one could seek to have > > URI data > > >>>>>>>> be represented in a model: > > >>>>>>>> > > >>>>>>>> A. > > >>>>>>>> leaf someUri { > > >>>>>>>> type instance-identifier; > > >>>>>>>> //some Xpath expression to a node > > >>>>>>>> } > > >>>>>>>> > > >>>>>>>> B. > > >>>>>>>> leaf anotherUri { > > >>>>>>>> type yang:uri; > > >>>>>>>> default "/my_uri/is/here" > > >>>>>>>> } > > >>>>>>>> > > >>>>>>>> Now, while the above is perhaps sufficient for some well known > > absolute > > >>>>>>>> paths, there appear to be a couple of problems in terms of a > > Restful API: > > >>>>>>>> > > >>>>>>>> 1. Based on the current Restconf spec, both A and B above when > > faced with > > >>>>>>>> a GET would appear to expose a URI, which the client would have > > to do some > > >>>>>>>> manipulation magic on it before use. What a Restful API would be > > more likely > > >>>>>>>> to expose instead is a URL, eg in JSON: > > >>>>>>>> { > > >>>>>>>> "url" : "http://example.com/files/v1/documents/abc123" > > >>>>>>>> } > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> I do not understand the concern. > > >>>>>>> One leaf is //restconf/config/someUri and the other is > > >>>>>>> /restconf/config/anotherUri. > > >>>>>>> What is the manipulation magic? Constructing /path/to/data/node > > based on > > >>>>>>> YANG? > > >>>>>>> That is the point of RESTCONF. There are already plenty of > > solutions for > > >>>>>>> using > > >>>>>>> REST APIs for ad-hoc data. I do not see any reason to develop > > RESTCONF for > > >>>>>>> clients that want to ignore YANG. There are already have plenty > > of choices > > >>>>>>> for that. > > >>>>>>> > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> It would appear to be sensible to add to the Restconf spec a URL > > >>>>>>>> generation capability. I.e. have Restconf transform URIs into > > canonical > > >>>>>>>> URLs. Thoughts? > > >>>>>>> > > >>>>>>> > > >>>>>>> Can you describe the solution you have in mind? > > >>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> 2. A URL to a data-model specific method > > >>>>>>>> Suppose that the model was also defining an RPC, along the lines > > of the > > >>>>>>>> "play" RPC in the Jukebox example. Now, as part of the song > > resource access > > >>>>>>>> API, it would be natural to have such a method returned in a URL. > > That would > > >>>>>>>> also be much more Resful than the currently implicit > > "/operations" resource > > >>>>>>>> listing. > > >>>>>>>> While it may be possible to use B. above to some degree, that is > > still > > >>>>>>>> below par as it is not validated in the model. > > >>>>>>>> Use of A. appears, to me at least, not possible since the RPC is > > not a > > >>>>>>>> node. > > >>>>>>>> Thus, is there a way to have Restconf return an RPC/services list > > for the > > >>>>>>>> data? Eg: > > >>>>>>>> > > >>>>>>>> { > > >>>>>>>> "songs": > > >>>>>>>> [ > > >>>>>>>> a list of songs, 1, 2, etc > > >>>>>>>> ], > > >>>>>>>> "rpc": > > >>>>>>>> { > > >>>>>>>> "play": [ " > > http://example.com/operations/example-jukebox:play"] > > >>>>>>>> } > > >>>>>>>> } > > >>>>>>>> > > >>>>>>> > > >>>>>>> The API already has /restconf/operations/. > > >>>>>>> > > >>>>>>> YANG is not object-oriented, so /restconf/config/routing/ > > >>>>>>> is not how the RPC is defined. You are describing a proprietary > > >>>>>>> extension. > > >>>>>>> > > >>>>>>>> 3. Use of current() function as predicate in URIs/URLs > > >>>>>>>> > > >>>>>>>> It would be useful to be able to use the "current()" function to > > construct > > >>>>>>>> URIs/URLs returned in Restconf. The spec does not make it clear > > on whether > > >>>>>>>> this would actually work in A or B above. Would it, or is there > > some other > > >>>>>>>> way? > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> The URI is not an XPath expression. There are no predicates > > allowed, > > >>>>>>> I don't think current() is allowed outside a predicate. > > >>>>>> > > >>>>>> Ok, so what is the way in Yang to have a predicate (e.g. current()) > > >>>>>> based expression that ends up being represented as a URI in > > Restconf? > > >>>>>> Use of the current() predicate in the instance-identifier appears > > not > > >>>>>> to be supported (at least by pyang). > > >>>>> > > >>>>> Predicates in instance-identifiers can be used only for matching > > list keys against constant strings, see sec. 9.13 in RFC 6020. > > >>>>> > > >>>>> Can you give an example of an effect you would like to achieve? > > >>>> > > >>>> Starting with a basic example: In a data-model for interfaces/x/y, I > > >>>> would like the ability to actually have a reference to another node in > > >>>> the model, that in Restconf ends up shwoing up as a URI. Eg. getting > > >>>> at the URI /interfaces/x/y, would return data which would also give me > > >>>> a URI for "/line-cards/foo/serial-number". > > >>>> > > >>>> A hypothetical Yang data-model for this could be: > > >>>> list interfaces { > > >>>> key some; > > >>>> leaf some { > > >>>> type string; > > >>>> } > > >>>> list details; > > >>>> key id; > > >>>> leaf id { > > >>>> type string; > > >>>> } > > >>>> Other stuff > > >>>> leaf someUri { > > >>>> type instance-identifier; > > >>>> // Xpath expression to the line-cards/foo > > >>>> } > > >>>> } > > >>>> } > > >>> > > >>> Assuming that line-cards also appear somewhere in the data tree, a > > leafref would be a more natural way of representing the reference - and > > then you can use current(), too. > > >>> > > >>> I have myself never used an instance-identifier in any data model yet, > > presumably they are mainly useful in notifications. > > >> > > >> So leafrefs are great, but if I interpret them correctly in rfc6020 > > >> (http://tools.ietf.org/html/rfc6020#page-124), their usage in the > > >> context of Restconf would result not in a URI for the leaf being > > >> passed to a client (say after a GET), but rather the value of that > > >> leaf. It also does not appear to be suited to referencing a data node > > >> (eg container). > > > > > > In my view, the leafref value (such as a list key) can be passed in in a > > GET response and then it should be easy for the client-side application to > > construct the corresponding URI, XPath or whatever, because it has access > > to the data model. I know this goes against REST catechism but I am > > inclined to consider it a feature, not a bug. > > > > It would be better to call it a missing feature. > > Leafref is fine as is, and does pass the value. The recipient though > > has no idea how to access the resource of that value unless the whole > > (sub) tree is conveyed. > > Using the example from 6020: > > > > leaf mgmt-interface { > > type leafref { > > path "../interface/name"; > > } > > } > > > > An example of a corresponding XML snippet: > > > > > > eth0 > > > > > > lo > > > > > > eth0 > > > > A client receiving eth0, has no idea about the URI of that resource. > > Assuming that the client is coded to the data model, or is fully Yang > > aware, and able to combine the "path ../interface/name" to make sense > > of it all, is not just going against REST principles; it forces a > > tight client-server coupling, even when one would not be required. I > > expect a good number of client applications wishing to access he data > > via Restconf, without necessarily having interest in the full > > data-models, or even in altering configurations (eg reading a > > topology). > > As I wrote previously, having the option of Yang aware clients vs pure > > REST would be a much stronger proposition. > > What can we do to get the missing feature? > > > > I would still see the "instance-identifier" either molded into a URI, > > or a new "instance-identifier" like data-type that allow that. > > > > Thoughts? > > > > > > > The client has the YANG model, otherwise it would not be > doing anything but attempt to render this leaf, since it doesn't > know the semantics or even the derived type (i-i or leafref). > > If the client knows the YANG, then it knows the general > path expression to the referenced leaf. These leafs are not > required to be unique (e.g., point at if-type leaf). The leafref > object must be set to 1 of the values that exist on the device. > Your example points at a key leaf, but a keyref is just 1 form > of a leafref. > > You seem to be assuming that the path-stmt nodeset must evaluate > to a single instance, and the client must be able to retrieve this instance. > However YANG leafref is not defined that way. The value is not tied > to a specific referenced leaf instance, so the client cannot retrieve the > instance-identifier of that leaf (or all matching leafs). Good point! /martin From lhotka@nic.cz Wed Dec 4 07:43:23 2013 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 8D4DE1AE2AC for ; Wed, 4 Dec 2013 07:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 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.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 3x2XS61oIxmH for ; Wed, 4 Dec 2013 07:43:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 526D01AE2A8 for ; Wed, 4 Dec 2013 07:43:20 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9B62714015B; Wed, 4 Dec 2013 16:43:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386171796; bh=Qfg+E3jrhIqMKcQNdX5dI2FxLJNNmz0Lv9VsE53jRmg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qjwubikpYg2FKGL0OgFWKUv5iMIVZ6kf0oYnfjqFTnsM9zbZD1YxnlGvPL4u9/3ns s3sm5Kc5iF5iLYcOOzDFAOWmK0lfs9D7Gs0fhrVnKyyBQOjls8tpKDeobVF4xlFXjd MO0WF7jfDsD2VQMh1dCGSU0UwW4ZcwSlNom4R8Iw= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 4 Dec 2013 16:43:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9AEC841C-E765-4D0D-A1A6-928E6C90D225@nic.cz> References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> To: Wojciech Dec X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:43:23 -0000 On 04 Dec 2013, at 15:57, Wojciech Dec wrote: > On 4 December 2013 13:33, Ladislav Lhotka wrote: >>=20 >> On 04 Dec 2013, at 11:10, Wojciech Dec wrote: >>=20 >>> On 3 December 2013 20:40, Ladislav Lhotka wrote: >>>>=20 >>>> On 03 Dec 2013, at 18:47, Wojciech Dec wrote: >>>>=20 >>>>> On 3 December 2013 16:58, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> On 03 Dec 2013, at 16:39, Wojciech Dec = wrote: >>>>>>=20 >>>>>>> Following up some of my earlier questions... Inline... >>>>>>>=20 >>>>>>> On 29 November 2013 16:59, Andy Bierman = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Fri, Nov 29, 2013 at 6:01 AM, Wojciech Dec = wrote: >>>>>>>>>=20 >>>>>>>>> Hello Restconf authors, >>>>>>>>>=20 >>>>>>>>> I would like to ask a few questions and seek your thoughts on = the topic of >>>>>>>>> URL representation in the API >>>>>>>>> Currently Yang allows two forms by which one could seek to = have URI data >>>>>>>>> be represented in a model: >>>>>>>>>=20 >>>>>>>>> A. >>>>>>>>> leaf someUri { >>>>>>>>> type instance-identifier; >>>>>>>>> //some Xpath expression to a node >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> B. >>>>>>>>> leaf anotherUri { >>>>>>>>> type yang:uri; >>>>>>>>> default "/my_uri/is/here" >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>> Now, while the above is perhaps sufficient for some well known = absolute >>>>>>>>> paths, there appear to be a couple of problems in terms of a = Restful API: >>>>>>>>>=20 >>>>>>>>> 1. Based on the current Restconf spec, both A and B above when = faced with >>>>>>>>> a GET would appear to expose a URI, which the client would = have to do some >>>>>>>>> manipulation magic on it before use. What a Restful API would = be more likely >>>>>>>>> to expose instead is a URL, eg in JSON: >>>>>>>>> { >>>>>>>>> "url" : "http://example.com/files/v1/documents/abc123" >>>>>>>>> } >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I do not understand the concern. >>>>>>>> One leaf is //restconf/config/someUri and the other is >>>>>>>> /restconf/config/anotherUri. >>>>>>>> What is the manipulation magic? Constructing = /path/to/data/node based on >>>>>>>> YANG? >>>>>>>> That is the point of RESTCONF. There are already plenty of = solutions for >>>>>>>> using >>>>>>>> REST APIs for ad-hoc data. I do not see any reason to develop = RESTCONF for >>>>>>>> clients that want to ignore YANG. There are already have = plenty of choices >>>>>>>> for that. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It would appear to be sensible to add to the Restconf spec a = URL >>>>>>>>> generation capability. I.e. have Restconf transform URIs into = canonical >>>>>>>>> URLs. Thoughts? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Can you describe the solution you have in mind? >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 2. A URL to a data-model specific method >>>>>>>>> Suppose that the model was also defining an RPC, along the = lines of the >>>>>>>>> "play" RPC in the Jukebox example. Now, as part of the song = resource access >>>>>>>>> API, it would be natural to have such a method returned in a = URL. That would >>>>>>>>> also be much more Resful than the currently implicit = "/operations" resource >>>>>>>>> listing. >>>>>>>>> While it may be possible to use B. above to some degree, that = is still >>>>>>>>> below par as it is not validated in the model. >>>>>>>>> Use of A. appears, to me at least, not possible since the RPC = is not a >>>>>>>>> node. >>>>>>>>> Thus, is there a way to have Restconf return an RPC/services = list for the >>>>>>>>> data? Eg: >>>>>>>>>=20 >>>>>>>>> { >>>>>>>>> "songs": >>>>>>>>> [ >>>>>>>>> a list of songs, 1, 2, etc >>>>>>>>> ], >>>>>>>>> "rpc": >>>>>>>>> { >>>>>>>>> "play": [ = "http://example.com/operations/example-jukebox:play"] >>>>>>>>> } >>>>>>>>> } >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The API already has /restconf/operations/. >>>>>>>>=20 >>>>>>>> YANG is not object-oriented, so = /restconf/config/routing/ >>>>>>>> is not how the RPC is defined. You are describing a = proprietary >>>>>>>> extension. >>>>>>>>=20 >>>>>>>>> 3. Use of current() function as predicate in URIs/URLs >>>>>>>>>=20 >>>>>>>>> It would be useful to be able to use the "current()" function = to construct >>>>>>>>> URIs/URLs returned in Restconf. The spec does not make it = clear on whether >>>>>>>>> this would actually work in A or B above. Would it, or is = there some other >>>>>>>>> way? >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The URI is not an XPath expression. There are no predicates = allowed, >>>>>>>> I don't think current() is allowed outside a predicate. >>>>>>>=20 >>>>>>> Ok, so what is the way in Yang to have a predicate (e.g. = current()) >>>>>>> based expression that ends up being represented as a URI in = Restconf? >>>>>>> Use of the current() predicate in the instance-identifier = appears not >>>>>>> to be supported (at least by pyang). >>>>>>=20 >>>>>> Predicates in instance-identifiers can be used only for matching = list keys against constant strings, see sec. 9.13 in RFC 6020. >>>>>>=20 >>>>>> Can you give an example of an effect you would like to achieve? >>>>>=20 >>>>> Starting with a basic example: In a data-model for interfaces/x/y, = I >>>>> would like the ability to actually have a reference to another = node in >>>>> the model, that in Restconf ends up shwoing up as a URI. Eg. = getting >>>>> at the URI /interfaces/x/y, would return data which would also = give me >>>>> a URI for "/line-cards/foo/serial-number". >>>>>=20 >>>>> A hypothetical Yang data-model for this could be: >>>>> list interfaces { >>>>> key some; >>>>> leaf some { >>>>> type string; >>>>> } >>>>> list details; >>>>> key id; >>>>> leaf id { >>>>> type string; >>>>> } >>>>> Other stuff >>>>> leaf someUri { >>>>> type instance-identifier; >>>>> // Xpath expression to the line-cards/foo >>>>> } >>>>> } >>>>> } >>>>=20 >>>> Assuming that line-cards also appear somewhere in the data tree, a = leafref would be a more natural way of representing the reference - and = then you can use current(), too. >>>>=20 >>>> I have myself never used an instance-identifier in any data model = yet, presumably they are mainly useful in notifications. >>>=20 >>> So leafrefs are great, but if I interpret them correctly in rfc6020 >>> (http://tools.ietf.org/html/rfc6020#page-124), their usage in the >>> context of Restconf would result not in a URI for the leaf being >>> passed to a client (say after a GET), but rather the value of that >>> leaf. It also does not appear to be suited to referencing a data = node >>> (eg container). >>=20 >> In my view, the leafref value (such as a list key) can be passed in = in a GET response and then it should be easy for the client-side = application to construct the corresponding URI, XPath or whatever, = because it has access to the data model. I know this goes against REST = catechism but I am inclined to consider it a feature, not a bug. >=20 > It would be better to call it a missing feature. > Leafref is fine as is, and does pass the value. The recipient though > has no idea how to access the resource of that value unless the whole > (sub) tree is conveyed. > Using the example from 6020: >=20 > leaf mgmt-interface { > type leafref { > path "../interface/name"; > } > } >=20 > An example of a corresponding XML snippet: >=20 > > eth0 > > > lo > >=20 > eth0 >=20 > A client receiving eth0, has no idea about the URI of that resource. > Assuming that the client is coded to the data model, or is fully Yang > aware, and able to combine the "path ../interface/name" to make sense > of it all, is not just going against REST principles; it forces a > tight client-server coupling, even when one would not be required. I > expect a good number of client applications wishing to access he data > via Restconf, without necessarily having interest in the full > data-models, or even in altering configurations (eg reading a > topology). > As I wrote previously, having the option of Yang aware clients vs pure > REST would be a much stronger proposition. > What can we do to get the missing feature? RESTCONF is a protocol only by virtue of YANG data models that serve as = a contract between the server and client. Other UIs, perhaps more = RESTful or more suitable for human users, are certainly possible, but = this is outside the scope of the WG - UI is a taboo word in the IETF in = general. Lada >=20 > I would still see the "instance-identifier" either molded into a URI, > or a new "instance-identifier" like data-type that allow that. >=20 > Thoughts? >=20 > -Wojciech. >=20 >>=20 >> Lada >>=20 >>>=20 >>> Regards, >>> Wojciech. >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> In the instance-identifier, having a leafref like current() >>>>> restriction/replacement would appear to be useful in cases where = wants >>>>> to construct such a URI by using as a piece the context of the = current >>>>> node. >>>>>=20 >>>>>=20 >>>>> Open to your suggestions. >>>>>=20 >>>>> Thanks, >>>>> Wojciech. >>>>>=20 >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Wojciech. >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Wojciech. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Andy >>>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Netconf mailing list >>>>>>> Netconf@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>>>=20 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: E74E8C0C >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: E74E8C0C >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Dec 4 07:58:06 2013 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 002091AE2C5 for ; Wed, 4 Dec 2013 07:58:06 -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 cg4e25iJu_ru for ; Wed, 4 Dec 2013 07:58:03 -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 C68E31AE2C0 for ; Wed, 4 Dec 2013 07:58:02 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id gc15so16269259qeb.35 for ; Wed, 04 Dec 2013 07:57:59 -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=IdpeY+MGbiy3HRVt54dhfTJT6PYg2pQlAxc8EOcZJIM=; b=eLEWGWujCXdg5IJgsLCuojUIP3XYMRbFYTppHF8nwbk2SFSeonVJTZI0mksZ3qJOGk GQTUeS70SaYiUsWbqZOQlu2APFj5NS6mVduYXJTA1EcIbZH+pBsRfdBPgZdhnlgoUoyK m3+7qgc1/FJ1tVLM79QzpCuAWvhILCeRrwkD0rLLF+QLztixXtN29QHig/docBylLlqs qn82sU8Y74t7pozhFVAB2/TTY7Sslds93j+XseaTnnpXwfj5Mr61yNzoZJ+d/IxbY1tj G9iN8j1vTk/3vOda0iMWo3UG5EE/y0szkZMyj7coRPgekm+83JufiNP/1IDThrQzikVn 5hzQ== X-Gm-Message-State: ALoCoQltt98uz7J5JzuJGf/Z/DKu5rdiZnDrDMapL0IgS1OFBf9V5xLWvKfTzzUXZvpiE0r+DbrN MIME-Version: 1.0 X-Received: by 10.49.130.135 with SMTP id oe7mr137052963qeb.41.1386172679357; Wed, 04 Dec 2013 07:57:59 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 4 Dec 2013 07:57:59 -0800 (PST) In-Reply-To: <20131204.161250.821204486523776419.mbj@tail-f.com> References: <20131204.161250.821204486523776419.mbj@tail-f.com> Date: Wed, 4 Dec 2013 07:57:59 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7bd6bc44269e1f04ecb77ae0 Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:58:06 -0000 --047d7bd6bc44269e1f04ecb77ae0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 7:12 AM, Martin Bjorklund wrote: > Wojciech Dec wrote: > .... > leafrefs are used when the "target" of the reference is defined in the > data model > > instance-identifiers are used when the "target" of the reference can > be any node in the data store. > > They are encoded in (NETCONF) XML as defined in 6020. > > They *could* be encoded differently for RESTCONF. But note that when > you write a value to a leafref, it is not very elegant (or useful > maybe) to write a complete URL. > > I strongly oppose encoding-specific references - how would a data > model designer know which one to use? restconf-leafref or leafref or > xxx-leafref? > > This is actually a real problem in the YANG Patch draft. There are some data-resource-identifier leafs, such as error-path, that are imported from ietf-restconf.yang, but NETCONF-EX needs to use the NETCONF error-path syntax (XPath) not a URI. The refine-stmt does not allow a leaf type-stmt to be altered so the grouping is unusable. This is preventing YANG Patch from being protocol independent. There is a deterministic 1:1 mapping between data-resource-identifier and instance-identifier for data nodes (by design). Should a RESTCONF client or NETCONF client need to know about transforming XPath to/from URI? I agree that it is messy to force the server to treat the same object differently, and render it according to the protocol used for the request. This violates every design principle for unified APIs. typedef both-identifiers { type union { type instance-identifier; type rc:data-resource-identifier; } } A YANG model could be written to work with both data types. This does not solve the problem of converting XPath to/from URI depending on the protocol used. We have to make sure YANG is protocol independent. Any ideas on how to do that? > /martin > Andy --047d7bd6bc44269e1f04ecb77ae0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 4, 2013 at 7:12 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Wojciech Dec <wdec.ietf@gmail.com> wrote:
.... leafrefs are used when the "target" of the reference is defined i= n the
data model

instance-identifiers are used when the "target" of the reference = can
be any node in the data store.

They are encoded in (NETCONF) XML as defined in 6020.

They *could* be encoded differently for RESTCONF. =A0But note that when
you write a value to a leafref, it is not very elegant (or useful
maybe) to write a complete URL.

I strongly oppose encoding-specific references - how would a data
model designer know which one to use? =A0restconf-leafref or leafref or
xxx-leafref?



This is actually a real= problem in the YANG Patch draft.
There are some data-resource-id= entifier leafs, such as error-path,
that are imported from ietf-r= estconf.yang, but NETCONF-EX
needs to use the NETCONF error-path syntax (XPath) not a URI.

The refine-stmt does not allow a leaf type-stmt to be alte= red
so the grouping is unusable. =A0This is preventing YANG Patch=
from being protocol independent.

There is a d= eterministic 1:1 mapping between data-resource-identifier
and ins= tance-identifier for data nodes (by design). =A0Should a RESTCONF client
or NETCONF client need to know about transforming XPath to/from URI?

I agree that it is messy to force the server to tre= at the same object differently,
and render it according to the pr= otocol used for the request. =A0This violates
every design principle for unified APIs.

=A0 = =A0typedef both-identifiers {
=A0 =A0 =A0 type union {
= =A0 =A0 =A0 =A0 =A0 type instance-identifier;
=A0 =A0 =A0 =A0 =A0= type rc:data-resource-identifier;
=A0 =A0 =A0 }
=A0 =A0}

A YANG model= could be written to work with both data types.
This does not sol= ve the problem of converting XPath to/from URI
depending on the p= rotocol used.

We have to make sure YANG is protocol independent.
Any ideas on how to do that?


=

/martin

Andy

=
--047d7bd6bc44269e1f04ecb77ae0-- From wwwrun@rfc-editor.org Fri Dec 6 02:07:44 2013 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 726EF1AE315 for ; Fri, 6 Dec 2013 02:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 FBJz4iHHY-Ar for ; Fri, 6 Dec 2013 02:07:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE51ADBE5 for ; Fri, 6 Dec 2013 02:07:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B33EB7FC383; Fri, 6 Dec 2013 02:07:37 -0800 (PST) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20131206100737.B33EB7FC383@rfc-editor.org> Date: Fri, 6 Dec 2013 02:07:37 -0800 (PST) X-Mailman-Approved-At: Fri, 06 Dec 2013 02:23:12 -0800 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [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: Fri, 06 Dec 2013 10:07:44 -0000 The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Jonathan Hansford 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 ----- 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. -------------------------------------- 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 Fri Dec 6 02:11:53 2013 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 DD3821ADC03 for ; Fri, 6 Dec 2013 02:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 ho7SSQWt3HN7 for ; Fri, 6 Dec 2013 02:11:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 61D181AC7F0 for ; Fri, 6 Dec 2013 02:11:52 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B5C3F7FC387; Fri, 6 Dec 2013 02:11:48 -0800 (PST) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20131206101148.B5C3F7FC387@rfc-editor.org> Date: Fri, 6 Dec 2013 02:11:48 -0800 (PST) X-Mailman-Approved-At: Fri, 06 Dec 2013 02:23:13 -0800 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] 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: Fri, 06 Dec 2013 10:11:54 -0000 The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Jonathan Hansford 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 ----- 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. -------------------------------------- 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 Fri Dec 6 02:14:18 2013 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 E68781AE2A7 for ; Fri, 6 Dec 2013 02:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 m1rMNoHdXNW3 for ; Fri, 6 Dec 2013 02:14:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9B41ADC03 for ; Fri, 6 Dec 2013 02:14:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7578C7FC38D; Fri, 6 Dec 2013 02:14:13 -0800 (PST) To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, bertietf@bwijnen.net, mehmet.ersue@nsn.com From: RFC Errata System Message-Id: <20131206101413.7578C7FC38D@rfc-editor.org> Date: Fri, 6 Dec 2013 02:14:13 -0800 (PST) X-Mailman-Approved-At: Fri, 06 Dec 2013 02:23:13 -0800 Cc: netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] [Technical Errata Reported] 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: Fri, 06 Dec 2013 10:14:19 -0000 The following errata report has been submitted 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 -------------------------------------- Type: Technical Reported by: Jonathan Hansford 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 ----- 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. -------------------------------------- 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 andy@yumaworks.com Fri Dec 6 11:43:08 2013 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 064BB1AE328 for ; Fri, 6 Dec 2013 11:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 XORDmEl-hy8x for ; Fri, 6 Dec 2013 11:43:07 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E9ED81AE15A for ; Fri, 6 Dec 2013 11:43:06 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id i8so848293qcq.10 for ; Fri, 06 Dec 2013 11:43:02 -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=tvCNlPJK/La4hcCPlwho+K+/lOMZsBosNYta37xfvnE=; b=WVpaZcGck9cUu/l040WmENTZ9jDIwvLDih1qJ7ZOUFDZq2aNJuLfkmVAOQ15WLIIsH e7WCc45S4wArLr55R0eAYmzhv78v7OuaqpsSKlY2KLB+/0rr00pKjKJyyGwwpnVYtU9q dNgc5FIQyA5rgpbNS6brt9tTO7GdGNH7HNAhDNxou6ZUiSswa9HKOmUQqggHE77prUy9 4Ym4DbEseCnQYP/Qafhl6ZHQ+nFFP1b/XSMfDlhsxVTlJkP/npLMR5StT63htxPVCyYN WkAPld25aPuNV/1IB49/LZA3sqGVyzBPYu4z93LJDjmk3xYvc3djqxRNcTDcL7Ln4v26 OSZg== X-Gm-Message-State: ALoCoQmBJGsi+Wx9tIpPvH1IWrZwZbmsYWKp0An4KEBxZxQLF4FMssp4no+Re9cdtDel5STWDjB1 MIME-Version: 1.0 X-Received: by 10.49.130.135 with SMTP id oe7mr159332557qeb.41.1386358982677; Fri, 06 Dec 2013 11:43:02 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 6 Dec 2013 11:43:02 -0800 (PST) In-Reply-To: References: <55E62C30-66A0-422A-A440-7D7ED57494E5@nic.cz> Date: Fri, 6 Dec 2013 11:43:02 -0800 Message-ID: From: Andy Bierman To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7bd6bc44b1a7bd04ece2da7d Cc: draft-bierman-netconf-restconf@tools.ietf.org, Netconf Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:43:08 -0000 --047d7bd6bc44b1a7bd04ece2da7d Content-Type: text/plain; charset=ISO-8859-1 Hi, You have raised an important RESTCONF issue, which is the client processing of server resource URIs. I think the client should be able to use the Location header URI for all CRUD access to the data resource. That's why the /restconf/config and /restconf/operational split is broken. In order to retrieve operational data, the client has to parse the URI and change it -- not too REST-ful ;-) I think there should be one YANG data root: /restconf/data. For RESTCONF, the ETag and Last-Modified headers are only affected by configuration data resources. The client will have to add a query parameter to retrieve config=false data, so it can also be aware that ETag and Last-Modified are not affected by config=false data nodes. Andy --047d7bd6bc44b1a7bd04ece2da7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

You have raised an important REST= CONF issue, which is the
client processing = of server resource URIs. =A0I think the
client should be able to use the Location = header URI for
all CRUD access to the data = resource.

That's why the /restconf/config and /restconf/operational split
is broken. In order to retrieve operational data, = the client
has to parse the URI and change = it -- not too REST-ful ;-)

I think the= re should be one YANG data root: /restconf/data.
For RESTCONF, the ETag and Last-Modified headers are
only affected by configuration data resources. =A0The client
will have to add a query parameter to retrieve config=3Df= alse
data, so it can also be aware that ETa= g and Last-Modified
are not affected by config=3Dfalse data nodes.


Andy



<= br>
--047d7bd6bc44b1a7bd04ece2da7d-- From mbj@tail-f.com Fri Dec 6 13:27:32 2013 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 D03B21AE09C for ; Fri, 6 Dec 2013 13:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3hqKVpQcCKw for ; Fri, 6 Dec 2013 13:27:32 -0800 (PST) Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id E44C31AE043 for ; Fri, 6 Dec 2013 13:27:31 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 56CB037C006; Fri, 6 Dec 2013 22:27:21 +0100 (CET) Date: Fri, 06 Dec 2013 22:27:20 +0100 (CET) Message-Id: <20131206.222720.369437985.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org, draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:27:33 -0000 Andy Bierman wrote: > Hi, > > You have raised an important RESTCONF issue, which is the > client processing of server resource URIs. I think the > client should be able to use the Location header URI for > all CRUD access to the data resource. > > That's why the /restconf/config and /restconf/operational split > is broken. In order to retrieve operational data, the client > has to parse the URI and change it -- not too REST-ful ;-) RESTCONF's uri scheme is already not too REST-ful. The uri's are deterministic and known by both client and server. The Location header only works when the client has created a resource, but it cannot be used to discover uris on the server. The split into config and operational does not change this. /martin From andy@yumaworks.com Fri Dec 6 17:54:24 2013 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 9A3D01AE098 for ; Fri, 6 Dec 2013 17:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, 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 ZoRvQN3tNXiL for ; Fri, 6 Dec 2013 17:54:23 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6111AD942 for ; Fri, 6 Dec 2013 17:54:23 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id a11so1136293qen.5 for ; Fri, 06 Dec 2013 17:54:19 -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=diYaXjXzQ/MMIYN9kwlsNq+mUU7u8laLYUFDQeSSM7g=; b=MbbLicWTKzXkzqaSBXtGMICqO/9vWZLb9+qbIbW+PeVjcdjLqV74PKJwY6vbvnxzOl UgPhvOg+4nLwtCPFN8okq20/g/qZaRvEqOoL0op5EOiPk+PYdXQs3scD/Uvuw7eI7P9E dGcn3rMuYToCeCv64wKnp0xBcq6/B+j/D4PqdPYPH8QzBtxAhle6c1Wmvi2/5cTwL1ga Y6XOZV5j3VWCSekIJdy1M6K9H4fcRadOl7pgaBIjLxGn/bPXyqgSfKnNa27jI7Ax9riL FGRWXdJFgfWqojuZZHa12zRQYiGiFQXmPGH1Q2EMzzOycZZCPT115acLk+iL5aqfCvPu 6Vnw== X-Gm-Message-State: ALoCoQmC9XD30xcZwyDS62XbgJ/prMWN+zLKMIbl9+6X4y3UDbBXwkXtmue9TzaPBmvSvmd6nBaU MIME-Version: 1.0 X-Received: by 10.229.194.1 with SMTP id dw1mr11675941qcb.20.1386381259307; Fri, 06 Dec 2013 17:54:19 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 6 Dec 2013 17:54:19 -0800 (PST) In-Reply-To: <20131206.222720.369437985.mbj@tail-f.com> References: <20131206.222720.369437985.mbj@tail-f.com> Date: Fri, 6 Dec 2013 17:54:19 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c2c7367c4ac204ece80af4 Cc: Netconf , draft-bierman-netconf-restconf@tools.ietf.org Subject: Re: [Netconf] Representing URLs X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 01:54:24 -0000 --001a11c2c7367c4ac204ece80af4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 6, 2013 at 1:27 PM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > You have raised an important RESTCONF issue, which is the > > client processing of server resource URIs. I think the > > client should be able to use the Location header URI for > > all CRUD access to the data resource. > > > > That's why the /restconf/config and /restconf/operational split > > is broken. In order to retrieve operational data, the client > > has to parse the URI and change it -- not too REST-ful ;-) > > RESTCONF's uri scheme is already not too REST-ful. The uri's are > deterministic and known by both client and server. The Location > header only works when the client has created a resource, but it > cannot be used to discover uris on the server. > > The split into config and operational does not change this. > > OK, but the split was supposed to get rid of the config query param but it didn't. Now config=true|false applies only to the /restconf/data resource, not the /restconf/config resource. I think we are better off without the /restconf/config resource and just have /restconf/data + content=enum (config|operational|both) [default:config] The ETag and Last-Modified values are only returned when content=config. They are only maintained for config=true data nodes. > > /martin > Andy --001a11c2c7367c4ac204ece80af4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Dec 6, 2013 at 1:27 PM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> You have raised an important RESTCONF issue, which is the
> client processing of server resource URIs. =A0I think the
> client should be able to use the Location header URI for
> all CRUD access to the data resource.
>
> That's why the /restconf/config and /restconf/operational split > is broken. In order to retrieve operational data, the client
> has to parse the URI and change it -- not too REST-ful ;-)

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

The split into config and operational does not change this.


OK, but the split was supposed to get rid of the con= fig query param
but it didn't. =A0Now config=3Dtrue|false app= lies only to the /restconf/data
resource, not the /restconf/config resource.

= I think we are better off without the /restconf/config resource and
just have /restconf/data + content=3Denum (config|operational|both) [def= ault:config]
The ETag and Last-Modified values are only returned when content=3Dcon= fig.
They are only maintained for config=3Dtrue data nodes.
=


=A0

/martin


<= /div>
Andy

--001a11c2c7367c4ac204ece80af4-- From bertietf@bwijnen.net Mon Dec 9 12:35:11 2013 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 E71C21AE52D for ; Mon, 9 Dec 2013 12:35:10 -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 DmUibqIDKTYz for ; Mon, 9 Dec 2013 12:35:09 -0800 (PST) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4CB1AE2AB for ; Mon, 9 Dec 2013 12:35:09 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Vq7Xe-0001bZ-Ax; Mon, 09 Dec 2013 21:34:59 +0100 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Vq7Xe-00061Q-7X; Mon, 09 Dec 2013 21:34:58 +0100 Message-ID: <52A62972.4010001@bwijnen.net> Date: Mon, 09 Dec 2013 21:34:58 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: rob.enns@gmail.com, mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, andy.bierman@brocade.com References: <20131206100737.B33EB7FC383@rfc-editor.org> In-Reply-To: <20131206100737.B33EB7FC383@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd43f92be232ebeb133f91aaee3c0dfa51b Cc: joelja@bogus.com, netconf@ietf.org 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, 09 Dec 2013 20:35:11 -0000 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. Thanks, Bert and Mehmet From j.schoenwaelder@jacobs-university.de Mon Dec 9 13:08:17 2013 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 4E5F61AE5A5 for ; Mon, 9 Dec 2013 13:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 1RMddwcMj6IF for ; Mon, 9 Dec 2013 13:08: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 307641AE5A8 for ; Mon, 9 Dec 2013 13:08:06 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9372320045; Mon, 9 Dec 2013 22:08:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RHJTHip3eYU6; Mon, 9 Dec 2013 22:08:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51EC62003E; Mon, 9 Dec 2013 22:07:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C81F829F65B2; Mon, 9 Dec 2013 22:07:53 +0100 (CET) Date: Mon, 9 Dec 2013 22:07:52 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20131209210752.GA70828@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , rob.enns@gmail.com, mbj@tail-f.com, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, mehmet.ersue@nsn.com, jonathan@hansfords.net, netconf@ietf.org References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A62972.4010001@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, andy.bierman@brocade.com Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) 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: Mon, 09 Dec 2013 21:08:17 -0000 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jonathan@hansfords.net Mon Dec 9 13:28:08 2013 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 6AF741AE08B for ; Mon, 9 Dec 2013 13:28:08 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 F5vMbDaLswcP for ; Mon, 9 Dec 2013 13:28:06 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id E52A91AE586 for ; Mon, 9 Dec 2013 13:28:04 -0800 (PST) Received: from [192.168.1.100] ([84.92.149.4]) by avasout04 with smtp id zZTw1m00205w0Nk01ZTxJy; Mon, 09 Dec 2013 21:27:58 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=C6LQl2/+ c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=crK2bTrhSLoA:10 a=OZAIM3IXDPUA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=U1ZSPVn_UXUA:10 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=jPBYgwADTMABCcHdWQUA:9 a=wPNLvfGTeEIA:10 a=PgLAuiSjgOYA:10 a=mhd2NDuUijAA:10 Message-ID: <52A635DC.1040708@hansfords.net> Date: Mon, 09 Dec 2013 21:27:56 +0000 From: Jonathan Hansford User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , rob.enns@gmail.com, mbj@tail-f.com, andy.bierman@brocade.com, bclaise@cisco.com, joelja@bogus.com, mehmet.ersue@nsn.com, netconf@ietf.org References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131209210752.GA70828@elstar.local> In-Reply-To: <20131209210752.GA70828@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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, 09 Dec 2013 21:28:08 -0000 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 > From jonathan@hansfords.net Tue Dec 10 03:22:19 2013 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 DA3391ADF6D for ; Tue, 10 Dec 2013 03:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 fGtJod7NZ81A for ; Tue, 10 Dec 2013 03:22:16 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 737E51ADF4B for ; Tue, 10 Dec 2013 03:22:15 -0800 (PST) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id znN81m00B283uBY01nN95M; Tue, 10 Dec 2013 11:22:10 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=C6LQl2/+ c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=fEVyH4MXk-0A:10 a=0B8HqoTn75oA:10 a=lxldWUwtbAkA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=NcN8dwhvxXUA:10 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=YHJ6EVaUX2EDRBK0ssMA:9 a=QEXdDO2ut3YA:10 a=PgLAuiSjgOYA:10 a=mhd2NDuUijAA:10 a=lZB815dzVvQA:10 a=9FRUSnrXfWB8m8DxySUA:9 a=OGvLclL1o53Gvw_M:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 10 Dec 2013 11:22:08 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_f6ce1fce99e4399e2a8919b17a95cd29" Date: Tue, 10 Dec 2013 11:22:08 +0000 From: Jonathan Hansford To: In-Reply-To: <52A635DC.1040708@hansfords.net> References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131209210752.GA70828@elstar.local> <52A635DC.1040708@hansfords.net> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] 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: Tue, 10 Dec 2013 11:22:20 -0000 --=_f6ce1fce99e4399e2a8919b17a95cd29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Is there any way of adding Notes to an existing erratum? I cannot find one. 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 [1] 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 Links: ------ [1] http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table --=_f6ce1fce99e4399e2a8919b17a95cd29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Is there any way of adding Notes to an existing erratum? I cannot find o= ne. 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 th= e adjective (meaning "firmly established") but rather that the commit needs= to be confirmed. It also emphasises that a "confirming commit" cannot be r= everted. Finally it identifies that it is possible to have a sequence of "c= onfirmed commits" prior to a "confirming commit" and that, should no "confi= rming commit" be received, the configuration will revert to the state prior= to the first "confirmed commit" in the sequence.

Erratum 3822:<= br />This erratum seeks to clarify that <cancel-commit> will cancel a= ll configuration changes arising from a sequence of "confirmed commits".
Erratum 3823:
This erratum seeks to clarify that the use of t= he "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=20
email and the subsequent thread about confirmed commits=20
(http://www.ietf.org/mail-archive/web/netconf/current/msg08314.html=
).=20
Consequently there has already been some discussion around the issue.=20
The points I was seeking to clarify related to the definition of the=20
term "Confirmed commit" (something that makes sense to those who have=20
had exposure to JUNOS but appeared counter-intuitive to me in that a=20
confirmed commit is one that hasn't yet been confirmed) and the fact=20
that it is possible to have a sequence of confirmed commits prior to the=20
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 +0= 100, Bert Wijnen (IETF) wrote:
We have a set of 3 new errata reporte= d to RFC6241. See: http://www.rfc-edit= or.org/errata_search.php?rfc=3D6241&rec_status=3D15&presentation=3D= 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 t= oo. 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 w= hat the submitter wants to achieve with these errata. Since these are techn= ical errata, it should be possible to describe the problem/bug that is bein= g fixed. It seems that the submitter is trying to address multiple issues i= n those changes. Anyway, an explanation would have been nice to have. /js 
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf=
=2Eorg/mailman/listinfo/netconf
--=_f6ce1fce99e4399e2a8919b17a95cd29-- From mbj@tail-f.com Tue Dec 10 04:28:26 2013 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 A41EE1AE002 for ; Tue, 10 Dec 2013 04:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWe0Ue_EbDjz for ; Tue, 10 Dec 2013 04:28:25 -0800 (PST) Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 848081ADFA2 for ; Tue, 10 Dec 2013 04:28:25 -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 7E55E37C02A; Tue, 10 Dec 2013 13:28:19 +0100 (CET) Date: Tue, 10 Dec 2013 13:28:19 +0100 (CET) Message-Id: <20131210.132819.2303764306420511964.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <52A62972.4010001@bwijnen.net> References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> 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: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, andy.bierman@brocade.com 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: Tue, 10 Dec 2013 12:28:26 -0000 "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. I think the proposed text is fine, however I do not know if it qualifies as an errata. IMO it clarifies the description of confirmed-commit, but the current text is not wrong. /martin From lhotka@nic.cz Tue Dec 10 04:45:22 2013 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 80A3A1AE02F for ; Tue, 10 Dec 2013 04:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.352 X-Spam-Level: X-Spam-Status: No, score=-0.352 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, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-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 Pb_cQC5iP8UF for ; Tue, 10 Dec 2013 04:45:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E5FB61ADF5F for ; Tue, 10 Dec 2013 04:45:20 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 047BA13F98D; Tue, 10 Dec 2013 13:45:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1386679515; bh=sEPn/zjpelq12QCd2YEc5rFEfQSNoWy1C8VhJOc0kzI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=L7xh8S7MwgwL7vG9AxYrCpWmA1LjGfvQkYqIZmRYiQAacN2wYRzLZ5TDx0rwNaF3K p8ms8MpMnDsocUJB5jyzObwEZ0c6jk9gMhBQx2pTwbBZI/cZenCJFlv0qaOML9PkWt 3E8XhMUYqrjpQNYANIZtIBiYoTLBGF3Z0spFvU6I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ladislav Lhotka In-Reply-To: <20131210.132819.2303764306420511964.mbj@tail-f.com> Date: Tue, 10 Dec 2013 13:45:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1822) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: rob.enns@gmail.com, joelja@bogus.com, andy.bierman@brocade.com, Netconf 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: Tue, 10 Dec 2013 12:45:22 -0000 On 10 Dec 2013, at 13:28, Martin Bjorklund wrote: > "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=3D6241&rec_status=3D15&pre= sentation=3Dtable >>=20 >> We would like to hear from the authors/editors what their >> opinion is on the reported errata. >=20 > I think the proposed text is fine, however I do not know if it > qualifies as an errata. IMO it clarifies the description of > confirmed-commit, but the current text is not wrong. So perhaps it might qualify as an editorial erratum, rather than = technical? Lada >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Tue Dec 10 04:54:26 2013 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 838D91AE043 for ; Tue, 10 Dec 2013 04:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.555 X-Spam-Level: * X-Spam-Status: No, score=1.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWnli1FxJZLr for ; Tue, 10 Dec 2013 04:54:25 -0800 (PST) Received: from postgirl.ripe.net (unknown [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8F1ADED7 for ; Tue, 10 Dec 2013 04:54:24 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VqMpJ-0005nq-TX; Tue, 10 Dec 2013 13:54:15 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest180.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VqMpJ-0008Si-Oo; Tue, 10 Dec 2013 13:54:13 +0100 Message-ID: <52A70EF5.2070201@bwijnen.net> Date: Tue, 10 Dec 2013 13:54:13 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Bjorklund References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> In-Reply-To: <20131210.132819.2303764306420511964.mbj@tail-f.com> 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: 86ab03e524994f79ca2c75a176445dd40563b4d4cbc9cc1b9374fd27feed16a0 Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, andy.bierman@brocade.com 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: Tue, 10 Dec 2013 12:54:26 -0000 I we all agree, then we can leave it, but we should then categorize it as an editorial change and not as a technical change. Not sure if we(or rfc-editor) can/must do that. Will try to find out. Bert On 12/10/13 1:28 PM, Martin Bjorklund wrote: > "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. > > I think the proposed text is fine, however I do not know if it > qualifies as an errata. IMO it clarifies the description of > confirmed-commit, but the current text is not wrong. > > > /martin > > From jonathan@hansfords.net Tue Dec 10 04:50:34 2013 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 B76221AE058 for ; Tue, 10 Dec 2013 04:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 QS1qY-N95lRy for ; Tue, 10 Dec 2013 04:50:32 -0800 (PST) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 31EEC1AE043 for ; Tue, 10 Dec 2013 04:50:32 -0800 (PST) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id zoqR1m0011SbfYc01oqRDg; Tue, 10 Dec 2013 12:50:25 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Z9fVQhhA c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=OZAIM3IXDPUA:10 a=0B8HqoTn75oA:10 a=lxldWUwtbAkA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=U1ZSPVn_UXUA:10 a=SUE4xeBjAAAA:8 a=BqEg4_3jAAAA:8 a=Ad2uro4BRyVbChx5SPAA:9 a=QEXdDO2ut3YA:10 a=mhd2NDuUijAA:10 a=jFPUFpGHtmAA:10 a=0N9LTMhsuN-R5-XuJrUA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 10 Dec 2013 12:50:25 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_8b12850d408a397ed3350d8fe54f8b15" Date: Tue, 10 Dec 2013 12:50:25 +0000 From: Jonathan Hansford To: Martin Bjorklund In-Reply-To: <20131210.132819.2303764306420511964.mbj@tail-f.com> References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> Message-ID: <5b0a33c781e844d8ea6eeed786f175a1@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] X-Mailman-Approved-At: Tue, 10 Dec 2013 04:56:21 -0800 Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, andy.bierman@brocade.com 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: Tue, 10 Dec 2013 12:50:34 -0000 --=_8b12850d408a397ed3350d8fe54f8b15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 But, short of an RFC6241-bis (which I can't see occurring any time soon), how else can the clarification be made available to readers of the RFC? They might find the information if they search the Netconf Discussion Archive, but that isn't particularly easy nor guaranteed to provide the information needed (even assuming they realise there is a need for clarification). For people who have been involved in all the discussions on NETCONF since RFC 3535 much of this is presumably obvious, but for those of us seeking to understand NETCONF based primarily on a reading of the RFCs (in the absence of any book written on the subject), it would be really useful if any clarifications that arise through the Netconf Discussion Archive could be made more easily available, maybe as annotations rather than errata. On 2013-12-10 12:28, Martin Bjorklund wrote: > "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 [1] We would like to hear from the authors/editors what their opinion is on the reported errata. > > I think the proposed text is fine, however I do not know if it > qualifies as an errata. IMO it clarifies the description of > confirmed-commit, but the current text is not wrong. > > /martin Links: ------ [1] http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table --=_8b12850d408a397ed3350d8fe54f8b15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

But, short of an RFC6241-bis (which I can't see occurring any time soon)= , how else can the clarification be made available to readers of the RFC? T= hey might find the information if they search the Netconf Discussion Archiv= e, but that isn't particularly easy nor guaranteed to provide the informati= on needed (even assuming they realise there is a need for clarification). F= or people who have been involved in all the discussions on NETCONF since RF= C 3535 much of this is presumably obvious, but for those of us seeking to u= nderstand NETCONF based primarily on a reading of the RFCs (in the absence = of any book written on the subject), it would be really useful if any clari= fications that arise through the Netconf Discussion Archive could be made m= ore easily available, maybe as annotations rather than errata.

On 2013-12-10 12:28, Martin Bjorklund wrote:

"Bert Wijnen (IETF)" <berti=
etf@bwijnen.net> wrote:
We have a set of 3 new errata reporte= d to RFC6241. See: http://www.rfc-edit= or.org/errata_search.php?rfc=3D6241&rec_status=3D15&presentation=3D= table We would like to hear from the authors/editors what their opinion= is on the reported errata.
I think the proposed text is fine, however I do not know if it
qualifies as an errata.  IMO it clarifies the description of
confirmed-commit, but the current text is not wrong.


/martin
--=_8b12850d408a397ed3350d8fe54f8b15-- From bertietf@bwijnen.net Tue Dec 10 06:25:24 2013 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 8624A1ADF82 for ; Tue, 10 Dec 2013 06:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL6wupoDWnBy for ; Tue, 10 Dec 2013 06:25:23 -0800 (PST) Received: from postgirl.ripe.net (unknown [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id DE3BD1ADFA2 for ; Tue, 10 Dec 2013 06:25:22 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VqOFO-0008Kr-UQ; Tue, 10 Dec 2013 15:25:16 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest180.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VqOFO-0002dA-Q7; Tue, 10 Dec 2013 15:25:14 +0100 Message-ID: <52A7244A.4090006@bwijnen.net> Date: Tue, 10 Dec 2013 15:25:14 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Martin Bjorklund References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> In-Reply-To: <20131210.132819.2303764306420511964.mbj@tail-f.com> 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: 86ab03e524994f79ca2c75a176445dd45767ab938779446f16612760250c7d3f Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org, andy.bierman@brocade.com 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: Tue, 10 Dec 2013 14:25:24 -0000 Martin, did you mean to make this statement for all 3 reported errata, or just for 3821? If anyone disagrees with Martin's assessment, pls speak up NOW. Thanks, Bert On 12/10/13 1:28 PM, Martin Bjorklund wrote: > "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. > > I think the proposed text is fine, however I do not know if it > qualifies as an errata. IMO it clarifies the description of > confirmed-commit, but the current text is not wrong. > > > /martin > > From mbj@tail-f.com Tue Dec 10 06:36:59 2013 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 7CCF81AC403 for ; Tue, 10 Dec 2013 06:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5k85MZu8FcP for ; Tue, 10 Dec 2013 06:36:58 -0800 (PST) Received: from mail.tail-f.com (unknown [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id EBE3E1A1F65 for ; Tue, 10 Dec 2013 06:36:57 -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 9BC8E240C038; Tue, 10 Dec 2013 15:36:51 +0100 (CET) Date: Tue, 10 Dec 2013 15:36:51 +0100 (CET) Message-Id: <20131210.153651.1182516105923318005.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <52A7244A.4090006@bwijnen.net> References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> 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: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org 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: Tue, 10 Dec 2013 14:36:59 -0000 [fixing andy's address] "Bert Wijnen (IETF)" wrote: > Martin, did you mean to make this statement for all 3 reported errata, > or just for 3821? All three. Editorial errata is fine with me. /martin > > If anyone disagrees with Martin's assessment, pls speak up NOW. > > Thanks, > Bert > > On 12/10/13 1:28 PM, Martin Bjorklund wrote: > > "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. > > > > I think the proposed text is fine, however I do not know if it > > qualifies as an errata. IMO it clarifies the description of > > confirmed-commit, but the current text is not wrong. > > > > > > /martin > > > > > From j.schoenwaelder@jacobs-university.de Tue Dec 10 07:54:37 2013 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 A213E1ADF7C for ; Tue, 10 Dec 2013 07:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 OCdePXJe50U0 for ; Tue, 10 Dec 2013 07:54:35 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 73DB31AD7C5 for ; Tue, 10 Dec 2013 07:54:35 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A6C32008E; Tue, 10 Dec 2013 16:54:30 +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 Jur034QHx01h; Tue, 10 Dec 2013 16:54:29 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E0AE92007B; Tue, 10 Dec 2013 16:54:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A437429F894B; Tue, 10 Dec 2013 16:54:22 +0100 (CET) Date: Tue, 10 Dec 2013 16:54:22 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20131210155422.GA73983@elstar.local> Mail-Followup-To: Martin Bjorklund , bertietf@bwijnen.net, rob.enns@gmail.com, andy@yumaworks.com, bclaise@cisco.com, joelja@bogus.com, mehmet.ersue@nsn.com, jonathan@hansfords.net, netconf@ietf.org References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131210.153651.1182516105923318005.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) 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, 10 Dec 2013 15:54:37 -0000 On Tue, Dec 10, 2013 at 03:36:51PM +0100, Martin Bjorklund wrote: > [fixing andy's address] > > "Bert Wijnen (IETF)" wrote: > > Martin, did you mean to make this statement for all 3 reported errata, > > or just for 3821? > > All three. > > Editorial errata is fine with me. > If we ever update RFC 6241, perhaps we can find a better solution to avoid the "confirmed commit" means "to-be-confirmed commit" confusion in the first place. The other changes (being more precise that it is a sequence of confirmed commits and the more detailed list what is impacted by the :confirmed-commit:1.1 capability) are fine. I am OK with this as an editorial errata. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From joelja@bogus.com Tue Dec 10 07:55:54 2013 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 945C41AE052 for ; Tue, 10 Dec 2013 07:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 IZHqziU_EZra for ; Tue, 10 Dec 2013 07:55:53 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 331481ADFA4 for ; Tue, 10 Dec 2013 07:55:53 -0800 (PST) Received: from mb-aye.local (c-50-174-18-221.hsd1.ca.comcast.net [50.174.18.221]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id rBAFtZnr090975 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 10 Dec 2013 15:55:36 GMT (envelope-from joelja@bogus.com) Message-ID: <52A73971.4020900@bogus.com> Date: Tue, 10 Dec 2013 07:55:29 -0800 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Thunderbird/26.0 MIME-Version: 1.0 To: Jonathan Hansford , Martin Bjorklund References: <20131206100737.B33EB7FC383@rfc-editor.org> <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <5b0a33c781e844d8ea6eeed786f175a1@imap.plus.net> In-Reply-To: <5b0a33c781e844d8ea6eeed786f175a1@imap.plus.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ULjDglASIiVpNrQ1Qo2ghgV81lPuVQqxD" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Tue, 10 Dec 2013 15:55:36 +0000 (UTC) Cc: rob.enns@gmail.com, netconf@ietf.org, andy.bierman@brocade.com 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: Tue, 10 Dec 2013 15:55:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ULjDglASIiVpNrQ1Qo2ghgV81lPuVQqxD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/10/13, 4:50 AM, Jonathan Hansford wrote: > =20 >=20 > But, short of an RFC6241-bis (which I can't see occurring any time > soon), how else can the clarification be made available to readers of > the RFC? They might find the information if they search the Netconf > Discussion Archive, but that isn't particularly easy nor guaranteed to > provide the information needed (even assuming they realise there is a > need for clarification). For people who have been involved in all the > discussions on NETCONF since RFC 3535 much of this is presumably > obvious, but for those of us seeking to understand NETCONF based > primarily on a reading of the RFCs (in the absence of any book written > on the subject), it would be really useful if any clarifications that > arise through the Netconf Discussion Archive could be made more easily > available, maybe as annotations rather than errata.=20 Imho this is not an appropriate use of the errata system. if there is something wrong (with 6241) e.g. the 3822 errata is necessary for correct implementation that's one thing, if the are clarifying we should not be handling them in this fashion. > On 2013-12-10 > 12:28, Martin Bjorklund wrote:=20 >=20 >> "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=3D6241&rec_status=3D15&= presentation=3Dtable > [1] We would like to hear from the authors/editors what their opinion > is on the reported errata. >> >> I think the proposed text is fine, > however I do not know if it >> qualifies as an errata. IMO it clarifies > the description of >> confirmed-commit, but the current text is not > wrong. >> >> /martin > =20 >=20 > Links: > ------ > [1] > http://www.rfc-editor.org/errata_search.php?rfc=3D6241&rec_status=3D= 15&presentation=3Dtable >=20 --ULjDglASIiVpNrQ1Qo2ghgV81lPuVQqxD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKnOXIACgkQ8AA1q7Z/VrJ6KgCeOQk1YBIGJ4dZQISp1MFso5nO 1XgAnRppg/5xp43Ata9RlfnHPkPS56mB =GnmC -----END PGP SIGNATURE----- --ULjDglASIiVpNrQ1Qo2ghgV81lPuVQqxD-- From andy@yumaworks.com Tue Dec 10 07:59:10 2013 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 4CE751AE098 for ; Tue, 10 Dec 2013 07:59: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 UJWDrsneXTcw for ; Tue, 10 Dec 2013 07:59:08 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 385DD1ADFA4 for ; Tue, 10 Dec 2013 07:59:08 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id nd7so4279575qeb.31 for ; Tue, 10 Dec 2013 07:59:02 -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=vMW4d2VqaUD3aWRJ2uFr4beB+F3KnnwpXi9laXjznCU=; b=kVfouRi2BiOCe4v7bGxexAwZKU1J5JHle6MBwVJ3DHqKE6sxff4ZvQrV0EqJPjB+Pl 4tqWvKnalIY4CFYdwn+OjnQDHOsDGRfzy825MPKIetul+SDjU1SdCxPyXPKL7RbYQndu rPGnHhf2ZXLbrcoT3h7/oBUWscIJtu91OD7TBraS2rCzXpfTaSTzSnw4Rco5orsJ+Trl 49pgX0O+5as5ZmPdm9aBJlYut9AjiuWEJx0mBbwF/zX5NmzJoTNqhMydRm28JuqDF2b2 4z/+U4doGGewC452ZmGVDO+Ivfi5E0y26JlyEoChjnDx7kVONmMGe3at8cUb/Pdu6hsX I6Rg== X-Gm-Message-State: ALoCoQnsHMDX9zwDJFz3HiyG6qHrmv1cCSTVVpeC+L3n/MDTpl6nhoUlHDaSEqQAGUsdBX6rgYLa MIME-Version: 1.0 X-Received: by 10.224.51.74 with SMTP id c10mr46576748qag.7.1386691142669; Tue, 10 Dec 2013 07:59:02 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 07:59:02 -0800 (PST) In-Reply-To: <20131210.153651.1182516105923318005.mbj@tail-f.com> References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> Date: Tue, 10 Dec 2013 07:59:02 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0158cb54f905f204ed303068 Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf 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: Tue, 10 Dec 2013 15:59:10 -0000 --089e0158cb54f905f204ed303068 Content-Type: text/plain; charset=ISO-8859-1 Hi, I don't think these 3 reports are corrections. They are editorial changes to the text. I don't agree that the new terminology added "sequence of confirmed commits" is correct. There is just 1 netconf-confirmed-commit notification for start & complete sent out no matter how how many times the procedure is extended. If the procedure ends with a cancel or timeout, there is only 1 original commit that is restored. It is incorrect to think of this procedure as a series of confirmed commits. A commit that extends the procedure is not treated the same as the commit that starts the procedure. Andy On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund wrote: > [fixing andy's address] > > "Bert Wijnen (IETF)" wrote: > > Martin, did you mean to make this statement for all 3 reported errata, > > or just for 3821? > > All three. > > Editorial errata is fine with me. > > > /martin > > > > > > If anyone disagrees with Martin's assessment, pls speak up NOW. > > > > Thanks, > > Bert > > > > On 12/10/13 1:28 PM, Martin Bjorklund wrote: > > > "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. > > > > > > I think the proposed text is fine, however I do not know if it > > > qualifies as an errata. IMO it clarifies the description of > > > confirmed-commit, but the current text is not wrong. > > > > > > > > > /martin > > > > > > > > > --089e0158cb54f905f204ed303068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I don't think these 3 reports a= re corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of confirm= ed commits"
is correct. =A0There is just 1 netconf-confirmed-commit notification f= or start & complete
sent out no matter how how many times the= procedure is extended.

If the procedure ends with a cancel or timeout, there is only 1 original co= mmit
that is restored. =A0It is incorrect t= o think of this procedure as a series of
co= nfirmed commits. =A0A commit that extends the procedure is not treated
the same as the commit that starts the procedure= .


=
Andy

<= br>
On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
[fixing andy's address]

"Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
> Martin, did you mean to make this statement for all 3 reported errata,=
> or just for 3821?

All three.

Editorial errata is fine with me.


/martin


>
> If anyone disagrees with Martin's assessment, pls speak up NOW. >
> Thanks,
> Bert
>
> On 12/10/13 1:28 PM, Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
> >> We have a set of 3 new errata reported to RFC6241.
> >> See:
> >> http:/= /www.rfc-editor.org/errata_search.php?rfc=3D6241&rec_status=3D15&pr= esentation=3Dtable
> >>
> >> We would like to hear from the authors/editors what their
> >> opinion is on the reported errata.
> >
> > I think the proposed text is fine, however I do not know if it > > qualifies as an errata. =A0IMO it clarifies the description of > > confirmed-commit, but the current text is not wrong.
> >
> >
> > /martin
> >
> >
>

--089e0158cb54f905f204ed303068-- From andy@yumaworks.com Tue Dec 10 08:15:20 2013 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 BAB951ADF4F for ; Tue, 10 Dec 2013 08:15: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 XMubIPNYZ766 for ; Tue, 10 Dec 2013 08:15:18 -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 0223C1ADFC3 for ; Tue, 10 Dec 2013 08:15:17 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id c9so4152979qcz.30 for ; Tue, 10 Dec 2013 08:15: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=EMCnngqgE9H3bQ63hg7cGh+Ngv5bjs0vaRC7ryCZGUs=; b=gIYSpZTxg8DZqOfhn6YbXxdQZgaj8A27G7XNf/uknkUQ18kK2Za76bg3s1NjhqLbmb 2ThqhCjDagnVQzkrxblkoYgsdW7mZ+ctEBeFnydWm/lzXeMG3hWP4yMquts0BUKscYBu M31bqi3TxuH4r5U3d+Krv25N6i7H5lpIyg8eYVLgsQWHLuhQCo/HZZB4HV7aNN6vHNEL QfyMba/VUAzqNwjexdPIXQGH8e8GHfsOBIv0bgjA7nCLkCg7J8sFk092i/n6ckGadslj /dNAdcgyIhIvkARIftbzHdxquP50x5bVUIfjxbVQjzdNekAuP6HuyVoQfNj7GTK4dhgR 3CaA== X-Gm-Message-State: ALoCoQk34loWcV13dqj9+coUh/5nIxv3sXB7CbFqugYr1uLSHvTZGDecGNss4Wjza6ZVCv2IC8tZ MIME-Version: 1.0 X-Received: by 10.224.39.15 with SMTP id d15mr45753836qae.36.1386692112544; Tue, 10 Dec 2013 08:15:12 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 08:15:12 -0800 (PST) In-Reply-To: References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> Date: Tue, 10 Dec 2013 08:15:12 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a1134a56ac7fee604ed306a3a Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf 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: Tue, 10 Dec 2013 16:15:20 -0000 --001a1134a56ac7fee604ed306a3a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford wrote: > > > On 2013-12-10 15:59, Andy Bierman wrote: > > Hi, > I don't think these 3 reports are corrections. > They are editorial changes to the text. > I don't agree that the new terminology added "sequence of confirmed > commits" > is correct. There is just 1 netconf-confirmed-commit notification for > start & complete > sent out no matter how how many times the procedure is extended. > If the procedure ends with a cancel or timeout, there is only 1 original > commit > that is restored. It is incorrect to think of this procedure as a series > of > confirmed commits. A commit that extends the procedure is not treated > the same as the commit that starts the procedure. > > Are you saying that the initial commit of the sequence (the confirmed > commit?) is restored should the procedure be cancelled or timeout? Surely > the commit that is restored is the one that preceded the confirmed commit. > The confirmed commit is the first that includes a parameter. The 2nd - Nth are extending the first commit operation. The server is still obligated to revert the running config for the first commit (if it is canceled or timed out). This obligation is not removed because the commit is extended. It is only removed if a confirming commit is received. Jonathan > Andy > Andy > > > On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund wrote: > >> [fixing andy's address] >> >> "Bert Wijnen (IETF)" wrote: >> > Martin, did you mean to make this statement for all 3 reported errata, >> > or just for 3821? >> >> All three. >> >> Editorial errata is fine with me. >> >> >> /martin >> >> >> > >> > If anyone disagrees with Martin's assessment, pls speak up NOW. >> > >> > Thanks, >> > Bert >> > >> > On 12/10/13 1:28 PM, Martin Bjorklund wrote: >> > > "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. >> > > >> > > I think the proposed text is fine, however I do not know if it >> > > qualifies as an errata. IMO it clarifies the description of >> > > confirmed-commit, but the current text is not wrong. >> > > >> > > >> > > /martin >> > > >> > > >> > > > --001a1134a56ac7fee604ed306a3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford <Jonathan@= hansfords.net> wrote:

=A0

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of con= firmed commits"
is correct. =A0There is just 1 netconf-confirmed-commit notification f= or start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored. =A0It is incorrect to think of= this procedure as a series of
confirmed commits. =A0A commit that extends the = procedure is not treated
the same as the commit that starts the procedure= .
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.



= The confirmed commit is the first <commit> that includes a <confir= med> parameter.
The 2nd - Nth <commit> are extending the= first commit operation. =A0The server is still
obligated to revert the running config for the first commit (if it is = canceled or timed out).
This obligation is not removed because th= e commit is extended. =A0It is only removed
if a confirming commi= t is received.



Jonathan

=

Andy
=A0
=
Andy


On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklun= d <mbj@tail-f.= com> wrote:
[fixing andy's address]

"Be= rt Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
> Martin, did you mean to make this statement for all 3 reported errata= ,
> or just for 3821?

All three.

Editorial errata is= fine with me.


/martin


>
> If anyone disa= grees with Martin's assessment, pls speak up NOW.
>
> Thanks,
> Bert
>
> On 12/10/13 1:28 PM,= Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)" <<= a href=3D"mailto:bertietf@bwijnen.net" target=3D"_blank">bertietf@bwijnen.n= et> wrote:
> >> We have a set of 3 new errata reported to RFC6241.
> = >> See:
> >> http://www.rfc-editor.org/errata_search.php?rfc=3D6241&rec_= status=3D15&presentation=3Dtable
> >>
> >> We would like to hear from the authors/edi= tors what their
> >> opinion is on the reported errata.
&g= t; >
> > I think the proposed text is fine, however I do not k= now if it
> > qualifies as an errata. =A0IMO it clarifies the description of > > confirmed-commit, but the current text is not wrong.
> = >
> >
> > /martin
> >
> >
&g= t;

--001a1134a56ac7fee604ed306a3a-- From jonathan@hansfords.net Tue Dec 10 08:26:52 2013 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 7BDA41AE03D for ; Tue, 10 Dec 2013 08:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 px5j5fSp5zZV for ; Tue, 10 Dec 2013 08:26:49 -0800 (PST) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3D1AD8F0 for ; Tue, 10 Dec 2013 08:26:49 -0800 (PST) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id zsSj1m0071SbfYc01sSjd6; Tue, 10 Dec 2013 16:26:43 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Z9fVQhhA c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=OZAIM3IXDPUA:10 a=0B8HqoTn75oA:10 a=lxldWUwtbAkA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=U1ZSPVn_UXUA:10 a=u07AKapRAAAA:8 a=SUE4xeBjAAAA:8 a=BqEg4_3jAAAA:8 a=sr8DB3k7OHan1JxBuMEA:9 a=QEXdDO2ut3YA:10 a=mhd2NDuUijAA:10 a=1rgnPY4EEFsA:10 a=XqebBV1NYWwA:10 a=jFPUFpGHtmAA:10 a=KnnnJg_a4gd-VWB_GYIA:9 a=zVlx6iei4MeMW_MR:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 10 Dec 2013 16:26:43 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_a21918c51cd62344439071e67050bff2" Date: Tue, 10 Dec 2013 16:26:43 +0000 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> Message-ID: <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf 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: Tue, 10 Dec 2013 16:26:52 -0000 --=_a21918c51cd62344439071e67050bff2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2013-12-10 16:15, Andy Bierman wrote: > On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford wrote: > >> On 2013-12-10 15:59, Andy Bierman wrote: >> >>> Hi, >>> I don't think these 3 reports are corrections. >>> They are editorial changes to the text. >>> I don't agree that the new terminology added "sequence of confirmed commits" >>> is correct. There is just 1 netconf-confirmed-commit notification for start & complete >>> sent out no matter how how many times the procedure is extended. >>> >>> If the procedure ends with a cancel or timeout, there is only 1 original commit >>> that is restored. It is incorrect to think of this procedure as a series of >>> confirmed commits. A commit that extends the procedure is not treated >>> the same as the commit that starts the procedure. >> >> Are you saying that the initial commit of the sequence (the confirmed commit?) is restored should the procedure be cancelled or timeout? Surely the commit that is restored is the one that preceded the confirmed commit. > > The confirmed commit is the first that includes a parameter. > The 2nd - Nth are extending the first commit operation. The server is still > obligated to revert the running config for the first commit (if it is canceled or timed out). > This obligation is not removed because the commit is extended. It is only removed > if a confirming commit is received. Andy, I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd paragraph) talks about 'a follow-up confirmed operation'. Are you saying that that second 'confirmed ' (i.e. a with the parameter) is not a "confirmed commit"? And when you say 'the server is obligated to revert the running config for the first commit' do you mean revert to the state prior to that first confirmed ? Jonathan >> Jonathan > > Andy > >>> Andy >>> >>> On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund wrote: >>> >>>> [fixing andy's address] >>>> >>>> "Bert Wijnen (IETF)" wrote: >>>> > Martin, did you mean to make this statement for all 3 reported errata, >>>> > or just for 3821? >>>> >>>> All three. >>>> >>>> Editorial errata is fine with me. >>>> >>>> /martin >>>> >>>> > >>>> > If anyone disagrees with Martin's assessment, pls speak up NOW. >>>> > >>>> > Thanks, >>>> > Bert >>>> > >>>> > On 12/10/13 1:28 PM, Martin Bjorklund wrote: >>>> > > "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 [4] >>>> > >> >>>> > >> We would like to hear from the authors/editors what their >>>> > >> opinion is on the reported errata. >>>> > > >>>> > > I think the proposed text is fine, however I do not know if it >>>> > > qualifies as an errata. IMO it clarifies the description of >>>> > > confirmed-commit, but the current text is not wrong. >>>> > > >>>> > > >>>> > > /martin >>>> > > >>>> > > >>>> > Links: ------ [1] mailto:Jonathan@hansfords.net [2] mailto:bertietf@bwijnen.net [3] mailto:bertietf@bwijnen.net [4] http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table [5] mailto:mbj@tail-f.com --=_a21918c51cd62344439071e67050bff2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 2013-12-10 16:15, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansfo= rd <Jonathan@hansfords= =2Enet> wrote:

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of confirmed co= mmits"
is correct.  There is just 1 netconf-confirmed-commit notificatio= n for start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored.  It is incorrect to think= of this procedure as a series of
confirmed commits.  A commit that extends t= he procedure is not treated
the same as the commit that starts the procedure= =2E
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
The confirmed commit is the first <commit> that includes a <c= onfirmed> parameter.
The 2nd - Nth <commit> are extending the first commit operation= =2E  The server is still
obligated to revert the running config for the first commit (if it is = canceled or timed out).
This obligation is not removed because the commit is extended.  I= t is only removed
if a confirming commit is received.
Andy,
I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd= paragraph) talks about 'a follow-up confirmed <commit> operation'. A= re you saying that that second 'confirmed <commit>' (i.e. a <commi= t> with the <confirmed> parameter) is not a "confirmed commit"? An= d when you say 'the server is obligated to revert the running config for th= e first commit' do you mean revert to the state prior to that first confirm= ed <commit>?
Jonathan
Jonathan
Andy
Andy


On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklun= d <mbj@tail-f.com>= wrote:
[fixing andy's address]

"Bert Wijnen (IETF)" <bertiet= f@bwijnen.net> wrote:
> Martin, did you mean to make this s= tatement for all 3 reported errata,
> or just for 3821?

All three.

Editorial errata is fine with me.


/martin


>
> If anyone disagrees with Martin= 's assessment, pls speak up NOW.
>
> Thanks,
> B= ert
>
> On 12/10/13 1:28 PM, Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
> >> We have a set of = 3 new errata reported to RFC6241.
> >> See:
> >&= gt; http://www.rfc-editor.org/errata_s= earch.php?rfc=3D6241&rec_status=3D15&presentation=3Dtable
= > >>
> >> We would like to hear from the authors/e= ditors what their
> >> opinion is on the reported errata. > >
> > I think the proposed text is fine, however I = do not know if it
> > qualifies as an errata.  IMO it clar= ifies the description of
> > confirmed-commit, but the current = text is not wrong.
> >
> >
> > /martin<= br /> > >
> >
>
--=_a21918c51cd62344439071e67050bff2-- From andy@yumaworks.com Tue Dec 10 08:56:02 2013 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 E371A1AE1E1 for ; Tue, 10 Dec 2013 08:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 CIc2fNUnUaQl for ; Tue, 10 Dec 2013 08:56:00 -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 E23D11AE1E2 for ; Tue, 10 Dec 2013 08:55:59 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id i13so3861704qae.2 for ; Tue, 10 Dec 2013 08:55: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=xW5euRgzhHSp07V4RbRlq8bArfMocE7/jA8YhYnf6lk=; b=XYWhc8/i34QXpkIQpwH9giO10RZUjiyCF8R6FGXoDD17N+mxHKi67x4LtgtCg8pxsr HSFBzSy5i4J/evVrfpfk8ylCLHgDRG1pdS+DpuhgPY+WjmBOAUYboYKe5kdsLN05oWT5 KgnQxWuI4/NgtMPzoBeJoy8xrXY7wL9naLrRwQXZZ32zESd+WNLkMFZodVfztdd68yvJ tZaW4gQDrHn5QRACoglYtTU9DiPiWVtLSVPiWLZARlvjJmuq7AufCg+mmdFQwIrx50+s meGgn2frQVxWmR8/oblF7KdU5YlheBBI7lY4Lh9DeC/S+sb+DA8Wknhg3qP0yJ/IU87N DrVA== X-Gm-Message-State: ALoCoQkO6r6o5Z3g3z2T0yl1RDjf/8yjSJeri/j81ggidqWFYEp38YZEh0KJIsZraYWxUZDxRbVx MIME-Version: 1.0 X-Received: by 10.224.60.69 with SMTP id o5mr46104200qah.92.1386694554337; Tue, 10 Dec 2013 08:55:54 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 08:55:54 -0800 (PST) In-Reply-To: References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> Date: Tue, 10 Dec 2013 08:55:54 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=001a11c3e488537de604ed30fcec Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf 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: Tue, 10 Dec 2013 16:56:03 -0000 --001a11c3e488537de604ed30fcec Content-Type: text/plain; charset=ISO-8859-1 Hi, The fact that it is not clear how confirmed commit works is an indication of just how broken the shared candidate config is in NETCONF. This is an artifact of CLI-based management, where nothing is locked, and the management application is just an SSH terminal. For programmatic applications, a shared scratchpad on the server is a terrible design choice. The NETCONF-EX draft fixes 1 or 2 of the many problems (e.g., decouple confirmed-commit from candidate), but it does not attempt to allow concurrent or independent transactions. The persist-id supplies a long-lived lock on the operation, but not against other sessions writing to the candidate (w/ edit/copy-config). I found another clarification for confirmed commit. Sec. 8.4.1, para 3: 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. Sec. 8.4.5.1: persist-id: Used to issue a follow-up confirmed commit or a confirming commit from any session, with the token from the previous operation. There is no mention in 8.4.5.1 which error-tag to return if the persist-id parameter is missing or wrong. (in-use?). Notice that 8.4.1 says "any follow-up commit" and 8.4.5.1 says "a follow-up confirmed commit"? This might make it unclear that any followup without the proper will be rejected by the server. Andy On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford wrote: > > > On 2013-12-10 15:59, Andy Bierman wrote: > > Hi, > I don't think these 3 reports are corrections. > They are editorial changes to the text. > I don't agree that the new terminology added "sequence of confirmed > commits" > is correct. There is just 1 netconf-confirmed-commit notification for > start & complete > sent out no matter how how many times the procedure is extended. > If the procedure ends with a cancel or timeout, there is only 1 original > commit > that is restored. It is incorrect to think of this procedure as a series > of > confirmed commits. A commit that extends the procedure is not treated > the same as the commit that starts the procedure. > > Are you saying that the initial commit of the sequence (the confirmed > commit?) is restored should the procedure be cancelled or timeout? Surely > the commit that is restored is the one that preceded the confirmed commit. > Jonathan > > Andy > > > On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund wrote: > >> [fixing andy's address] >> >> "Bert Wijnen (IETF)" wrote: >> > Martin, did you mean to make this statement for all 3 reported errata, >> > or just for 3821? >> >> All three. >> >> Editorial errata is fine with me. >> >> >> /martin >> >> >> > >> > If anyone disagrees with Martin's assessment, pls speak up NOW. >> > >> > Thanks, >> > Bert >> > >> > On 12/10/13 1:28 PM, Martin Bjorklund wrote: >> > > "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. >> > > >> > > I think the proposed text is fine, however I do not know if it >> > > qualifies as an errata. IMO it clarifies the description of >> > > confirmed-commit, but the current text is not wrong. >> > > >> > > >> > > /martin >> > > >> > > >> > > > --001a11c3e488537de604ed30fcec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

The fact that it is not clear how confirm= ed commit works is an indication
of just how broken the shared ca= ndidate config is in NETCONF.
This is an artifact of CLI-based ma= nagement, where nothing is locked,
and the management application is just an SSH terminal.

For programmatic appl= ications, a shared scratchpad on the server is
a terrible design choice. =A0The NETCONF-EX draft fixes 1 or 2 of the
=
many problems (e.g., decouple confirmed-commit f= rom candidate),
but it does not attempt to = allow concurrent or independent transactions.

The persist= -id supplies a long-lived lock on the <commit> operation,
but not against other sessions writing to the candidat= e (w/ edit/copy-config).

I found ano= ther clarification for confirmed commit.
Se= c. 8.4.1, para 3:

 =
  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.
=

Sec. 8.4.5.1:

 =
    persist-id:

            Used to issue a follow-up confirmed commit or a confirming
            commit from any session, with the token from the previous
            <commit> operation.

There is no mention in 8.4.5.1 which = error-tag to return if the persist-id parameter is
missing or wrong. (in-use?).

Notice that 8.4.1 says "any follow-up commit&qu= ot; and 8.4.5.1 says "a follow-up
conf= irmed commit"? =A0This might make it unclear that any followup <com= mit> without
the proper <persist-id> will be rejected b= y the server.


Andy


<= br>

On Tue, = Dec 10, 2013 at 8:05 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:

=A0

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of con= firmed commits"
is correct. =A0There is just 1 netconf-confirmed-commit notification f= or start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored. =A0It is incorrect to think of= this procedure as a series of
confirmed commits. =A0A commit that extends the = procedure is not treated
the same as the commit that starts the procedure= .
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
Jonathan
Andy


On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklun= d <mbj@tail-f.= com> wrote:
[fixing andy's address]

"Bert Wijnen (IET= F)" <bert= ietf@bwijnen.net> wrote:
> Martin, did you mean to make this statement for all 3 reported errata= ,
> or just for 3821?

All three.

Editorial errata is= fine with me.


/martin


>
> If anyone disa= grees with Martin's assessment, pls speak up NOW.
>
> Thanks,
> Bert
>
> On 12/10/13 1:28 PM,= Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)" <<= a href=3D"mailto:bertietf@bwijnen.net" target=3D"_blank">bertietf@bwijnen.n= et> wrote:
> >> We have a set of 3 new errata reported to RFC6241.
> = >> See:
> >> http://www.rfc-editor.org/errata_search.php?rfc=3D6241&rec_= status=3D15&presentation=3Dtable
> >>
> >> We would like to hear from the authors/edi= tors what their
> >> opinion is on the reported errata.
&g= t; >
> > I think the proposed text is fine, however I do not k= now if it
> > qualifies as an errata. =A0IMO it clarifies the description of > > confirmed-commit, but the current text is not wrong.
> = >
> >
> > /martin
> >
> >
&g= t;

--001a11c3e488537de604ed30fcec-- From andy@yumaworks.com Tue Dec 10 09:05:57 2013 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 39D061AE22A for ; Tue, 10 Dec 2013 09:05:57 -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 zDsir8wzpKo5 for ; Tue, 10 Dec 2013 09:05:56 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id C9ED41AE226 for ; Tue, 10 Dec 2013 09:05:55 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id n7so3976378qcx.5 for ; Tue, 10 Dec 2013 09:05: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=48nFxqZHo3DEsbWGJbg6/xTKm+0sp+1CbKH9qQ08zWg=; b=kj2mP6xkZeDbJxGcbBpvqFDxlez+Kbnbez6iqPbnIFG/mwYGMKTTDaYnE0NTlc266j RjCOqsoLb4zgvjIjlrlrA95TGQWv/v6vcFoK7YXv//VB5a17k8XsGYLE2GhqhbTtS6Or OYxfR9jzmoGR+xZLQwSkPto18SMJSpjFpMYMSQMnqqbIFBtPNzpgM2Ki4fXZim+AKxGW w4dAJbWVg5ryROzYGvvJuzAEqkM8xPg3MZYSL6oQgFMOfikPNEgfgk7eaWDvMPMezAlE T1ZTy/RVkzv81cbfTgWIDFcdzQfMANJrXjoZNKp+/6UehyCmNttaPY+N1Bwwg281OQdJ za0Q== X-Gm-Message-State: ALoCoQlHnvhSoVv+8lq49D4QxBCmPftc4Vo71Rv3nH0Elweid8V5yM7DqY+xwqU1IZfoESkI8s9Q MIME-Version: 1.0 X-Received: by 10.224.151.209 with SMTP id d17mr28186065qaw.87.1386695150368; Tue, 10 Dec 2013 09:05:50 -0800 (PST) Received: by 10.140.48.75 with HTTP; Tue, 10 Dec 2013 09:05:50 -0800 (PST) In-Reply-To: <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> Date: Tue, 10 Dec 2013 09:05:50 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=089e0149d2c4d9a14804ed311fb5 Cc: Rob Enns , joel jaeggli , Netconf 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: Tue, 10 Dec 2013 17:05:57 -0000 --089e0149d2c4d9a14804ed311fb5 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford wrote: > > > On 2013-12-10 16:15, Andy Bierman wrote: > > > > > On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford > wrote: > >> On 2013-12-10 15:59, Andy Bierman wrote: >> >> Hi, >> I don't think these 3 reports are corrections. >> They are editorial changes to the text. >> I don't agree that the new terminology added "sequence of confirmed >> commits" >> is correct. There is just 1 netconf-confirmed-commit notification for >> start & complete >> sent out no matter how how many times the procedure is extended. >> If the procedure ends with a cancel or timeout, there is only 1 >> original commit >> that is restored. It is incorrect to think of this procedure as a series >> of >> confirmed commits. A commit that extends the procedure is not treated >> the same as the commit that starts the procedure. >> >> Are you saying that the initial commit of the sequence (the confirmed >> commit?) is restored should the procedure be cancelled or timeout? Surely >> the commit that is restored is the one that preceded the confirmed commit. >> > The confirmed commit is the first that includes a > parameter. > The 2nd - Nth are extending the first commit operation. The > server is still > obligated to revert the running config for the first commit (if it is > canceled or timed out). > This obligation is not removed because the commit is extended. It is only > removed > if a confirming commit is received. > > Andy, > I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd > paragraph) talks about 'a follow-up confirmed operation'. Are you > saying that that second 'confirmed ' (i.e. a with the > parameter) is not a "confirmed commit"? And when you say 'the > server is obligated to revert the running config for the first commit' do > you mean revert to the state prior to that first confirmed ? > sec. 8.4.1, para 2: The confirming commit is a operation without the parameter. The 2nd commit with a parameter extends the confirmed-commit procedure. Any cancel or complete applies to this commit. If canceled, then the changes made for the 2nd commit are going to be undone. An extension commit is not a confirming commit. A cancel/timeout causes the config to revert to its state before the first confirmed commit operation. Jonathan > Andy --089e0149d2c4d9a14804ed311fb5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <Jonathan@= hansfords.net> wrote:

=A0

On 2013-12-10 16:15, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansfo= rd <Jo= nathan@hansfords.net> wrote:

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of con= firmed commits"
is correct. =A0There is just 1 netconf-confirmed-commit notification f= or start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored. =A0It is incorrect to think of= this procedure as a series of
confirmed commits. =A0A commit that extends the = procedure is not treated
the same as the commit that starts the procedure= .
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
The confirmed commit is the first <commit> that includes a <c= onfirmed> parameter.
The 2nd - Nth <commit> are extending the first commit operation.= =A0The server is still
obligated to revert the running config for the first commit (if it is = canceled or timed out).
This obligation is not removed because the commit is extended. =A0It i= s only removed
if a confirming commit is received.
Andy,
I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 = (2nd paragraph) talks about 'a follow-up confirmed <commit> opera= tion'. Are you saying that that second 'confirmed <commit>= 9; (i.e. a <commit> with the <confirmed> parameter) is not a &q= uot;confirmed commit"? And when you say 'the server is obligated t= o revert the running config for the first commit' do you mean revert to= the state prior to that first confirmed <commit>?


sec. 8.4.= 1, para 2:

   The confirming commit is a <commit=
> operation
   without the <confirmed> parameter.
=A0
= The 2nd commit with a <confirmed> parameter extends the confirmed-com= mit procedure.
Any cancel or complete applies to this commit. =A0= If canceled, then the changes made for the
2nd commit are going to be undone. =A0An extension commit is not a con= firming commit.
A cancel/timeout causes the config to revert to i= ts state before the first confirmed commit
operation.


Jonathan

Andy
<= div>=A0
--089e0149d2c4d9a14804ed311fb5-- From jonathan@hansfords.net Tue Dec 10 08:05:21 2013 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 959261AE059 for ; Tue, 10 Dec 2013 08:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 qdkeh7f6RY1z for ; Tue, 10 Dec 2013 08:05:18 -0800 (PST) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id D5CD61AE0F6 for ; Tue, 10 Dec 2013 08:05:17 -0800 (PST) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id zs5B1m0091SbfYc01s5BY8; Tue, 10 Dec 2013 16:05:12 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=Z9fVQhhA c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=OZAIM3IXDPUA:10 a=0B8HqoTn75oA:10 a=lxldWUwtbAkA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=U1ZSPVn_UXUA:10 a=u07AKapRAAAA:8 a=SUE4xeBjAAAA:8 a=BqEg4_3jAAAA:8 a=yNDW1slZx-oJOkTWoPcA:9 a=QEXdDO2ut3YA:10 a=mhd2NDuUijAA:10 a=XqebBV1NYWwA:10 a=jFPUFpGHtmAA:10 a=iY4jf9MO24OleQkMi9MA:9 a=-nU-te13jhiyxndQ:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Tue, 10 Dec 2013 16:05:11 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_b51a45fecf8af5e171981c582bcd25a0" Date: Tue, 10 Dec 2013 16:05:11 +0000 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] X-Mailman-Approved-At: Tue, 10 Dec 2013 13:11:08 -0800 Cc: rob.enns@gmail.com, joelja@bogus.com, Netconf 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: Tue, 10 Dec 2013 16:05:21 -0000 --=_b51a45fecf8af5e171981c582bcd25a0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2013-12-10 15:59, Andy Bierman wrote: > Hi, > I don't think these 3 reports are corrections. > They are editorial changes to the text. > I don't agree that the new terminology added "sequence of confirmed commits" > is correct. There is just 1 netconf-confirmed-commit notification for start & complete > sent out no matter how how many times the procedure is extended. > > If the procedure ends with a cancel or timeout, there is only 1 original commit > that is restored. It is incorrect to think of this procedure as a series of > confirmed commits. A commit that extends the procedure is not treated > the same as the commit that starts the procedure. Are you saying that the initial commit of the sequence (the confirmed commit?) is restored should the procedure be cancelled or timeout? Surely the commit that is restored is the one that preceded the confirmed commit. Jonathan > Andy > > On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklund wrote: > >> [fixing andy's address] >> >> "Bert Wijnen (IETF)" wrote: >> > Martin, did you mean to make this statement for all 3 reported errata, >> > or just for 3821? >> >> All three. >> >> Editorial errata is fine with me. >> >> /martin >> >> > >> > If anyone disagrees with Martin's assessment, pls speak up NOW. >> > >> > Thanks, >> > Bert >> > >> > On 12/10/13 1:28 PM, Martin Bjorklund wrote: >> > > "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 [3] >> > >> >> > >> We would like to hear from the authors/editors what their >> > >> opinion is on the reported errata. >> > > >> > > I think the proposed text is fine, however I do not know if it >> > > qualifies as an errata. IMO it clarifies the description of >> > > confirmed-commit, but the current text is not wrong. >> > > >> > > >> > > /martin >> > > >> > > >> > Links: ------ [1] mailto:bertietf@bwijnen.net [2] mailto:bertietf@bwijnen.net [3] http://www.rfc-editor.org/errata_search.php?rfc=6241&rec_status=15&presentation=table [4] mailto:mbj@tail-f.com --=_b51a45fecf8af5e171981c582bcd25a0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of confirmed co= mmits"
is correct.  There is just 1 netconf-confirmed-commit notificatio= n for start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored.  It is incorrect to think= of this procedure as a series of
confirmed commits.  A commit that extends t= he procedure is not treated
the same as the commit that starts the procedure= =2E
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
Jonathan
Andy


On Tue, Dec 10, 2013 at 6:36 AM, Martin Bjorklun= d <mbj@tail-f.com>= wrote:
[fixing andy's address]

"Bert Wijnen (IETF)" <bertiet= f@bwijnen.net> wrote:
> Martin, did you mean to make this s= tatement for all 3 reported errata,
> or just for 3821?

All three.

Editorial errata is fine with me.


/martin


>
> If anyone disagrees with Martin= 's assessment, pls speak up NOW.
>
> Thanks,
> B= ert
>
> On 12/10/13 1:28 PM, Martin Bjorklund wrote:
> > "Bert Wijnen (IETF)" <bertietf@bwijnen.net> wrote:
> >> We have a set of = 3 new errata reported to RFC6241.
> >> See:
> >&= gt; http://www.rfc-editor.org/errata_s= earch.php?rfc=3D6241&rec_status=3D15&presentation=3Dtable
= > >>
> >> We would like to hear from the authors/e= ditors what their
> >> opinion is on the reported errata. > >
> > I think the proposed text is fine, however I = do not know if it
> > qualifies as an errata.  IMO it clar= ifies the description of
> > confirmed-commit, but the current = text is not wrong.
> >
> >
> > /martin<= br /> > >
> >
>
--=_b51a45fecf8af5e171981c582bcd25a0-- From mehmet.ersue@nsn.com Wed Dec 11 05:56:52 2013 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 986341AD9AE for ; Wed, 11 Dec 2013 05:56:52 -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 89GI2vDBMn9g for ; Wed, 11 Dec 2013 05:56:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D46F41ADDD3 for ; Wed, 11 Dec 2013 05:56:49 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBBDufYC016793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Dec 2013 14:56:41 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBBDuftG019154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 14:56:41 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Dec 2013 14:56:40 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.217]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Wed, 11 Dec 2013 14:56:40 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Draft charter after consensus call Thread-Index: AQHO9njRcsoTthT74EWvwxfLqjMn6w== Date: Wed, 11 Dec 2013 13:56:40 +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.113] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8227417DEMUMBX005nsnintr_" 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: 8992 X-purgate-ID: 151667::1386770201-00001A6F-1F681BA8/0-0/0-0 Subject: [Netconf] Draft charter after consensus call 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, 11 Dec 2013 13:56:52 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8227417DEMUMBX005nsnintr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBORVRDT05GIFdHLA0KDQp3ZSBoYWQgdHdvIGNvbnNlbnN1cyBjYWxscyBlbmRlZCBvbiBE ZWNlbWJlciA0LCAyMDEzLg0KDQriiJIgICAgICAgVmVyaWZpbmcgc2Vzc2lvbiBjb25zZW5zdXMg d2l0aCB0aGUgbWFpbGxpc3Qgb24gUkZDNTUzOWJpcyBuZXcgcG9ydCBhbmQgWUFORyBtb2R1bGUg c2VwYXJhdGlvbg0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNv bmYvY3VycmVudC9tc2cwODQ0NS5odG1sDQriiJIgICAgICAgVmVyaWZpbmcgc2Vzc2lvbiBjb25z ZW5zdXMgb24gUkVTVENPTkYgYXMgV0cgaXRlbSB3aXRoIHRoZSBtYWlsbGlzdA0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwODQ0NC5odG1s DQoNClRoZSBjby1jaGFpcnMgdGhpbmsgdGhhdCB0aGVyZSB3YXMgc3VwcG9ydCBmb3IgdGhlIGFj dGlvbiBwb2ludHMgYW5kIG5vIG9iamVjdGlvbnMgdG8gdGhlIGNvbnNlbnN1cyBmcm9tIHRoZSBW YW5jb3V2ZXIgTkVUQ09ORiBzZXNzaW9uLg0KV2UgdGhpbmsgd2UgY2FuIGdvIG9uZSBzdGVwIGZ1 cnRoZXIuIFRoZSBjby1jaGFpcnMgYWdyZWVkIHRvIGhhdmUgUmV2ZXJzZSBTU0ggYXMgYSBzZXBh cmF0ZSBkb2N1bWVudCBmb3IgdGhlIHRpbWUgYmVpbmcuDQoNCkJlbG93IGlzIHRoZSByZWxldmFu dCBwYXJ0IG9mIHRoZSBkcmFmdCBjaGFydGVyLiBQbGVhc2UgY29tbWVudCBieSBEZWNlbWJlciAy MCwgMjAxMyBFT0IgUFQuDQpXZSB3aWxsIHRoZW4gcGFzcyBpdCBvbiB0byBvdXIgQUQgZm9yIGFw cHJvdmFsIGJ5IElFU0cuDQoNCkJlcnQgJiBNZWhtZXQNCg0KLS0tLS0tLS0tLS0tLS0tDQoNCiAg SW4gdGhlIGN1cnJlbnQgcGhhc2Ugb2YgTkVUQ09ORidzIGluY3JlbWVudGFsIGRldmVsb3BtZW50 IHRoZSB3b3JrZ3JvdXANCiAgd2lsbCBmb2N1cyBvbiBmb2xsb3dpbmcgaXRlbXM6DQoNCiAgMS4g RGV2ZWxvcCB0aGUgY2FsbCBob21lIG1lY2hhbmlzbSBmb3IgdGhlIG1hbmRhdG9yeSBTU0ggYmlu ZGluZyAoUmV2ZXJzZQ0KICBTU0gpIHByb3ZpZGluZyBhIHNlcnZlci1pbml0aWF0ZWQgc2Vzc2lv biBlc3RhYmxpc2htZW50Lg0KDQogIDIuIEFkdmFuY2UgTkVUQ09ORiBvdmVyIFRMUyB0byBiZSBp bi1saW5lIHdpdGggTkVUQ09ORiAxLjEgKGkuZS4sIHVwZGF0ZQ0KICBSRkMgNTUzOSkgYW5kIGFk ZCB0aGUgY2FsbCBob21lIG1lY2hhbmlzbSB0byBwcm92aWRlIGEgc2VydmVyLWluaXRpYXRlZA0K ICBzZXNzaW9uIGVzdGFibGlzaG1lbnQuDQoNCiAgMy4gQ29tYmluZSB0aGUgc2VydmVyIGNvbmZp Z3VyYXRpb24gZGF0YSBtb2RlbHMgZnJvbSBSZXZlcnNlIFNTSCBhbmQNCiAgUkZDNTUzOWJpcyBk cmFmdHMgaW4gYSBzZXBhcmF0ZSBZQU5HIG1vZHVsZS4NCg0KICA0LiBEZXZlbG9wIGEgUkVTVGZ1 bCBwcm90b2NvbCAoUkVTVENPTkYpIHRoYXQgcHJvdmlkZXMgYSBwcm9ncmFtbWF0aWMNCiAgaW50 ZXJmYWNlIGZvciBhY2Nlc3NpbmcgZGF0YSBkZWZpbmVkIGluIFlBTkcsIHVzaW5nIHRoZSBkYXRh c3RvcmVzDQogIGRlZmluZWQgaW4gTkVUQ09ORi4gVGhlIHR3byBwYXJ0cyBjb25jZXJuaW5nIFJF U1RDT05GIHByb3RvY29sIG92ZXINCiAgSFRUUCBhbmQgdGhlIFlBTkcgcGF0Y2ggb3BlcmF0aW9u IHdpbGwgYmUgcHJlcGFyZWQgaW4gc2VwYXJhdGUgZHJhZnRzLg0KDQoNCkdvYWxzIGFuZCBNaWxl c3RvbmVzOg0KICBKYW4gMjAxNCAtIFN1Ym1pdCBpbml0aWFsIFdHIGRyYWZ0cyBmb3IgUkVTVENP TkYgYXMgV0cgaXRlbQ0KICBBcHIgMjAxNCAtIFdHTEMgZm9yIFJGQzU1MzliaXMNCiAgQXByIDIw MTQgLSBXR0xDIGZvciBSZXZlcnNlIFNTSA0KICBBcHIgMjAxNCAtIFdHTEMgZm9yIE5FVENPTkYg c2VydmVyIGNvbmZpZ3VyYXRpb24gZGF0YSBtb2RlbA0KICBNYXkgMjAxNCAtIFN1Ym1pdCBSZXZl cnNlIFNTSCB0byBBRC9JRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJk DQogIE1heSAyMDE0IC0gU3VibWl0IFJGQzU1MzliaXMgdG8gQUQvSUVTRyBmb3IgY29uc2lkZXJh dGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KICBKdW4gMjAxNCAtIFdHTEMgZm9yIFJFU1RDT05G DQogIEF1ZyAyMDE0IC0gU3VibWl0IFJFU1RDT05GIHRvIEFEL0lFU0cgZm9yIGNvbnNpZGVyYXRp b24gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCg0KDQoNCg== --_000_E4DE949E6CE3E34993A2FF8AE79131F8227417DEMUMBX005nsnintr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJWZXJkYW5hIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxkaXY+RGVhciBORVRDT05GIFdHLDwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+d2UgaGFkIHR3byBjb25zZW5zdXMgY2FsbHMgZW5kZWQgb24gRGVj ZW1iZXIgNCwgMjAxMy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdp bjowO3BhZGRpbmctbGVmdDoxOHB0OyI+DQo8bGk+VmVyaWZpbmcgc2Vzc2lvbiBjb25zZW5zdXMg d2l0aCB0aGUgbWFpbGxpc3Qgb24gUkZDNTUzOWJpcyBuZXcgcG9ydCBhbmQgWUFORyBtb2R1bGUg c2VwYXJhdGlvbjxicj4NCg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cwODQ0NS5odG1sIj48Zm9udCBjb2xvcj0iYmx1ZSI+ PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9t c2cwODQ0NS5odG1sPC91PjwvZm9udD48L2E+IDwvbGk+PGxpPlZlcmlmaW5nIHNlc3Npb24gY29u c2Vuc3VzIG9uIFJFU1RDT05GIGFzIFdHIGl0ZW0gd2l0aCB0aGUgbWFpbGxpc3Q8YnI+DQoNCjxh IGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJl bnQvbXNnMDg0NDQuaHRtbCI+PGZvbnQgY29sb3I9ImJsdWUiPjx1Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDg0NDQuaHRtbDwvdT48L2Zv bnQ+PC9hPiZuYnNwOyA8L2xpPjwvdWw+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2PlRoZSBjby1jaGFpcnMgdGhpbmsgdGhhdCB0aGVyZSB3YXMgc3VwcG9ydCBmb3Ig dGhlIGFjdGlvbiBwb2ludHMgYW5kIG5vIG9iamVjdGlvbnMgdG8gdGhlIGNvbnNlbnN1cyBmcm9t IHRoZSBWYW5jb3V2ZXIgTkVUQ09ORiBzZXNzaW9uLjwvZGl2Pg0KPGRpdj5XZSB0aGluayB3ZSBj YW4gZ28gb25lIHN0ZXAgZnVydGhlci48Zm9udCBjb2xvcj0iYmx1ZSI+IDwvZm9udD5UaGUgY28t Y2hhaXJzIGFncmVlZCB0byBoYXZlIFJldmVyc2UgU1NIIGFzIGEgc2VwYXJhdGUgZG9jdW1lbnQg Zm9yIHRoZSB0aW1lIGJlaW5nLjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj5CZWxvdyBpcyB0aGUgcmVsZXZhbnQgcGFydCBvZiB0aGUgZHJhZnQgY2hhcnRl ci4gUGxlYXNlIGNvbW1lbnQgYnkgRGVjZW1iZXIgMjAsIDIwMTMgRU9CIFBULjxmb250IGNvbG9y PSJibHVlIj4gPC9mb250PjwvZGl2Pg0KPGRpdj5XZSB3aWxsIHRoZW4gcGFzcyBpdCBvbiB0byBv dXIgQUQgZm9yIGFwcHJvdmFsIGJ5IElFU0cuPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2PkJlcnQgJmFtcDsgTWVobWV0PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0mbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDsgSW4gdGhlIGN1cnJlbnQgcGhhc2Ugb2YgTkVUQ09ORidzIGluY3JlbWVu dGFsIGRldmVsb3BtZW50IHRoZSB3b3JrZ3JvdXA8L2Rpdj4NCjxkaXY+Jm5ic3A7IHdpbGwgZm9j dXMgb24gZm9sbG93aW5nIGl0ZW1zOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5i c3A7IDEuIERldmVsb3AgdGhlIGNhbGwgaG9tZSBtZWNoYW5pc20gZm9yIHRoZSBtYW5kYXRvcnkg U1NIIGJpbmRpbmcgKFJldmVyc2UgPC9kaXY+DQo8ZGl2PiZuYnNwOyBTU0gpIHByb3ZpZGluZyBh IHNlcnZlci1pbml0aWF0ZWQgc2Vzc2lvbiBlc3RhYmxpc2htZW50LjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+Jm5ic3A7IDIuIEFkdmFuY2UgTkVUQ09ORiBvdmVyIFRMUyB0byBiZSBp bi1saW5lIHdpdGggTkVUQ09ORiAxLjEgKGkuZS4sIHVwZGF0ZTwvZGl2Pg0KPGRpdj4mbmJzcDsg UkZDIDU1MzkpIGFuZCBhZGQgdGhlIGNhbGwgaG9tZSBtZWNoYW5pc20gdG8gcHJvdmlkZSBhIHNl cnZlci1pbml0aWF0ZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7IHNlc3Npb24gZXN0YWJsaXNobWVudC48 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyAzLiBDb21iaW5lIHRoZSBzZXJ2 ZXIgY29uZmlndXJhdGlvbiBkYXRhIG1vZGVscyBmcm9tIFJldmVyc2UgU1NIIGFuZCA8L2Rpdj4N CjxkaXY+Jm5ic3A7IFJGQzU1MzliaXMgZHJhZnRzIGluIGEgc2VwYXJhdGUgWUFORyBtb2R1bGUu PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsgNC4gRGV2ZWxvcCBhIFJFU1Rm dWwgcHJvdG9jb2wgKFJFU1RDT05GKSB0aGF0IHByb3ZpZGVzIGEgcHJvZ3JhbW1hdGljIDwvZGl2 Pg0KPGRpdj4mbmJzcDsgaW50ZXJmYWNlIGZvciBhY2Nlc3NpbmcgZGF0YSBkZWZpbmVkIGluIFlB TkcsIHVzaW5nIHRoZSBkYXRhc3RvcmVzIDwvZGl2Pg0KPGRpdj4mbmJzcDsgZGVmaW5lZCBpbiBO RVRDT05GLiBUaGUgdHdvIHBhcnRzIGNvbmNlcm5pbmcgUkVTVENPTkYgcHJvdG9jb2wgb3ZlciA8 L2Rpdj4NCjxkaXY+Jm5ic3A7IEhUVFAgYW5kIHRoZSBZQU5HIHBhdGNoIG9wZXJhdGlvbiB3aWxs IGJlIHByZXBhcmVkIGluIHNlcGFyYXRlIGRyYWZ0cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Hb2FscyBhbmQgTWlsZXN0b25lczo8L2Rpdj4NCjxk aXY+Jm5ic3A7IEphbiAyMDE0IC0gU3VibWl0IGluaXRpYWwgV0cgZHJhZnRzIGZvciBSRVNUQ09O RiBhcyBXRyBpdGVtIDwvZGl2Pg0KPGRpdj4mbmJzcDsgQXByIDIwMTQgLSBXR0xDIGZvciBSRkM1 NTM5YmlzPC9kaXY+DQo8ZGl2PiZuYnNwOyBBcHIgMjAxNCAtIFdHTEMgZm9yIFJldmVyc2UgU1NI PC9kaXY+DQo8ZGl2PiZuYnNwOyBBcHIgMjAxNCAtIFdHTEMgZm9yIE5FVENPTkYgc2VydmVyIGNv bmZpZ3VyYXRpb24gZGF0YSBtb2RlbCA8L2Rpdj4NCjxkaXY+Jm5ic3A7IE1heSAyMDE0IC0gU3Vi bWl0IFJldmVyc2UgU1NIIHRvIEFEL0lFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgUHJvcG9zZWQg U3RhbmRhcmQ8L2Rpdj4NCjxkaXY+Jm5ic3A7IE1heSAyMDE0IC0gU3VibWl0IFJGQzU1MzliaXMg dG8gQUQvSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZDwvZGl2Pg0K PGRpdj4mbmJzcDsgSnVuIDIwMTQgLSBXR0xDIGZvciBSRVNUQ09ORjwvZGl2Pg0KPGRpdj4mbmJz cDsgQXVnIDIwMTQgLSBTdWJtaXQgUkVTVENPTkYgdG8gQUQvSUVTRyBmb3IgY29uc2lkZXJhdGlv biBhcyBQcm9wb3NlZCBTdGFuZGFyZDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4mbmJz cDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_E4DE949E6CE3E34993A2FF8AE79131F8227417DEMUMBX005nsnintr_-- From jonathan@hansfords.net Thu Dec 12 04:26:48 2013 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 CF8661ACC88 for ; Thu, 12 Dec 2013 04:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ey37aSugaSPv for ; Thu, 12 Dec 2013 04:26:45 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 722B51AC85E for ; Thu, 12 Dec 2013 04:26:44 -0800 (PST) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id 0cSb1n004283uBY01cScln; Thu, 12 Dec 2013 12:26:37 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=C6LQl2/+ c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=dYCPD3cKDi0A:10 a=OZAIM3IXDPUA:10 a=0B8HqoTn75oA:10 a=lxldWUwtbAkA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=U1ZSPVn_UXUA:10 a=EVJldYyK298S8oRfLc4A:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=vpWXxfwkl_5LFXiwmZkA:9 a=7CNTHFcVIAk7eBje:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 12 Dec 2013 12:26:35 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_84704754319ccb67f2e2e5e7310f3a54" Date: Thu, 12 Dec 2013 12:26:35 +0000 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> Message-ID: <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: Rob Enns , joel jaeggli , Netconf 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: Thu, 12 Dec 2013 12:26:49 -0000 --=_84704754319ccb67f2e2e5e7310f3a54 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 On 2013-12-10 17:05, Andy Bierman wrote: > On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford wrote: > >> On 2013-12-10 16:15, Andy Bierman wrote: >> >>> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford wrote: >>> >>>> On 2013-12-10 15:59, Andy Bierman wrote: >>>> >>>>> Hi, >>>>> I don't think these 3 reports are corrections. >>>>> They are editorial changes to the text. >>>>> I don't agree that the new terminology added "sequence of confirmed commits" >>>>> is correct. There is just 1 netconf-confirmed-commit notification for start & complete >>>>> sent out no matter how how many times the procedure is extended. >>>>> >>>>> If the procedure ends with a cancel or timeout, there is only 1 original commit >>>>> that is restored. It is incorrect to think of this procedure as a series of >>>>> confirmed commits. A commit that extends the procedure is not treated >>>>> the same as the commit that starts the procedure. >>>> >>>> Are you saying that the initial commit of the sequence (the confirmed commit?) is restored should the procedure be cancelled or timeout? Surely the commit that is restored is the one that preceded the confirmed commit. >>> >>> The confirmed commit is the first that includes a parameter. >>> The 2nd - Nth are extending the first commit operation. The server is still >>> obligated to revert the running config for the first commit (if it is canceled or timed out). >>> This obligation is not removed because the commit is extended. It is only removed >>> if a confirming commit is received. >> >> Andy, >> I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd paragraph) talks about 'a follow-up confirmed operation'. Are you saying that that second 'confirmed ' (i.e. a with the parameter) is not a "confirmed commit"? And when you say 'the server is obligated to revert the running config for the first commit' do you mean revert to the state prior to that first confirmed ? > > sec. 8.4.1, para 2: > > The confirming commit is a operation > without the parameter. > > The 2nd commit with a parameter extends the confirmed-commit procedure. > Any cancel or complete applies to this commit. If canceled, then the changes made for the > 2nd commit are going to be undone. An extension commit is not a confirming commit. > A cancel/timeout causes the config to revert to its state before the first confirmed commit > operation. > >> Jonathan > > Andy Andy, What I think you seem to be stating here is that there are three types of commit (and possibly, by extension, four): * "Confirmed commit" - the first successful commit with a parameter after a successful commit without a parameter * "Extension commit" - any commit with a parameter after a "confirmed commit" and before any successful "confirming commit" * "Confirming commit" - any commit without a parameter after a "confirmed commit" and before any other successful "confirming commit" * "Standard commit" - any commit without a parameter after a successful "confirming commit" and before a subsequent "confirmed commit" By those definitions a "confirmed commit" cannot follow another "confirmed commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about follow-up "confirmed commits" and "confirming commits". How can there be a follow-up "confirmed commit", unless the definition of a "confirmed commit" becomes something like: (the first commit with a parameter after a successful commit without a parameter) OR (the first successful commit with a parameter from another session and the appropriate ) Also, 8.4.5.1 states the parameter makes the "confirmed commit" survive a session termination. Does that mean the parameter can only be successful if the original session has been terminated, or is it more accurate to state that the parameter allows the "confirmed commit" to be extended by other sessions, whether or not the original session has been terminated? Thanks, Jonathan Links: ------ [1] mailto:Jonathan@hansfords.net [2] mailto:Jonathan@hansfords.net --=_84704754319ccb67f2e2e5e7310f3a54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

 

On 2013-12-10 17:05, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansfo= rd <Jonathan@hansfords= =2Enet> wrote:

On 2013-12-10 16:15, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansfo= rd <Jonathan@hansfords= =2Enet> wrote:

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of confirmed co= mmits"
is correct.  There is just 1 netconf-confirmed-commit notificatio= n for start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored.  It is incorrect to think= of this procedure as a series of
confirmed commits.  A commit that extends t= he procedure is not treated
the same as the commit that starts the procedure= =2E
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
The confirmed commit is the first <commit> that includes a <c= onfirmed> parameter.
The 2nd - Nth <commit> are extending the first commit operation= =2E  The server is still
obligated to revert the running config for the first commit (if it is = canceled or timed out).
This obligation is not removed because the commit is extended.  I= t is only removed
if a confirming commit is received.
Andy,
I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd= paragraph) talks about 'a follow-up confirmed <commit> operation'. A= re you saying that that second 'confirmed <commit>' (i.e. a <commi= t> with the <confirmed> parameter) is not a "confirmed commit"? An= d when you say 'the server is obligated to revert the running config for th= e first commit' do you mean revert to the state prior to that first confirm= ed <commit>?
sec. 8.4.1, para 2:




Jonathan
Andy
Andy,
What I think you seem to be stating here is that there are three types= of commit (and possibly, by extension, four):
  1. "Confirmed commit" - the first successful commit with a <confirmed&g= t; parameter after a successful commit without a <confirmed> paramete= r
  2. "Extension commit" - any commit with a <confirmed> parameter afte= r a "confirmed commit" and before any successful "confirming commit"
  3. "Confirming commit" - any commit without a <confirmed> parameter = after a "confirmed commit" and before any other successful "confirming comm= it"
  4. "Standard commit" - any commit without a <confirmed> parameter af= ter a successful "confirming commit" and before a subsequent "confirmed com= mit"

By those definitions a "confirmed commit" cannot follow another "confirm= ed commit" without an intervening "confirming commit". Yet 8.4.5.1 talks ab= out follow-up "confirmed commits" and "confirming commits". How can there b= e a follow-up "confirmed commit", unless the definition of a "confirmed com= mit" becomes something like:

(the first commit with a <confirmed> parameter after a successful = commit without a <confirmed> parameter) OR (the first successful comm= it with a <confirmed> parameter from another session and the appropri= ate <persist-id>)

Also, 8.4.5.1 states the <persist> parameter makes the "confirmed = commit" survive a session termination. Does that mean the <persist-id>= ; parameter can only be successful if the original session has been termina= ted, or is it more accurate to state that the <persist> parameter all= ows the "confirmed commit" to be extended by other sessions, whether or not= the original session has been terminated?

Thanks,

Jonathan

--=_84704754319ccb67f2e2e5e7310f3a54-- From andy@yumaworks.com Thu Dec 12 08:57:52 2013 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 1CF7D1ADF67 for ; Thu, 12 Dec 2013 08:57:52 -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 L5JIH2gSmwLN for ; Thu, 12 Dec 2013 08:57:49 -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 EF1651AD2EC for ; Thu, 12 Dec 2013 08:57:48 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id ii20so1856603qab.15 for ; Thu, 12 Dec 2013 08:57:42 -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=XanpNtx2tcTMbfk8eQBMX+6eZFV47OfJjrb3mimxGY0=; b=H5JEY4JHWstx9atj8VAKu/4X/e2Dgky7polvuBdKcjENCWBTbXXqhSY8vGQdtHonqq DHm0x6NPs6ALN78EIeViDoBYPbMoMC8bWDXsGrgM3j2NtvVXQETi3ZCEgh/x9WbxY4td 5scY1sDNHo5KdA4Q69xRGsqSFub4U/2KwHVXsxXbGX7Vw0bwTwO3UX36+i6bKNYd/c4l Ddq4g6IM2y1t9BzGMnlmDp8dcEtdXdbx6OkJAkBlX0dJ+tC7zqroxt/HkWOlffaZJJ98 L83XbA6fSVKUtI0zbGilPZh0VOP0BYomB3U8xTj50AaxAe11uwBwo7z1gpk4BqZGcs7h 53cQ== X-Gm-Message-State: ALoCoQmbzR1fSjsLW8mbfslH7h92JJx4S6tNqI0y+/PPt5voA7ee4sXDiyxSWTjCdRummbwX1NcI MIME-Version: 1.0 X-Received: by 10.224.51.74 with SMTP id c10mr14574215qag.7.1386867435232; Thu, 12 Dec 2013 08:57:15 -0800 (PST) Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 08:57:15 -0800 (PST) In-Reply-To: <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> Date: Thu, 12 Dec 2013 08:57:15 -0800 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: multipart/alternative; boundary=089e0158cb54d40bcb04ed593c0c Cc: Rob Enns , joel jaeggli , Netconf 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: Thu, 12 Dec 2013 16:57:52 -0000 --089e0158cb54d40bcb04ed593c0c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford wrote: > > > On 2013-12-10 17:05, Andy Bierman wrote: > > > > > On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford > wrote: > >> On 2013-12-10 16:15, Andy Bierman wrote: >> >> >> >> >> On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford < >> Jonathan@hansfords.net> wrote: >> >>> On 2013-12-10 15:59, Andy Bierman wrote: >>> >>> Hi, >>> I don't think these 3 reports are corrections. >>> They are editorial changes to the text. >>> I don't agree that the new terminology added "sequence of confirmed >>> commits" >>> is correct. There is just 1 netconf-confirmed-commit notification for >>> start & complete >>> sent out no matter how how many times the procedure is extended. >>> If the procedure ends with a cancel or timeout, there is only 1 >>> original commit >>> that is restored. It is incorrect to think of this procedure as a >>> series of >>> confirmed commits. A commit that extends the procedure is not treated >>> the same as the commit that starts the procedure. >>> >>> Are you saying that the initial commit of the sequence (the confirmed >>> commit?) is restored should the procedure be cancelled or timeout? Surely >>> the commit that is restored is the one that preceded the confirmed commit. >>> >> The confirmed commit is the first that includes a >> parameter. >> The 2nd - Nth are extending the first commit operation. The >> server is still >> obligated to revert the running config for the first commit (if it is >> canceled or timed out). >> This obligation is not removed because the commit is extended. It is >> only removed >> if a confirming commit is received. >> >> Andy, >> I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd >> paragraph) talks about 'a follow-up confirmed operation'. Are you >> saying that that second 'confirmed ' (i.e. a with the >> parameter) is not a "confirmed commit"? And when you say 'the >> server is obligated to revert the running config for the first commit' do >> you mean revert to the state prior to that first confirmed ? >> > sec. 8.4.1, para 2: > > The confirming commit is a operation > without the parameter. > > The 2nd commit with a parameter extends the confirmed-commit > procedure. > Any cancel or complete applies to this commit. If canceled, then the > changes made for the > 2nd commit are going to be undone. An extension commit is not a > confirming commit. > A cancel/timeout causes the config to revert to its state before the first > confirmed commit > operation. > >> Jonathan >> > Andy > > Andy, > What I think you seem to be stating here is that there are three types of > commit (and possibly, by extension, four): > > 1. "Confirmed commit" - the first successful commit with a > parameter after a successful commit without a parameter > 2. "Extension commit" - any commit with a parameter after > a "confirmed commit" and before any successful "confirming commit" > 3. "Confirming commit" - any commit without a parameter > after a "confirmed commit" and before any other successful "confirming > commit" > 4. "Standard commit" - any commit without a parameter > after a successful "confirming commit" and before a subsequent "confirmed > commit" > > By those definitions a "confirmed commit" cannot follow another "confirmed > commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about > follow-up "confirmed commits" and "confirming commits". How can there be a > follow-up "confirmed commit", unless the definition of a "confirmed commit" > becomes something like: > > (the first commit with a parameter after a successful commit > without a parameter) OR (the first successful commit with a > parameter from another session and the appropriate ) > The saved state that that gets reverted if the commit is not confirmed does not change because anther commit with a element is received. This 2nd commit that is extending the confirmed commit procedure is clearly not a confirming commit, so the server cannot update the saved state that will be reverted if necessary. The terminology does not distinguish very well between the confirmed commit procedure and a request that is called a confirmed commit. There is only 1 confirmed commit procedure active at any given time. The 2nd confirmed commit request does not end the first procedure and start a new one. Once the procedure is ended somehow, then it ends for all the confirmed commit requests that are pending. Also, 8.4.5.1 states the parameter makes the "confirmed commit" > survive a session termination. Does that mean the parameter > can only be successful if the original session has been terminated, or is > it more accurate to state that the parameter allows the > "confirmed commit" to be extended by other sessions, whether or not the > original session has been terminated? > No -- any session that knows the correct persist-id can complete the procedure, including any session that sent a confirmed commit request. > Thanks, > > Jonathan > Andy --089e0158cb54d40bcb04ed593c0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford <Jonathan@= hansfords.net> wrote:

=A0

On 2013-12-10 17:05, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansfo= rd <Jo= nathan@hansfords.net> wrote:

On 2013-12-10 16:15, Andy Bierman wrote:




On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansfo= rd <Jo= nathan@hansfords.net> wrote:

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,
I don't think these 3 reports are corrections.
They are editorial changes to the text.
I don't agree that the new terminology added "sequence of con= firmed commits"
is correct. =A0There is just 1 netconf-confirmed-commit notification f= or start & complete
sent out no matter how how many times the procedure is extended.
If the procedure ends with a cancel or timeout, = there is only 1 original commit
that is restored. =A0It is incorrect to think of= this procedure as a series of
confirmed commits. =A0A commit that extends the = procedure is not treated
the same as the commit that starts the procedure= .
Are you saying that the initial commit of the se= quence (the confirmed commit?) is restored should the procedure be cancelle= d or timeout? Surely the commit that is restored is the one that preceded t= he confirmed commit.
The confirmed commit is the first <commit> that includes a <c= onfirmed> parameter.
The 2nd - Nth <commit> are extending the first commit operation.= =A0The server is still
obligated to revert the running config for the first commit (if it is = canceled or timed out).
This obligation is not removed because the commit is extended. =A0It i= s only removed
if a confirming commit is received.
Andy,
I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 = (2nd paragraph) talks about 'a follow-up confirmed <commit> opera= tion'. Are you saying that that second 'confirmed <commit>= 9; (i.e. a <commit> with the <confirmed> parameter) is not a &q= uot;confirmed commit"? And when you say 'the server is obligated t= o revert the running config for the first commit' do you mean revert to= the state prior to that first confirmed <commit>?
sec. 8.4.1, para 2:
   The confirming =
commit is a <commit> operation
   without the <confirmed> parameter.
The 2nd commit with a <confirmed> parameter extends the confirme= d-commit procedure.
Any cancel or complete applies to this commit. =A0If canceled, then th= e changes made for the
2nd commit are going to be undone. =A0An extension commit is not a con= firming commit.
A cancel/timeout causes the config to revert to its state before the f= irst confirmed commit
operation.
Jonathan
Andy
Andy,
What I think you seem to be stating here is that there are three types= of commit (and possibly, by extension, four):
  1. "Confirmed commit" - the first successful commit with a <c= onfirmed> parameter after a successful commit without a <confirmed>= ; parameter
  2. "Extension commit" - any commit with a <confirmed> para= meter after a "confirmed commit" and before any successful "= confirming commit"
  3. "Confirming commit" - any commit without a <confirmed> = parameter after a "confirmed commit" and before any other success= ful "confirming commit"
  4. "Standard commit" - any commit without a <confirmed> pa= rameter after a successful "confirming commit" and before a subse= quent "confirmed commit"

By those definitions a "confirmed commit" cannot follow anothe= r "confirmed commit" without an intervening "confirming comm= it". Yet 8.4.5.1 talks about follow-up "confirmed commits" a= nd "confirming commits". How can there be a follow-up "confi= rmed commit", unless the definition of a "confirmed commit" = becomes something like:

(the first commit with a <confirmed> parameter after a successful = commit without a <confirmed> parameter) OR (the first successful comm= it with a <confirmed> parameter from another session and the appropri= ate <persist-id>)




The saved state that that gets reverted if the commit is = not confirmed does not change
because anther commit with a <co= nfirmed> element is received. =A0This 2nd commit that
is extending the confirmed commit procedure is clearly not a confirmin= g commit, so
the server cannot update the saved state that will b= e reverted if necessary.

The terminology does not = distinguish very well between the confirmed commit procedure
and a <rpc> request that is called a confirmed commit. =A0There = is only 1 confirmed commit
procedure active at any given time. = =A0The 2nd confirmed commit <rpc> request does not end
the = first procedure and start a new one. =A0Once the procedure is ended somehow= ,
then it ends for all the confirmed commit requests that are pending.


Also, 8.4.5.1 states the <persist> parameter makes the "confi= rmed commit" survive a session termination. Does that mean the <per= sist-id> parameter can only be successful if the original session has be= en terminated, or is it more accurate to state that the <persist> par= ameter allows the "confirmed commit" to be extended by other sess= ions, whether or not the original session has been terminated?


No -- any se= ssion that knows the correct persist-id can complete the procedure,
including any session that sent a confirmed commit <rpc> request.<= /div>

=A0

Thanks,

Jonathan


Andy

--089e0158cb54d40bcb04ed593c0c-- From ietfdbh@comcast.net Thu Dec 12 09:20:55 2013 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 6C7A71AE375 for ; Thu, 12 Dec 2013 09:20:55 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 xdnXSwda5OMj for ; Thu, 12 Dec 2013 09:20:51 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3197C1AE36A for ; Thu, 12 Dec 2013 09:20:51 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 0gcf1n0021YDfWL58hLlku; Thu, 12 Dec 2013 17:20:45 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta20.westchester.pa.mail.comcast.net with comcast id 0hLk1n0082yZEBF3ghLkuZ; Thu, 12 Dec 2013 17:20:45 +0000 From: "ietfdbh" To: "'Andy Bierman'" , "'Jonathan Hansford'" References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> In-Reply-To: Date: Thu, 12 Dec 2013 12:20:40 -0500 Message-ID: <004e01cef75e$7bb29250$7317b6f0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004F_01CEF734.92DF2260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFxRN3ibRGuFkOXIPpnNb6vzrZ6MwIxKmMoAhpYLgUB5zDFsADOA3C8AbaCCN8AyzainQHGVfMPAoQ8528B6MKFzAJROrpsmnv4Z4A= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386868845; bh=ZDiKKyLtf/00xqLjBDGGplsK23BL2A2YszwpJI06vUA=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Waqf+mR2sqKhzyd2zA7EA3yTIlRj4tCCqDkyPmH7cQInLf5cjGRG2J/pfl7BCGdeQ bEl/5kiedChljBVz+q+6fT1u3+w4yRX4NWqt8bGi10ZvhSPFMB1tvFKU7tf30FPxoW /n/6zQvL/5TcjDtXhjbswhTxhCqUGFZ3fYLsToHr1t+JWDbIS/k1ZOVI6MOgQLBDGP lnJNBQ+XEOvJ4xKpgJ7xpOfMAILJge3hOouUxZTh+ET4lLTTGNua/cpdr7VcM171q3 Njpd4dS98h+T3l5Nb0WWLZtCyRWyRWjEEzBgdF8vfw4IxIY3p7/d6BV3t+6VdKHu87 2gNeHqQbH5yBg== Cc: 'Rob Enns' , 'joel jaeggli' , 'Netconf' 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: Thu, 12 Dec 2013 17:20:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004F_01CEF734.92DF2260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This thread about an errata says to me that implementers could implement the original text in different ways and be conformant to the standard. The clarification text seems to be modifying what a conformant implementation must do, and obviously the WG members haven't reached consensus on just what that must be. If the clarification becomes part of conformance requirements, then existing implementations would likely become non-conformant. To me, that says a -bis is called for, including WGLC and IETF LCs, to change the conformance requirements of the standard. I am not implementing this standard, so maybe I misjudge whether this affects existing implementations or not. Please let me know if I am looking at this incorrectly. David Harrington ietfdbh@comcast.net +1-603-828-1401 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, December 12, 2013 11:57 AM To: Jonathan Hansford Cc: Rob Enns; joel jaeggli; Netconf Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford wrote: On 2013-12-10 17:05, Andy Bierman wrote: On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford wrote: On 2013-12-10 16:15, Andy Bierman wrote: On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford wrote: On 2013-12-10 15:59, Andy Bierman wrote: Hi, I don't think these 3 reports are corrections. They are editorial changes to the text. I don't agree that the new terminology added "sequence of confirmed commits" is correct. There is just 1 netconf-confirmed-commit notification for start & complete sent out no matter how how many times the procedure is extended. If the procedure ends with a cancel or timeout, there is only 1 original commit that is restored. It is incorrect to think of this procedure as a series of confirmed commits. A commit that extends the procedure is not treated the same as the commit that starts the procedure. Are you saying that the initial commit of the sequence (the confirmed commit?) is restored should the procedure be cancelled or timeout? Surely the commit that is restored is the one that preceded the confirmed commit. The confirmed commit is the first that includes a parameter. The 2nd - Nth are extending the first commit operation. The server is still obligated to revert the running config for the first commit (if it is canceled or timed out). This obligation is not removed because the commit is extended. It is only removed if a confirming commit is received. Andy, I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd paragraph) talks about 'a follow-up confirmed operation'. Are you saying that that second 'confirmed ' (i.e. a with the parameter) is not a "confirmed commit"? And when you say 'the server is obligated to revert the running config for the first commit' do you mean revert to the state prior to that first confirmed ? sec. 8.4.1, para 2: The confirming commit is a operation without the parameter. The 2nd commit with a parameter extends the confirmed-commit procedure. Any cancel or complete applies to this commit. If canceled, then the changes made for the 2nd commit are going to be undone. An extension commit is not a confirming commit. A cancel/timeout causes the config to revert to its state before the first confirmed commit operation. Jonathan Andy Andy, What I think you seem to be stating here is that there are three types of commit (and possibly, by extension, four): 1. "Confirmed commit" - the first successful commit with a parameter after a successful commit without a parameter 2. "Extension commit" - any commit with a parameter after a "confirmed commit" and before any successful "confirming commit" 3. "Confirming commit" - any commit without a parameter after a "confirmed commit" and before any other successful "confirming commit" 4. "Standard commit" - any commit without a parameter after a successful "confirming commit" and before a subsequent "confirmed commit" By those definitions a "confirmed commit" cannot follow another "confirmed commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about follow-up "confirmed commits" and "confirming commits". How can there be a follow-up "confirmed commit", unless the definition of a "confirmed commit" becomes something like: (the first commit with a parameter after a successful commit without a parameter) OR (the first successful commit with a parameter from another session and the appropriate ) The saved state that that gets reverted if the commit is not confirmed does not change because anther commit with a element is received. This 2nd commit that is extending the confirmed commit procedure is clearly not a confirming commit, so the server cannot update the saved state that will be reverted if necessary. The terminology does not distinguish very well between the confirmed commit procedure and a request that is called a confirmed commit. There is only 1 confirmed commit procedure active at any given time. The 2nd confirmed commit request does not end the first procedure and start a new one. Once the procedure is ended somehow, then it ends for all the confirmed commit requests that are pending. Also, 8.4.5.1 states the parameter makes the "confirmed commit" survive a session termination. Does that mean the parameter can only be successful if the original session has been terminated, or is it more accurate to state that the parameter allows the "confirmed commit" to be extended by other sessions, whether or not the original session has been terminated? No -- any session that knows the correct persist-id can complete the procedure, including any session that sent a confirmed commit request. Thanks, Jonathan Andy ------=_NextPart_000_004F_01CEF734.92DF2260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

This thread about an errata says to me that implementers could = implement the original text in different ways and be conformant to the = standard.

 

The clarification text seems to be modifying what a conformant = implementation must do, and obviously the WG members haven’t = reached consensus on just what that must be.

 

If the clarification becomes part of conformance requirements, then = existing implementations would likely become non-conformant. =

To me, that says a –bis is called for, including WGLC and IETF = LCs, to change the conformance requirements of the = standard.

 

I am not implementing this standard, so maybe I misjudge whether this = affects existing implementations or not. Please let me know if I am = looking at this incorrectly.

 

David Harrington

ietfdbh@comca= st.net

+1-603-828-1401

From:= = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Thursday, December 12, 2013 11:57 = AM
To: Jonathan Hansford
Cc: Rob Enns; joel jaeggli; = Netconf
Subject: Re: [Netconf] [Technical Errata Reported] = RFC6241 (3821)

 

 

 

On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford = <Jonathan@hansfords.net> = wrote:

 

On 2013-12-10 = 17:05, Andy Bierman wrote:

 

 

On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford = <Jonathan@hansfords.net> = wrote:

On 2013-12-10 16:15, Andy Bierman = wrote:

 

 

On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford = <Jonathan@hansfords.net> = wrote:

On 2013-12-10 15:59, Andy Bierman = wrote:

Hi,

I don't = think these 3 reports are corrections.

They are editorial changes to the = text.

I don't agree that = the new terminology added "sequence of confirmed = commits"

is correct. =  There is just 1 netconf-confirmed-commit notification for start = & complete

sent out no = matter how how many times the procedure is = extended.

If the = procedure ends with a cancel or timeout, there is only 1 original = commit

that is restored. =  It is incorrect to think of this procedure as a series = of

confirmed commits. =  A commit that extends the procedure is not = treated

the same as the = commit that starts the = procedure.

Are you saying that the initial commit of the sequence = (the confirmed commit?) is restored should the procedure be cancelled or = timeout? Surely the commit that is restored is the one that preceded the = confirmed commit.

The confirmed commit is the first <commit> that = includes a <confirmed> parameter.

The 2nd - Nth <commit> are extending the first = commit operation.  The server is still

obligated to revert the running config for the first = commit (if it is canceled or timed out).

This obligation is not removed because the commit is = extended.  It is only removed

if a confirming commit is = received.

Andy,

I'm not sure whether we agreeing or not. Section 8.4.1 = of RFC6241 (2nd paragraph) talks about 'a follow-up confirmed = <commit> operation'. Are you saying that that second 'confirmed = <commit>' (i.e. a <commit> with the <confirmed> = parameter) is not a "confirmed commit"? And when you say 'the = server is obligated to revert the running config for the first commit' = do you mean revert to the state prior to that first confirmed = <commit>?

sec. 8.4.1, para 2:

   The =
confirming commit is a <commit> =
operation
   without the =
<confirmed> parameter.

The 2nd commit with a <confirmed> parameter = extends the confirmed-commit procedure.

Any cancel or complete applies to this commit. =  If canceled, then the changes made for = the

2nd commit are going = to be undone.  An extension commit is not a confirming = commit.

A cancel/timeout = causes the config to revert to its state before the first confirmed = commit

operation.

Jonathan

<= div>

Andy

Andy,

What I think you seem to be stating here is that there = are three types of commit (and possibly, by extension, = four):

  1. "Confirmed commit" - the first successful commit = with a <confirmed> parameter after a successful commit without a = <confirmed> parameter
  2. "Extension commit" - any commit with a = <confirmed> parameter after a "confirmed commit" and = before any successful "confirming commit"
  3. "Confirming commit" - any commit without a = <confirmed> parameter after a "confirmed commit" and = before any other successful "confirming = commit"
  4. "Standard commit" - any commit without a = <confirmed> parameter after a successful "confirming = commit" and before a subsequent "confirmed = commit"

By those definitions a = "confirmed commit" cannot follow another "confirmed = commit" without an intervening "confirming commit". Yet = 8.4.5.1 talks about follow-up "confirmed commits" and = "confirming commits". How can there be a follow-up = "confirmed commit", unless the definition of a "confirmed = commit" becomes something like:

(the first commit = with a <confirmed> parameter after a successful commit without a = <confirmed> parameter) OR (the first successful commit with a = <confirmed> parameter from another session and the appropriate = <persist-id>)

 

 

 

The saved state that that gets reverted if the commit = is not confirmed does not change

because anther commit with a <confirmed> element = is received.  This 2nd commit that

is extending the confirmed commit procedure is clearly = not a confirming commit, so

the server cannot update the saved state that will be = reverted if necessary.

 

The terminology does not distinguish very well between = the confirmed commit procedure

and a <rpc> request that is called a confirmed = commit.  There is only 1 confirmed = commit

procedure active at = any given time.  The 2nd confirmed commit <rpc> request does = not end

the first = procedure and start a new one.  Once the procedure is ended = somehow,

then it ends for = all the confirmed commit requests that are = pending.

 

 

Als= o, 8.4.5.1 states the <persist> parameter makes the = "confirmed commit" survive a session termination. Does that = mean the <persist-id> parameter can only be successful if the = original session has been terminated, or is it more accurate to state = that the <persist> parameter allows the "confirmed = commit" to be extended by other sessions, whether or not the = original session has been = terminated?

 

No -- any session that knows the correct persist-id = can complete the procedure,

including any session that sent a confirmed commit = <rpc> request.

 

 

Tha= nks,

Jonathan

 

Andy

 

------=_NextPart_000_004F_01CEF734.92DF2260-- From andy@yumaworks.com Thu Dec 12 09:42:58 2013 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 781281ADFD4 for ; Thu, 12 Dec 2013 09:42:58 -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 59Skr4Xq16u3 for ; Thu, 12 Dec 2013 09:42:54 -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 840C51AE02C for ; Thu, 12 Dec 2013 09:42:54 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id c9so573774qcz.16 for ; Thu, 12 Dec 2013 09:42:48 -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=MjMnHxSm/TGegPRHyfpTFFFaCKNqtbMdUFOFsJyTAiM=; b=DqekH2H7mOk6TgBtTQYNVgvoHWzOlOhiPEwq8jU3c1cdO2ZPjZ+kwdKNz28dhUcCA2 mimeUljRwFE96FI/kc2k4WaX/6J81f0ohwVbVi+iD4jqHonugKRuU6vrogrzzzKhuQPj TTiazy8Q3ZjW8osLcEvGmVoR0/VMyKq1sMSKWn91dST225il8o0GkNl7k3IFMVML8kbe 1gObwLxHkt37j/xRbGjaJDFn8469Wobty7M5zyGZ3w19cK+tWGmvCWEAzgDwWOMlPpfq QdnaILdjnf/jRv2W5bZR1f7/Ev0flHcHuTrFWrq5X+H6dnLLAyzMJ7MWYhbaj0e886Ls U8lg== X-Gm-Message-State: ALoCoQmADzo9nY4ACta19VfF9cWkJ6mac9zRWTChIgv79UnZNskW8Fl0ElOkwqMLCQQJoJusYCgi MIME-Version: 1.0 X-Received: by 10.224.39.15 with SMTP id d15mr8162541qae.36.1386870168245; Thu, 12 Dec 2013 09:42:48 -0800 (PST) Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 09:42:48 -0800 (PST) In-Reply-To: <004e01cef75e$7bb29250$7317b6f0$@comcast.net> References: <52A62972.4010001@bwijnen.net> <20131210.132819.2303764306420511964.mbj@tail-f.com> <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> <004e01cef75e$7bb29250$7317b6f0$@comcast.net> Date: Thu, 12 Dec 2013 09:42:48 -0800 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=001a1134a56aba8cb104ed59dfa0 Cc: Rob Enns , joel jaeggli , Netconf 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: Thu, 12 Dec 2013 17:42:58 -0000 --001a1134a56aba8cb104ed59dfa0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh wrote: > Hi, > > > > This thread about an errata says to me that implementers could implement > the original text in different ways and be conformant to the standard. > > > What are the implementation differences that the spec allows? > The clarification text seems to be modifying what a conformant > implementation must do, and obviously the WG members haven=92t reached > consensus on just what that must be. > > > I do not agree that there is WG consensus to accept the errata -- the discussion seems to show that the term "confirmed commit" is used to refer to the entire procedure and to a specific form of a request. There is no text that is clearly in error. I don't think consensus has been established that different implementations of confirmed commit are possible. The draft is clear about the definition of a confirming commit, and also clear what ends a confirmed commit procedure. If the clarification becomes part of conformance requirements, then > existing implementations would likely become non-conformant. > > To me, that says a =96bis is called for, including WGLC and IETF LCs, to > change the conformance requirements of the standard. > Can you describe this non-conformance that needs to be fixed with a new RFC= ? It seems to me (and other implementors) that restoring the running config t= o its state before the first confirmed commit request is the correct behavior. I do not agree that the current RFC text allows an interpretation that permits the server to treat a with a element as a confirming commit. Only a timeout, or confirming commit can release the server from its obligation to revert the saved state. > > > I am not implementing this standard, so maybe I misjudge whether this > affects existing implementations or not. Please let me know if I am looki= ng > at this incorrectly. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > Andy > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Thursday, December 12, 2013 11:57 AM > *To:* Jonathan Hansford > *Cc:* Rob Enns; joel jaeggli; Netconf > *Subject:* Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) > > > > > > > > On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford > wrote: > > > > On 2013-12-10 17:05, Andy Bierman wrote: > > > > > > On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford > wrote: > > On 2013-12-10 16:15, Andy Bierman wrote: > > > > > > On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford > wrote: > > On 2013-12-10 15:59, Andy Bierman wrote: > > Hi, > > I don't think these 3 reports are corrections. > > They are editorial changes to the text. > > I don't agree that the new terminology added "sequence of confirmed > commits" > > is correct. There is just 1 netconf-confirmed-commit notification for > start & complete > > sent out no matter how how many times the procedure is extended. > > If the procedure ends with a cancel or timeout, there is only 1 original > commit > > that is restored. It is incorrect to think of this procedure as a series > of > > confirmed commits. A commit that extends the procedure is not treated > > the same as the commit that starts the procedure. > > Are you saying that the initial commit of the sequence (the confirmed > commit?) is restored should the procedure be cancelled or timeout? Surely > the commit that is restored is the one that preceded the confirmed commit= . > > The confirmed commit is the first that includes a > parameter. > > The 2nd - Nth are extending the first commit operation. The > server is still > > obligated to revert the running config for the first commit (if it is > canceled or timed out). > > This obligation is not removed because the commit is extended. It is onl= y > removed > > if a confirming commit is received. > > Andy, > > I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd > paragraph) talks about 'a follow-up confirmed operation'. Are yo= u > saying that that second 'confirmed ' (i.e. a with the > parameter) is not a "confirmed commit"? And when you say 'the > server is obligated to revert the running config for the first commit' do > you mean revert to the state prior to that first confirmed ? > > sec. 8.4.1, para 2: > > The confirming commit is a operation > > without the parameter. > > The 2nd commit with a parameter extends the confirmed-commit > procedure. > > Any cancel or complete applies to this commit. If canceled, then the > changes made for the > > 2nd commit are going to be undone. An extension commit is not a > confirming commit. > > A cancel/timeout causes the config to revert to its state before the firs= t > confirmed commit > > operation. > > Jonathan > > Andy > > Andy, > > What I think you seem to be stating here is that there are three types of > commit (and possibly, by extension, four): > > 1. "Confirmed commit" - the first successful commit with a > parameter after a successful commit without a parameter > 2. "Extension commit" - any commit with a parameter after > a "confirmed commit" and before any successful "confirming commit" > 3. "Confirming commit" - any commit without a parameter > after a "confirmed commit" and before any other successful "confirming > commit" > 4. "Standard commit" - any commit without a parameter > after a successful "confirming commit" and before a subsequent "confir= med > commit" > > By those definitions a "confirmed commit" cannot follow another "confirme= d > commit" without an intervening "confirming commit". Yet 8.4.5.1 talks abo= ut > follow-up "confirmed commits" and "confirming commits". How can there be = a > follow-up "confirmed commit", unless the definition of a "confirmed commi= t" > becomes something like: > > (the first commit with a parameter after a successful commit > without a parameter) OR (the first successful commit with a > parameter from another session and the appropriate ) > > > > > > > > The saved state that that gets reverted if the commit is not confirmed > does not change > > because anther commit with a element is received. This 2nd > commit that > > is extending the confirmed commit procedure is clearly not a confirming > commit, so > > the server cannot update the saved state that will be reverted if > necessary. > > > > The terminology does not distinguish very well between the confirmed > commit procedure > > and a request that is called a confirmed commit. There is only 1 > confirmed commit > > procedure active at any given time. The 2nd confirmed commit > request does not end > > the first procedure and start a new one. Once the procedure is ended > somehow, > > then it ends for all the confirmed commit requests that are pending. > > > > > > Also, 8.4.5.1 states the parameter makes the "confirmed commit" > survive a session termination. Does that mean the parameter > can only be successful if the original session has been terminated, or is > it more accurate to state that the parameter allows the > "confirmed commit" to be extended by other sessions, whether or not the > original session has been terminated? > > > > No -- any session that knows the correct persist-id can complete the > procedure, > > including any session that sent a confirmed commit request. > > > > > > Thanks, > > Jonathan > > > > Andy > > > --001a1134a56aba8cb104ed59dfa0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,


On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh <<= a href=3D"mailto:ietfdbh@comcast.net" target=3D"_blank">ietfdbh@comcast.net= > wrote:

Hi,

=A0<= /p>

This thread about an e= rrata says to me that implementers could implement the original text in dif= ferent ways and be conformant to the standard.

=A0



What are the implem= entation differences that the spec allows?

=A0

The clarification text se= ems to be modifying what a conformant implementation must do, and obviously= the WG members haven=92t reached consensus on just what that must be. <= /u>

=A0


I do not agree that there is WG co= nsensus to accept the errata -- the discussion seems to show
that the term "confirmed commit" is used to refer to the ent= ire procedure and to a specific
form of a <commit> request.= =A0 There is no text that is clearly in error.

I don't think consensus has been established that different implementat= ions of confirmed commit
are possible. =A0The draft is clear abou= t the definition of a confirming commit, and also clear
what ends= a confirmed commit procedure.


If the clarification beco= mes part of conformance requirements, then existing implementations would l= ikely become non-conformant.

To me, that says a =96bis= is called for, including WGLC and IETF LCs, to change the conformance requ= irements of the standard.



Can you describ= e this non-conformance that needs to be fixed with a new RFC?
It = seems to me (and other implementors) that restoring the running config to
its state before the first confirmed commit <rpc> request is the= correct behavior.

I do not agree that the current= RFC text allows an interpretation that permits the
server to tre= at a <commit> with a <confirmed> element as a confirming commit= .
Only a timeout, <cancel-commit> or confirming commit can release= the server
from its obligation to revert the saved state.=A0

=A0

=A0

I am not implementing thi= s standard, so maybe I misjudge whether this affects existing implementatio= ns or not. Please let me know if I am looking at this incorrectly.

=A0<= /p>

David Harrington<= span style=3D"color:#1f497d">

ietfdbh@comcast.net

+1-603-828-1401

<= /div>



A= ndy

=A0

From:= Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bier= man
Sent: Thursday, December 12, 2013 11:57 AM
To: Jonathan Ha= nsford
Cc: Rob Enns; joel jaeggli; Netconf
Subject: Re:= [Netconf] [Technical Errata Reported] RFC6241 (3821)<= /p>

=A0

=A0

=A0

On Thu, Dec = 12, 2013 at 4:26 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:=

=A0

On 2013-12-10 17:05, Andy Bierman wrote:=

=A0

=A0

On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford <Jonathan@hansfords.net&g= t; wrote:

On 2013-12-10 16:15, Andy Bierman wrote:

=A0

=A0

On Tue, Dec 10, 2013 = at 8:05 AM, Jonathan Hansford <Jonathan@hansfords.net> wrote:

On 2013-12-10 15:59, Andy Bierman wrote:

Hi,

I don't think these 3= reports are corrections.

They are editorial changes to the text.

I don't agree that the new terminology added "sequence of confirme= d commits"

is corre= ct. =A0There is just 1 netconf-confirmed-commit notification for start &= ; complete

sent out no matter how how many times the= procedure is extended.

If the procedure ends with a cancel or timeout, there is only 1 origin= al commit

that is restored. =A0It is incorrect to t= hink of this procedure as a series of

confirmed commits. =A0A commit that extends the procedure is= not treated

the same as the commit that starts the pr= ocedure.

Are you saying that the initial commit of the sequence (the = confirmed commit?) is restored should the procedure be cancelled or timeout= ? Surely the commit that is restored is the one that preceded the confirmed= commit.

The confirmed commit is the f= irst <commit> that includes a <confirmed> parameter.<= /u>

The 2nd - Nth <commit> are e= xtending the first commit operation. =A0The server is still

obligated to revert the running config fo= r the first commit (if it is canceled or timed out).

This obligation is not removed because the com= mit is extended. =A0It is only removed

if a confirming commit is received.

Andy,

I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd = paragraph) talks about 'a follow-up confirmed <commit> operation&= #39;. Are you saying that that second 'confirmed <commit>' (i= .e. a <commit> with the <confirmed> parameter) is not a "c= onfirmed commit"? And when you say 'the server is obligated to rev= ert the running config for the first commit' do you mean revert to the = state prior to that first confirmed <commit>?

sec. 8.4.1, para 2:<= /u>

=A0=A0 The confirming commit is a <commit> operation=

=A0=A0 without the <confirmed> parameter.

The 2nd commit with a <confirmed> par= ameter extends the confirmed-commit procedure.

=

Any cancel or complete applies to this commit. =A0If canceled, then the cha= nges made for the

2nd co= mmit are going to be undone. =A0An extension commit is not a confirming com= mit.

A cancel/timeout causes the config to rev= ert to its state before the first confirmed commit

<= div>

operation.

Jonathan

Andy

= Andy,

What I think you seem to be stating here = is that there are three types of commit (and possibly, by extension, four):=

  1. "Confirmed commit" - the first successful commit with a <confi= rmed> parameter after a successful commit without a <confirmed> pa= rameter
  2. "Extension commit&qu= ot; - any commit with a <confirmed> parameter after a "confirmed= commit" and before any successful "confirming commit"
  3. "Confirming commit" - any commit without = a <confirmed> parameter after a "confirmed commit" and befo= re any other successful "confirming commit"
    4. "Standard commit" - any commit without a <confirmed> parame= ter after a successful "confirming commit" and before a subsequen= t "confirmed commit"

By those definitio= ns a "confirmed commit" cannot follow another "confirmed com= mit" without an intervening "confirming commit". Yet 8.4.5.1= talks about follow-up "confirmed commits" and "confirming c= ommits". How can there be a follow-up "confirmed commit", un= less the definition of a "confirmed commit" becomes something lik= e:

(the first commit with a <confirmed> parameter after a successful = commit without a <confirmed> parameter) OR (the first successful comm= it with a <confirmed> parameter from another session and the appropri= ate <persist-id>)

=A0=

=A0

=A0

Th= e saved state that that gets reverted if the commit is not confirmed does n= ot change

because anther commit with a <confirme= d> element is received. =A0This 2nd commit that

<= div>

is extending the confirmed commit procedure is c= learly not a confirming commit, so

the server cannot update the saved state = that will be reverted if necessary.

=A0

The term= inology does not distinguish very well between the confirmed commit procedu= re

and a <rpc> request that is called = a confirmed commit. =A0There is only 1 confirmed commit

procedure active at any given time. =A0The = 2nd confirmed commit <rpc> request does not end

the first procedure and start a new one. = =A0Once the procedure is ended somehow,

then it ends for all the confirmed commit requests that are= pending.

=A0

=A0

Also, 8.4.5.1 states the <persist> parame= ter makes the "confirmed commit" survive a session termination. D= oes that mean the <persist-id> parameter can only be successful if th= e original session has been terminated, or is it more accurate to state tha= t the <persist> parameter allows the "confirmed commit" to = be extended by other sessions, whether or not the original session has been= terminated?

<= /u>=A0

No -- any session that k= nows the correct persist-id can complete the procedure,

including any session that sent a confirmed com= mit <rpc> request.

=A0

=A0

Thanks,

Jonathan

=A0

Andy

=A0


--001a1134a56aba8cb104ed59dfa0-- From mbj@tail-f.com Thu Dec 12 10:29:13 2013 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 E7D5A1AD75F for ; Thu, 12 Dec 2013 10:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Z45rJucSjMoo for ; Thu, 12 Dec 2013 10:29:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 936791AE0BE for ; Thu, 12 Dec 2013 10:29:10 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id D119537C040; Thu, 12 Dec 2013 19:29:02 +0100 (CET) Date: Thu, 12 Dec 2013 19:29:02 +0100 (CET) Message-Id: <20131212.192902.499172458.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <004e01cef75e$7bb29250$7317b6f0$@comcast.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp-3 Content-Transfer-Encoding: 7bit Cc: rob.enns@gmail.com, joelja@bogus.com, netconf@ietf.org 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: Thu, 12 Dec 2013 18:29:14 -0000 Hi, I agree w/ Andy. The current text is correct, but can be improved (clearer). /martin Andy Bierman wrote: > Hi, > > > On Thu, Dec 12, 2013 at 9:20 AM, ietfdbh wrote: > > > Hi, > > > > > > > > This thread about an errata says to me that implementers could implement > > the original text in different ways and be conformant to the standard. > > > > > > > > > What are the implementation differences that the spec allows? > > > > > The clarification text seems to be modifying what a conformant > > implementation must do, and obviously the WG members haven$B!G(Bt reached > > consensus on just what that must be. > > > > > > > > I do not agree that there is WG consensus to accept the errata -- the > discussion seems to show > that the term "confirmed commit" is used to refer to the entire procedure > and to a specific > form of a request. There is no text that is clearly in error. > > I don't think consensus has been established that different implementations > of confirmed commit > are possible. The draft is clear about the definition of a confirming > commit, and also clear > what ends a confirmed commit procedure. > > > If the clarification becomes part of conformance requirements, then > > existing implementations would likely become non-conformant. > > > > To me, that says a $(Q#|(Bbis is called for, including WGLC and IETF LCs, to > > change the conformance requirements of the standard. > > > > > Can you describe this non-conformance that needs to be fixed with a new RFC? > It seems to me (and other implementors) that restoring the running config to > its state before the first confirmed commit request is the correct > behavior. > > I do not agree that the current RFC text allows an interpretation that > permits the > server to treat a with a element as a confirming > commit. > Only a timeout, or confirming commit can release the server > from its obligation to revert the saved state. > > > > > > > > > I am not implementing this standard, so maybe I misjudge whether this > > affects existing implementations or not. Please let me know if I am looking > > at this incorrectly. > > > > > > > > David Harrington > > > > ietfdbh@comcast.net > > > > +1-603-828-1401 > > > > > > Andy > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > > Bierman > > *Sent:* Thursday, December 12, 2013 11:57 AM > > *To:* Jonathan Hansford > > *Cc:* Rob Enns; joel jaeggli; Netconf > > *Subject:* Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) > > > > > > > > > > > > > > > > On Thu, Dec 12, 2013 at 4:26 AM, Jonathan Hansford > > wrote: > > > > > > > > On 2013-12-10 17:05, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Dec 10, 2013 at 8:26 AM, Jonathan Hansford > > wrote: > > > > On 2013-12-10 16:15, Andy Bierman wrote: > > > > > > > > > > > > On Tue, Dec 10, 2013 at 8:05 AM, Jonathan Hansford > > wrote: > > > > On 2013-12-10 15:59, Andy Bierman wrote: > > > > Hi, > > > > I don't think these 3 reports are corrections. > > > > They are editorial changes to the text. > > > > I don't agree that the new terminology added "sequence of confirmed > > commits" > > > > is correct. There is just 1 netconf-confirmed-commit notification for > > start & complete > > > > sent out no matter how how many times the procedure is extended. > > > > If the procedure ends with a cancel or timeout, there is only 1 original > > commit > > > > that is restored. It is incorrect to think of this procedure as a series > > of > > > > confirmed commits. A commit that extends the procedure is not treated > > > > the same as the commit that starts the procedure. > > > > Are you saying that the initial commit of the sequence (the confirmed > > commit?) is restored should the procedure be cancelled or timeout? Surely > > the commit that is restored is the one that preceded the confirmed commit. > > > > The confirmed commit is the first that includes a > > parameter. > > > > The 2nd - Nth are extending the first commit operation. The > > server is still > > > > obligated to revert the running config for the first commit (if it is > > canceled or timed out). > > > > This obligation is not removed because the commit is extended. It is only > > removed > > > > if a confirming commit is received. > > > > Andy, > > > > I'm not sure whether we agreeing or not. Section 8.4.1 of RFC6241 (2nd > > paragraph) talks about 'a follow-up confirmed operation'. Are you > > saying that that second 'confirmed ' (i.e. a with the > > parameter) is not a "confirmed commit"? And when you say 'the > > server is obligated to revert the running config for the first commit' do > > you mean revert to the state prior to that first confirmed ? > > > > sec. 8.4.1, para 2: > > > > The confirming commit is a operation > > > > without the parameter. > > > > The 2nd commit with a parameter extends the confirmed-commit > > procedure. > > > > Any cancel or complete applies to this commit. If canceled, then the > > changes made for the > > > > 2nd commit are going to be undone. An extension commit is not a > > confirming commit. > > > > A cancel/timeout causes the config to revert to its state before the first > > confirmed commit > > > > operation. > > > > Jonathan > > > > Andy > > > > Andy, > > > > What I think you seem to be stating here is that there are three types of > > commit (and possibly, by extension, four): > > > > 1. "Confirmed commit" - the first successful commit with a > > parameter after a successful commit without a parameter > > 2. "Extension commit" - any commit with a parameter after > > a "confirmed commit" and before any successful "confirming commit" > > 3. "Confirming commit" - any commit without a parameter > > after a "confirmed commit" and before any other successful "confirming > > commit" > > 4. "Standard commit" - any commit without a parameter > > after a successful "confirming commit" and before a subsequent "confirmed > > commit" > > > > By those definitions a "confirmed commit" cannot follow another "confirmed > > commit" without an intervening "confirming commit". Yet 8.4.5.1 talks about > > follow-up "confirmed commits" and "confirming commits". How can there be a > > follow-up "confirmed commit", unless the definition of a "confirmed commit" > > becomes something like: > > > > (the first commit with a parameter after a successful commit > > without a parameter) OR (the first successful commit with a > > parameter from another session and the appropriate ) > > > > > > > > > > > > > > > > The saved state that that gets reverted if the commit is not confirmed > > does not change > > > > because anther commit with a element is received. This 2nd > > commit that > > > > is extending the confirmed commit procedure is clearly not a confirming > > commit, so > > > > the server cannot update the saved state that will be reverted if > > necessary. > > > > > > > > The terminology does not distinguish very well between the confirmed > > commit procedure > > > > and a request that is called a confirmed commit. There is only 1 > > confirmed commit > > > > procedure active at any given time. The 2nd confirmed commit > > request does not end > > > > the first procedure and start a new one. Once the procedure is ended > > somehow, > > > > then it ends for all the confirmed commit requests that are pending. > > > > > > > > > > > > Also, 8.4.5.1 states the parameter makes the "confirmed commit" > > survive a session termination. Does that mean the parameter > > can only be successful if the original session has been terminated, or is > > it more accurate to state that the parameter allows the > > "confirmed commit" to be extended by other sessions, whether or not the > > original session has been terminated? > > > > > > > > No -- any session that knows the correct persist-id can complete the > > procedure, > > > > including any session that sent a confirmed commit request. > > > > > > > > > > > > Thanks, > > > > Jonathan > > > > > > > > Andy > > > > > > From j.schoenwaelder@jacobs-university.de Thu Dec 12 12:13:34 2013 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 B416D1AE410 for ; Thu, 12 Dec 2013 12:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 ZzD_0887j1b0 for ; Thu, 12 Dec 2013 12:13:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 769321AE1EE for ; Thu, 12 Dec 2013 12:13:32 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DDF74200A8; Thu, 12 Dec 2013 21:13:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fT9fS6KXsJyg; Thu, 12 Dec 2013 21:13:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18E70200A7; Thu, 12 Dec 2013 21:13:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 87B0E29FD955; Thu, 12 Dec 2013 21:13:19 +0100 (CET) Date: Thu, 12 Dec 2013 21:13:19 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20131212201319.GC81732@elstar.local> Mail-Followup-To: ietfdbh , 'Andy Bierman' , 'Jonathan Hansford' , 'Rob Enns' , 'joel jaeggli' , 'Netconf' References: <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> <004e01cef75e$7bb29250$7317b6f0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004e01cef75e$7bb29250$7317b6f0$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Rob Enns' , 'joel jaeggli' , 'Netconf' Subject: Re: [Netconf] [Technical Errata Reported] RFC6241 (3821) 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: Thu, 12 Dec 2013 20:13:35 -0000 On Thu, Dec 12, 2013 at 12:20:40PM -0500, ietfdbh wrote: > Hi, > > The clarification text seems to be modifying what a conformant > implementation must do, and obviously the WG members haven't reached > consensus on just what that must be. > I do not thing this is a fair assessment of the situation. I believe people do agree on the intended behaviour; there is perhaps less agreement on how to describe it better. Jonathan's proposal in the errata helps somewhat but I believe to really describe this well, we actually need to discuss the various situations in more detail. > To me, that says a -bis is called for, including WGLC and IETF LCs, to > change the conformance requirements of the standard. I do not think this is the case. In other parts of the IETF, there are sometimes implementation guideline documents that clear up some of the issues. I am not saying we need to produce one but this would be an option to deal with this case. The reason I am not exiting about such an implementation guideline document is that confirmed commit by itself does not justify to write one. If more things like this pop up, we might reach the point where such a document could be reasonable to produce. /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 Fri Dec 13 00:43:21 2013 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 518261ADFA6 for ; Fri, 13 Dec 2013 00:43:21 -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 0RReNxWTWjqo for ; Fri, 13 Dec 2013 00:43:02 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADEA1AE1EF for ; Fri, 13 Dec 2013 00:42:52 -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 1VrOKY-0006rv-1J; Fri, 13 Dec 2013 09:42:43 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=[IPv6:::1]) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VrOKX-00016m-NQ; Fri, 13 Dec 2013 09:42:41 +0100 Message-ID: <52AAC886.6000000@bwijnen.net> Date: Fri, 13 Dec 2013 09:42:46 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: ietfdbh , 'Andy Bierman' , 'Jonathan Hansford' , 'Rob Enns' , 'joel jaeggli' , 'Netconf' References: <52A7244A.4090006@bwijnen.net> <20131210.153651.1182516105923318005.mbj@tail-f.com> <7de2779d935aae627d3c3b030466b1dc@imap.plus.net> <80d82e162c729b696be4ddd23dc624d2@imap.plus.net> <004e01cef75e$7bb29250$7317b6f0$@comcast.net> <20131212201319.GC81732@elstar.local> In-Reply-To: <20131212201319.GC81732@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: 86ab03e524994f79ca2c75a176445dd42898456639c3cb22877c0423168ed170 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: Fri, 13 Dec 2013 08:43:21 -0000 Inline On 12/12/13 9:13 PM, Juergen Schoenwaelder wrote: > I believe people do agree on the intended behaviour; there is perhaps > less agreement on how to describe it better. Jonathan's proposal in > the errata helps somewhat but I believe to really describe this well, > we actually need to discuss the various situations in more detail. If we indeed believe that we agree on the behaviour and IF we believe we can make the text to describe that better, then I propose that the document authors sit together to come uo with a proposed new text that we can then discuss on this list. Bert From uprajput@cisco.com Thu Dec 12 14:19:03 2013 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 ED71C1AE50E for ; Thu, 12 Dec 2013 14:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 yQJFbQJfNblB for ; Thu, 12 Dec 2013 14:19:02 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 72EE71AE176 for ; Thu, 12 Dec 2013 14:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2757; q=dns/txt; s=iport; t=1386886736; x=1388096336; h=from:to:subject:date:message-id:mime-version; bh=bN4NxezAhTCfZ13JoQAInrelku5gvvivArr+iRl8BTI=; b=gUaai60nrzGR41NIBPBBfTQMw916fccIGCRfm1AfYxvAvqdiaohQXVjm 96nBBJXvDQmjXxt9iYkmm8qh3RoH2ayz11CYy1d1V3LHyYHAE/H//Cwdt nLec1A5bksY/jKoFHnfiS3pGYZm+5FtWEbUjUZG/BlilF2zZgZvmcex0m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJE1qlKtJXG//2dsb2JhbABZgkZEgQ25dhZ0giyBCwEMAXMnBIgXo3+fJReTUASYFZIUgymCKg X-IronPort-AV: E=Sophos;i="4.95,474,1384300800"; d="scan'208,217";a="291211223" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 12 Dec 2013 22:18:56 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBCMIuqM009094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Dec 2013 22:18:56 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.86]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:18:56 -0600 From: "Upendra Rajput (uprajput)" To: "netconf@ietf.org" Thread-Topic: RESTCONF depth parameter Thread-Index: AQHO94glJ0RF/hpcY02i2VylCz74vg== Date: Thu, 12 Dec 2013 22:18:55 +0000 Message-ID: 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: [10.154.204.62] Content-Type: multipart/alternative; boundary="_000_CECF765337003uprajputciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Dec 2013 01:20:59 -0800 Subject: [Netconf] RESTCONF depth parameter 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, 12 Dec 2013 22:22:43 -0000 --_000_CECF765337003uprajputciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was looking at the "depth" parameter example in RESTCONF draft version 2 = in section 3.8.1. There they have an example that will retrieve 2 levels of= configuration data nodes from "example-jukebox" module. And the result of = retrieval is shown as: { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } My question is since both containers and lists are defined as resources the= n why "list playlist" is not included in the result shown above ? Will an error be returned when level is less then 1 ? Also I will appreciate if you can provide sample of what will be returned w= hen depth is 1 and 3. Thanks ~Upendra --_000_CECF765337003uprajputciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I was looking at the "depth" parameter example in RESTCONF d= raft version 2 in section 3.8.1. There they have an example that will retri= eve 2 levels of configuration data nodes from "example-jukebox" m= odule. And the result of retrieval is shown as:
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }

My question is since both containers and lists are defined as r= esources then why "list playlist" is not included in the result shown above = ? 

Will an error be returned when level is less then 1 ?

Also I will appreciate if you can provide sample of what will be retur= ned when depth is 1 and 3.


Thanks
~Upendra


--_000_CECF765337003uprajputciscocom_-- From andy@yumaworks.com Fri Dec 13 09:28:24 2013 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 CD88C1AE340 for ; Fri, 13 Dec 2013 09:28:24 -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 jUJ8quMOgRky for ; Fri, 13 Dec 2013 09:28:22 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA501AE126 for ; Fri, 13 Dec 2013 09:28:22 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id nd7so1836103qeb.17 for ; Fri, 13 Dec 2013 09:28:16 -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=zjT4n+OHIf93ED1A2izQwjvi7hAJjVZsgkIdCf51Z7A=; b=ZCnKRHhteqbgvz8NcfveaTD6M4spPgkPH3aS5B1uLfcdbiaOpQ58JcP/wli+q0o700 6YKcm1NajX1NCKnYw1afQ78j/MhPEWdc0VglagbzL+7FL7DFgrxRfV8s+5Fads6IRlbh To6Eyo7Lij+D9zf2OGFaXWrfWWEm6o1j+2o7O6UHDRZOo/DC5FznqpTVL0JGEgLYQPMz Hq8Wf3kvl4/XLvFHaH8e8mowlZ8+U8s7IIOSmYcmeLD+elnqfEJ5t1wJd96bZ0G67sQQ LUo+FEpFpiGPuX9uwojsP2D8UPNVoRcDm8e26xyjwjf6i51KpgARMdt/gmfcyR9TkOHj Sz7A== X-Gm-Message-State: ALoCoQnqeB+aW31sOxJMs74zCzIoCCsQpExaL63FAYnjf76d/DcS1ICl8KfqGfwO72qVSTWAhuhI MIME-Version: 1.0 X-Received: by 10.49.130.135 with SMTP id oe7mr6572461qeb.41.1386955695937; Fri, 13 Dec 2013 09:28:15 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 13 Dec 2013 09:28:15 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 09:28:15 -0800 Message-ID: From: Andy Bierman To: "Upendra Rajput (uprajput)" Content-Type: multipart/alternative; boundary=047d7bd6bc44936f6c04ed6dc9a0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF depth parameter 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, 13 Dec 2013 17:28:25 -0000 --047d7bd6bc44936f6c04ed6dc9a0 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput (uprajput) < uprajput@cisco.com> wrote: > Hi, > > I was looking at the "depth" parameter example in RESTCONF draft version > 2 in section 3.8.1. There they have an example that will retrieve 2 levels > of configuration data nodes from "example-jukebox" module. And the result > of retrieval is shown as: > > { > "example-jukebox:jukebox" : { > "library" : { > "artist" : { > "name" : "Foo Fighters" > } > }, > "player" : { > "gap" : 0.5 > } > } > } > > > This example is wrong and needs to be fixed. The depth parameter is affected by the decision to make all YANG nodes be resources instead of just containers and lists. The example did not get updated to adjust for this change. The example will be clarified so the starting data is shown, so it is clear what is begin filtered by the depth parameter: GET /restconf/config/example-jukebox:jukebox { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } GET /restconf/config/example-jukebox:jukebox?depth=1 { "example-jukebox:jukebox" : [null] } GET /restconf/config/example-jukebox:jukebox?depth=2 { "example-jukebox:jukebox" : { "library" : [null], "player" : [null] } } GET /restconf/config/example-jukebox:jukebox?depth=3 { "example-jukebox:jukebox" : { "library" : { "artist" : [null] }, "player" : { "gap" : 0.5 } } } > My question is since *both containers and lists* are defined as > resources then why *"list playlist"* is not included in the result shown > above ? > > Will an error be returned when level is less then 1 ? > > yes > Also I will appreciate if you can provide sample of what will be > returned when depth is 1 and 3. > > > Thanks > ~Upendra > > Andy --047d7bd6bc44936f6c04ed6dc9a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput (uprajput) <upraj= put@cisco.com> wrote:
Hi,

I was looking at the "depth" parameter example in RESTCONF d= raft version 2 in section 3.8.1. There they have an example that will retri= eve 2 levels of configuration data nodes from "example-jukebox" m= odule. And the result of retrieval is shown as:
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }




This example is wrong and needs to be fixed.
The depth p= arameter is affected by the decision to make
all YANG nodes be re= sources instead of just containers and lists.
The example did not get updated to adjust for this change.
<= br>
The example will be clarified so the starting data is shown, = so it is
clear what is begin filtered by the depth parameter: 

GET /restconf/config/exam=
ple-jukebox:jukebox
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }
GET /restconf/config/example-juk=
ebox:jukebox?depth=3D1
     {
        "example-jukebox:jukebox" : [null]
     }

GET /restconf/config/example-jukebox:jukebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
          "player" : [null]
        }
      }

GET /restconf/config/example-jukebox:jukeb=
ox?depth=3D3
     {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : [null]
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }

=A0
My question is since both containers and lists are defined as r= esources then why "list playlist" is not included in the result shown above = ?=A0

Will an error be returned when level is less then 1 ?


yes=A0
=A0<= /div>
Also I will appreciate if you can provide sample of what will be retur= ned when depth is 1 and 3.


Thanks
~Upendra



Andy
=A0
--047d7bd6bc44936f6c04ed6dc9a0-- From uprajput@cisco.com Fri Dec 13 09:48:08 2013 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 C2A241AE364 for ; Fri, 13 Dec 2013 09:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 gbUhuFS1tTlZ for ; Fri, 13 Dec 2013 09:48:06 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC321AE363 for ; Fri, 13 Dec 2013 09:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11031; q=dns/txt; s=iport; t=1386956880; x=1388166480; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=13fZPiO/XhyeabmccOS22Uty1Wi9uabX9LFp+XMHu/0=; b=RFL1IgKvtK0OVN3bIfFAzLOjORWyQUJSpkDYM3IQ7mA+eBTRh+4CG5h9 P08cnZw4zoKNUnpDBo6lwPpDBowN0RmQRGD1H0sHXlduCdugPOudJGxJt ZwuElY4fQ5rOJXm8rqd8Uk5DNmS13ALrF2sHzyYsvnORULCiMdnIa1NaW 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAApIq1KtJV2c/2dsb2JhbABZgkZEgQ24XYElFnSCJQEBAQR5EAIBCBEDAQIoBzIUCQgCBA4FiATLHhePBBEGAYQ2BJgWkhSDKoIq X-IronPort-AV: E=Sophos;i="4.95,480,1384300800"; d="scan'208,217";a="291426647" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Dec 2013 17:47:59 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rBDHlxAa016086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 17:48:00 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.86]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 11:47:59 -0600 From: "Upendra Rajput (uprajput)" To: Andy Bierman Thread-Topic: [Netconf] RESTCONF depth parameter Thread-Index: AQHO94glJ0RF/hpcY02i2VylCz74vppSxu2A//9/aQA= Date: Fri, 13 Dec 2013 17:47:58 +0000 Message-ID: References: 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: [10.21.101.11] Content-Type: multipart/alternative; boundary="_000_CED085F2370E2uprajputciscocom_" MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF depth parameter 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, 13 Dec 2013 17:48:09 -0000 --_000_CED085F2370E2uprajputciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Andy. In your example for depth=3D2 why is LIST "playlist" omitted. It is at the = same level as CONTAINER "library" and "player" are. So I was thinking it wi= ll be part of depth=3D2 output for the example module that is being used in= the draft. GET /restconf/config/example-jukebox:jukebox?depth=3D2 { "example-jukebox:jukebox" : { "library" : [null], "playlist": [null], <<=3D=3D Missing in your example for depth=3D2 "player" : [null] } } Thanks ~Upendra From: Andy Bierman > Date: Friday, December 13, 2013 9:28 AM To: Cisco Employee > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] RESTCONF depth parameter On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput (uprajput) > wrote: Hi, I was looking at the "depth" parameter example in RESTCONF draft version 2 = in section 3.8.1. There they have an example that will retrieve 2 levels of= configuration data nodes from "example-jukebox" module. And the result of = retrieval is shown as: { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } This example is wrong and needs to be fixed. The depth parameter is affected by the decision to make all YANG nodes be resources instead of just containers and lists. The example did not get updated to adjust for this change. The example will be clarified so the starting data is shown, so it is clear what is begin filtered by the depth parameter: GET /restconf/config/example-jukebox:jukebox { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } GET /restconf/config/example-jukebox:jukebox?depth=3D1 { "example-jukebox:jukebox" : [null] } GET /restconf/config/example-jukebox:jukebox?depth=3D2 { "example-jukebox:jukebox" : { "library" : [null], "player" : [null] } } GET /restconf/config/example-jukebox:jukebox?depth=3D3 { "example-jukebox:jukebox" : { "library" : { "artist" : [null] }, "player" : { "gap" : 0.5 } } } My question is since both containers and lists are defined as resources the= n why "list playlist" is not included in the result shown above ? Will an error be returned when level is less then 1 ? yes Also I will appreciate if you can provide sample of what will be returned w= hen depth is 1 and 3. Thanks ~Upendra Andy --_000_CED085F2370E2uprajputciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Than= ks Andy.

In y= our example for depth=3D2 why is LIST "playlist" omitted. It is a= t the same level as CONTAINER "library" and "player" ar= e. So I was thinking it will be part of depth=3D2 output for the example module that is being used in the draft.
GET =
/restconf/config/example-jukebox:jukebox?depth=3D2
    =
 {
        "example-jukebox:jukebox" : {
          "library" : [null],
    "playlist": [null],   <=
;<=3D=3D Missing in your example for depth=3D2
    =
      "player" : [null]
        }
      }

Than= ks
~Upe= ndra


From: Andy Bierman <andy@yumaworks.com>
Date: Friday, December 13, 2013 9:2= 8 AM
To: Cisco Employee <uprajput@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dep= th parameter




On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput = (uprajput) <uprajput@cisco.com> wrote:
Hi,

I was looking at the "depth" parameter example in RESTCONF d= raft version 2 in section 3.8.1. There they have an example that will retri= eve 2 levels of configuration data nodes from "example-jukebox" m= odule. And the result of retrieval is shown as:
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }




This example is wrong and needs to be fixed.
The depth parameter is affected by the decision to make
all YANG nodes be resources instead of just containers and lists.
The example did not get updated to adjust for this change.

The example will be clarified so the starting data is shown, so it is<= /div>
clear what is begin filtered by the depth parameter:

GET /restconf/config/example-jukebox:jukebox<=
/pre>

      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }
GET /restconf/config/example-jukebox:jukebox?=
depth=3D1
     {
        "example-jukebox:jukebox" : [null]
     }

GET /restconf/config/example-jukebox:juk=
ebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
          "player" : [null]
        }
      }

GET /restconf/config/example-jukebox:jukeb=
ox?depth=3D3
     {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : [null]
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }

 
My question is since both containers and lists are defined as r= esources then why "list playlist" is not included in the result shown above = ? 

Will an error be returned when level is less then 1 ?


yes 
 
Also I will appreciate if you can provide sample of what will be retur= ned when depth is 1 and 3.


Thanks
~Upendra



Andy
 
--_000_CED085F2370E2uprajputciscocom_-- From andy@yumaworks.com Fri Dec 13 10:04:55 2013 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 A64951ADF7E for ; Fri, 13 Dec 2013 10:04:55 -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 GyiUtrPGdPKv for ; Fri, 13 Dec 2013 10:04:53 -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 4B9371ADF77 for ; Fri, 13 Dec 2013 10:04:53 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id nc12so1842065qeb.26 for ; Fri, 13 Dec 2013 10:04: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=ojcPilMu6qaMtHbInbBim5a0mRFAUWOPjIoeWu5T38o=; b=VnZqe8qUBRBkCtOAHf11dQ7aqt87rAR2ywTgcKVsZcs+0IijaLN2DpLqa47mFGWVKT H5yCjvLxN7/pDvS36qx/Opj76i6mJQtoJv4Nz0ynvZJGYHy5J/wfWUUvtBsqPC8fdu3f 6u9vSpgiUdRVXuZi4SZNZY1MENSNUGmdoxWP1oa/brtVzxUUbVXz7P4mPFmyR9QqoouE 3z2fT9SoEtorSWf3268+1e7jQZCIaKTYYRR99ODb5Xz0TLSyn2FcNTfbReRCyrDlAssj Adzp1IwFwsCSreuyMr0p7SU3X55oVIxJoo0sbJwurK0CZbGnPPwlCVEMMb5CJbw17Q2z 214g== X-Gm-Message-State: ALoCoQncvi4tXjvyYbCKZuNQU9awRnWzml8H4wkl6xrnoTB2nJtsFjxjUcTDNXjcSVrWALPunu3D MIME-Version: 1.0 X-Received: by 10.224.60.69 with SMTP id o5mr6960153qah.92.1386957886799; Fri, 13 Dec 2013 10:04:46 -0800 (PST) Received: by 10.140.48.75 with HTTP; Fri, 13 Dec 2013 10:04:46 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 10:04:46 -0800 Message-ID: From: Andy Bierman To: "Upendra Rajput (uprajput)" Content-Type: multipart/alternative; boundary=001a11c3e4882955c504ed6e4cda Cc: "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF depth parameter 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, 13 Dec 2013 18:04:55 -0000 --001a11c3e4882955c504ed6e4cda Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 13, 2013 at 9:47 AM, Upendra Rajput (uprajput) < uprajput@cisco.com> wrote: > Thanks Andy. > > In your example for depth=2 why is LIST "playlist" omitted. It is at the > same level as CONTAINER "library" and "player" are. So I was thinking it > will be part of depth=2 output for the example module that is being used in > the draft. > > GET /restconf/config/example-jukebox:jukebox?depth=2 > > { > "example-jukebox:jukebox" : { > "library" : [null], > > "playlist": [null], <<== Missing in your example for depth=2 > > "player" : [null] > } > } > > > Not based on the starting point (no depth parameter given). I will add 1 or 2 playlists in the draft example. > Thanks > ~Upendra > > Andy > > From: Andy Bierman > Date: Friday, December 13, 2013 9:28 AM > To: Cisco Employee > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] RESTCONF depth parameter > > > > > On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput (uprajput) < > uprajput@cisco.com> wrote: > >> Hi, >> >> I was looking at the "depth" parameter example in RESTCONF draft >> version 2 in section 3.8.1. There they have an example that will retrieve 2 >> levels of configuration data nodes from "example-jukebox" module. And the >> result of retrieval is shown as: >> >> { >> "example-jukebox:jukebox" : { >> "library" : { >> "artist" : { >> "name" : "Foo Fighters" >> } >> }, >> "player" : { >> "gap" : 0.5 >> } >> } >> } >> >> >> > > > This example is wrong and needs to be fixed. > The depth parameter is affected by the decision to make > all YANG nodes be resources instead of just containers and lists. > The example did not get updated to adjust for this change. > > The example will be clarified so the starting data is shown, so it is > clear what is begin filtered by the depth parameter: > > GET /restconf/config/example-jukebox:jukebox > > { > "example-jukebox:jukebox" : { > "library" : { > "artist" : { > "name" : "Foo Fighters" > } > }, > "player" : { > "gap" : 0.5 > } > } > } > > GET /restconf/config/example-jukebox:jukebox?depth=1 > > { > "example-jukebox:jukebox" : [null] > } > > > GET /restconf/config/example-jukebox:jukebox?depth=2 > > { > "example-jukebox:jukebox" : { > "library" : [null], > "player" : [null] > } > } > > > GET /restconf/config/example-jukebox:jukebox?depth=3 > > { > "example-jukebox:jukebox" : { > "library" : { > "artist" : [null] > }, > "player" : { > "gap" : 0.5 > } > } > } > > > > >> My question is since *both containers and lists* are defined as >> resources then why *"list playlist"* is not included in the result shown >> above ? >> >> Will an error be returned when level is less then 1 ? >> >> > yes > > >> Also I will appreciate if you can provide sample of what will be >> returned when depth is 1 and 3. >> >> >> Thanks >> ~Upendra >> >> > > Andy > > --001a11c3e4882955c504ed6e4cda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Dec 13, 2013 at 9:47 AM, Upendra Rajput (uprajput) <upraj= put@cisco.com> wrote:
Thanks Andy.

In your example for depth=3D2= why is LIST "playlist" omitted. It is at the same level as CONTA= INER "library" and "player" are. So I was thinking it w= ill be part of depth=3D2 output for the example module that is being used in the draft.
GET /restconf/config/example-=
jukebox:jukebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
    "playlist": [null],   <<=
;=3D=3D Missing in your example for depth=3D2
          "player" =
: [null]
        }
      }

=

Not based on the starting point (no depth parameter giv= en).
I will add 1 or 2 playlists in the draft example.

=A0
Thanks
~Upendra

=


Andy

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

From: Andy Bierman <andy@yumaworks.com>
Date: Friday, December 13, 2013 9:2= 8 AM
To: Cisco Employee <uprajput@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dep= th parameter




On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput = (uprajput) <uprajput@cisco.com> wrote:
Hi,

I was looking at the "depth" parameter example in RESTCONF d= raft version 2 in section 3.8.1. There they have an example that will retri= eve 2 levels of configuration data nodes from "example-jukebox" m= odule. And the result of retrieval is shown as:
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }




This example is wrong and needs to be fixed.
The depth parameter is affected by the decision to make
all YANG nodes be resources instead of just containers and lists.
The example did not get updated to adjust for this change.

The example will be clarified so the starting data is shown, so it is<= /div>
clear what is begin filtered by the depth parameter:

GET /restconf/config/example-jukebox:jukebox<=
/pre>

      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }
GET /restconf/config/example-jukebox:jukebox?=
depth=3D1
     {
        "example-jukebox:jukebox" : [null]
     }

GET /restconf/config/example-jukebox:juk=
ebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
          "player" : [null]
        }
      }

GET /restconf/config/example-jukebox:jukeb=
ox?depth=3D3
     {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : [null]
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }

=A0
My question is since both containers and lists are defined as r= esources then why "list playlist" is not included in the result shown above = ?=A0

Will an error be returned when level is less then 1 ?


yes=A0
=A0
Also I will appreciate if you can provide sample of what will be retur= ned when depth is 1 and 3.


Thanks
~Upendra



Andy
=A0

--001a11c3e4882955c504ed6e4cda-- From uprajput@cisco.com Fri Dec 13 10:28:37 2013 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 C75251AE142 for ; Fri, 13 Dec 2013 10:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 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.001, 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 NtW5ye6DwkRX for ; Fri, 13 Dec 2013 10:28:35 -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 323441ADFEF for ; Fri, 13 Dec 2013 10:28:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13719; q=dns/txt; s=iport; t=1386959309; x=1388168909; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tfwYhzQQRERu3TjX+fFNYMiWPtUcCQLW8FeuL3Lttj4=; b=SVIRrb5+hX4WI5tiho26mlfKwmxkfu3py8QAWVn+GZZRHWspnkO9g09h PlY+AY4klqAeqL4W009et7s5jBqRd36bv1USddCBGRmuYL9wtCFtP2MIQ XKgwstXrxSXAVySYCyiGsXZNNDJDydSfaXIH8WpOd7q+vFDFztKIQMiPW o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAH1Qq1KtJXG9/2dsb2JhbABZgkZEgQ24XYElFnSCJQEBAQR5EAIBCBEDAQIoBzIUCQgCBA4FiATLKhePBBEGAYQ2BJgWkhSDKoIq X-IronPort-AV: E=Sophos;i="4.95,480,1384300800"; d="scan'208,217";a="6630665" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 13 Dec 2013 18:28:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBDISSOO014324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 18:28:28 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.86]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 13 Dec 2013 12:28:27 -0600 From: "Upendra Rajput (uprajput)" To: Andy Bierman Thread-Topic: [Netconf] RESTCONF depth parameter Thread-Index: AQHO94glJ0RF/hpcY02i2VylCz74vppSxu2A//9/aQCAAIrLAP//gISA Date: Fri, 13 Dec 2013 18:28:26 +0000 Message-ID: References: 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: [10.21.101.11] Content-Type: multipart/alternative; boundary="_000_CED091A33710Cuprajputciscocom_" MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] RESTCONF depth parameter 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, 13 Dec 2013 18:28:38 -0000 --_000_CED091A33710Cuprajputciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you Andy. From: Andy Bierman > Date: Friday, December 13, 2013 10:04 AM To: Cisco Employee > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] RESTCONF depth parameter On Fri, Dec 13, 2013 at 9:47 AM, Upendra Rajput (uprajput) > wrote: Thanks Andy. In your example for depth=3D2 why is LIST "playlist" omitted. It is at the = same level as CONTAINER "library" and "player" are. So I was thinking it wi= ll be part of depth=3D2 output for the example module that is being used in= the draft. GET /restconf/config/example-jukebox:jukebox?depth=3D2 { "example-jukebox:jukebox" : { "library" : [null], "playlist": [null], <<=3D=3D Missing in your example for depth=3D2 "player" : [null] } } Not based on the starting point (no depth parameter given). I will add 1 or 2 playlists in the draft example. Thanks ~Upendra Andy From: Andy Bierman > Date: Friday, December 13, 2013 9:28 AM To: Cisco Employee > Cc: "netconf@ietf.org" > Subject: Re: [Netconf] RESTCONF depth parameter On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput (uprajput) > wrote: Hi, I was looking at the "depth" parameter example in RESTCONF draft version 2 = in section 3.8.1. There they have an example that will retrieve 2 levels of= configuration data nodes from "example-jukebox" module. And the result of = retrieval is shown as: { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } This example is wrong and needs to be fixed. The depth parameter is affected by the decision to make all YANG nodes be resources instead of just containers and lists. The example did not get updated to adjust for this change. The example will be clarified so the starting data is shown, so it is clear what is begin filtered by the depth parameter: GET /restconf/config/example-jukebox:jukebox { "example-jukebox:jukebox" : { "library" : { "artist" : { "name" : "Foo Fighters" } }, "player" : { "gap" : 0.5 } } } GET /restconf/config/example-jukebox:jukebox?depth=3D1 { "example-jukebox:jukebox" : [null] } GET /restconf/config/example-jukebox:jukebox?depth=3D2 { "example-jukebox:jukebox" : { "library" : [null], "player" : [null] } } GET /restconf/config/example-jukebox:jukebox?depth=3D3 { "example-jukebox:jukebox" : { "library" : { "artist" : [null] }, "player" : { "gap" : 0.5 } } } My question is since both containers and lists are defined as resources the= n why "list playlist" is not included in the result shown above ? Will an error be returned when level is less then 1 ? yes Also I will appreciate if you can provide sample of what will be returned w= hen depth is 1 and 3. Thanks ~Upendra Andy --_000_CED091A33710Cuprajputciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Thank you Andy.

From: Andy Bierman <andy@yumaworks.com>
Date: Friday, December 13, 2013 10:= 04 AM
To: Cisco Employee <uprajput@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dep= th parameter




On Fri, Dec 13, 2013 at 9:47 AM, Upendra Rajput = (uprajput) <uprajput@cisco.com> wrote:
Thanks Andy.

In your example for depth=3D2= why is LIST "playlist" omitted. It is at the same level as CONTA= INER "library" and "player" are. So I was thinking it w= ill be part of depth=3D2 output for the example module that is being used in the draft.
GET /restconf/config/example-=
jukebox:jukebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
    "playlist": [null],   <=
;<=3D=3D Missing in your example for depth=3D2
          "player" =
: [null]
        }
      }


Not based on the starting point (no depth parameter given).
I will add 1 or 2 playlists in the draft example.

 
Thanks
~Upendra



Andy

 

From: Andy Bierman <andy@yumaworks.com>
Date: Friday, December 13, 2013 9:2= 8 AM
To: Cisco Employee <uprajput@cisco.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
Subject: Re: [Netconf] RESTCONF dep= th parameter




On Thu, Dec 12, 2013 at 2:18 PM, Upendra Rajput = (uprajput) <uprajput@cisco.com> wrote:
Hi,

I was looking at the "depth" parameter example in RESTCONF d= raft version 2 in section 3.8.1. There they have an example that will retri= eve 2 levels of configuration data nodes from "example-jukebox" m= odule. And the result of retrieval is shown as:
      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }




This example is wrong and needs to be fixed.
The depth parameter is affected by the decision to make
all YANG nodes be resources instead of just containers and lists.
The example did not get updated to adjust for this change.

The example will be clarified so the starting data is shown, so it is<= /div>
clear what is begin filtered by the depth parameter:

GET /restconf/config/example-jukebox:jukebox<=
/pre>

      {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : {
              "name" : "Foo Fighters"
            }
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }
GET /restconf/config/example-jukebox:jukebox?=
depth=3D1
     {
        "example-jukebox:jukebox" : [null]
     }

GET /restconf/config/example-jukebox:juk=
ebox?depth=3D2
     {
        "example-jukebox:jukebox" : {
          "library" : [null],
          "player" : [null]
        }
      }

GET /restconf/config/example-jukebox:jukeb=
ox?depth=3D3
     {
        "example-jukebox:jukebox" : {
          "library" : {
            "artist" : [null]
          },
          "player" : {
            "gap" : 0.5
          }
        }
      }

 
My question is since both containers and lists are defined as r= esources then why "list playlist" is not included in the result shown above = ? 

Will an error be returned when level is less then 1 ?


yes 
 
Also I will appreciate if you can provide sample of what will be retur= ned when depth is 1 and 3.


Thanks
~Upendra



Andy
 

 --_000_CED091A33710Cuprajputciscocom_-- From randy_presuhn@mindspring.com Fri Dec 13 11:20:59 2013 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 AF7551AE3D7 for ; Fri, 13 Dec 2013 11:20: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 lOgzInNMIxW9 for ; Fri, 13 Dec 2013 11:20:57 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8A1AE3CC for ; Fri, 13 Dec 2013 11:20:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=l3NXX0tJNNOFs14iiJvvA8y78uw3P6RABKJEWyWe/fGi7Yb6q+Lz/Yz+JRZB1PeJ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrYI6-0000PS-Fm for netconf@ietf.org; Fri, 13 Dec 2013 14:20:50 -0500 Received: from 76.254.55.132 by webmail.earthlink.net with HTTP; Fri, 13 Dec 2013 14:20:50 -0500 Message-ID: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 13 Dec 2013 11:20:50 -0800 (GMT-08:00) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb18db9fd85cb45f8253aa313003d03a31350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 X-Mailman-Approved-At: Fri, 13 Dec 2013 13:10:55 -0800 Subject: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:21:00 -0000 Hi - *If* this is approved (some issues have been raised on the IETF list) are there any plans to make use of this for netconf? Randy -----Forwarded Message----- >From: The IESG >Sent: Dec 13, 2013 9:16 AM >To: IETF-Announce >Cc: tls@ietf.org >Subject: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard > > >The IESG has received a request from the Transport Layer Security WG >(tls) to consider the following document: >- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation > Extension' > as Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2013-12-27. Exceptionally, comments may be >sent to iesg@ietf.org instead. In either case, please retain the >beginning of the Subject line to allow automated sorting. > >Abstract > > > This document describes a Transport Layer Security (TLS) extension > for application layer protocol negotiation within the TLS handshake. > For instances in which the TLS connection is established over a well > known TCP/IP port not associated with the desired application layer > protocol, this extension allows the application layer to negotiate > which protocol will be used within the TLS session. > > > > >The file can be obtained via >http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ > >IESG discussion can be tracked via >http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ballot/ > > >No IPR declarations have been submitted directly on this I-D. > > From mbadra@gmail.com Fri Dec 13 14:25:05 2013 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 5B9E11ADFD6 for ; Fri, 13 Dec 2013 14:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 gPHzM941uX-f for ; Fri, 13 Dec 2013 14:25:03 -0800 (PST) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E7F741ADFC9 for ; Fri, 13 Dec 2013 14:25:02 -0800 (PST) Received: by mail-vc0-f177.google.com with SMTP id hq11so1715337vcb.8 for ; Fri, 13 Dec 2013 14:24:56 -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=FdW6Z0FAa5DbfwTybIEp1CK/8MCZa13Qjqpv3njS1wo=; b=Ch2MuB4GFBcBCSpTIKhfMc2fzY2dYwRvB2kfK/+neoRmsZohosmb3ICn9d/czJE0zE 5jsgVporTHUpd6eiiRyqqWH0sFG+H4ufVdPT5gXq83mtq0mCMe1vcYfKE9tJYpoGPaD3 yoxAoJVu5++7ZNImoF0DpBkJPQq0FozzO9PpZB82x9hgFc9XWcjJTYW1W/obogyVHJLa jJZt5hKaFdyzqVZOQDsHio1nRYMXv5oH4uABO0QBCGLVvktPVzKtl5NiocTMtYI9pC6n PU22VYthAgOuySjbTt4mBVbZH9N8VPMf0SzXff/0q3Fe/gqqjeIvIQ3W5L0l5DmS3948 PKtQ== MIME-Version: 1.0 X-Received: by 10.58.208.130 with SMTP id me2mr2239446vec.13.1386973496378; Fri, 13 Dec 2013 14:24:56 -0800 (PST) Received: by 10.220.165.132 with HTTP; Fri, 13 Dec 2013 14:24:56 -0800 (PST) In-Reply-To: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 02:24:56 +0400 Message-ID: From: Mohamad Badra To: Randy Presuhn Content-Type: multipart/alternative; boundary=047d7bdc192c908ee604ed71ee39 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 13 Dec 2013 22:25:05 -0000 --047d7bdc192c908ee604ed71ee39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 13, 2013 at 11:20 PM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > Hi - > > *If* this is approved (some issues have been raised on > the IETF list) are there any plans to make use of this > for netconf? > > Randy > NETCONF dosn't have the issue of version negotiation as with the case of HTTP1&2, so how can this document be useful for this WG? Best regards Badra=E2=80=8B=E2=80=8B --047d7bdc192c908ee604ed71ee39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 13, 2013 = at 11:20 PM, Randy Presuhn <= randy_presuhn@mindspring.com> wrote:
Hi -

*If* this is approved (some issues have been raised on
the IETF list) are there any plans to make use of this
for netconf?

Randy


NETCONF dosn't have the issue o= f version negotiation as with the case of HTTP1&2, so how can this docu= ment be useful for this WG?

Be= st regards
Badra=E2=80=8B=E2=80= =8B
--047d7bdc192c908ee604ed71ee39-- From randy_presuhn@mindspring.com Fri Dec 13 14:52:27 2013 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 AD9F21AE005 for ; Fri, 13 Dec 2013 14:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 eYC9UluxvTtv for ; Fri, 13 Dec 2013 14:52:26 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4E01ADF58 for ; Fri, 13 Dec 2013 14:52:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LGQDQ7d1m2JoEcaRMNF4XgOSSQ/5e86UPMYKSF7qXQGCrUXHnVyUj71KrrIXGIvG; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.237.104] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vrbak-0006Q3-Dl for netconf@ietf.org; Fri, 13 Dec 2013 17:52:18 -0500 Message-ID: <000701cef856$32718760$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 13 Dec 2013 14:53:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbff7a1117e45a844abfc2c7c0920db504350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.104 Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 13 Dec 2013 22:52:27 -0000 Hi - > From: "Mohamad Badra" > To: "Randy Presuhn" > Cc: > Sent: Friday, December 13, 2013 2:24 PM > Subject: Re: [Netconf] Fw: Last Call: (Transport > Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard ... > NETCONF dosn't have the issue of version negotiation as with the case of > HTTP1&2, so how can this document be useful for this WG? Abstract claims: For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. Seems directly applicable to 5539bis, reducing or possibly eliminating the need for a separate port. Randy From mbadra@gmail.com Fri Dec 13 15:08:16 2013 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 8E7FE1AE449 for ; Fri, 13 Dec 2013 15:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 wP4GJGHJPiSt for ; Fri, 13 Dec 2013 15:08:15 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D46171AE448 for ; Fri, 13 Dec 2013 15:08:14 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id w20so1718173vbb.5 for ; Fri, 13 Dec 2013 15:08:08 -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=nC87P1gYAwF4NGmheUbj+v6Cj6zTvE4SnA8MnECofpQ=; b=yzZ40I7uHM27TDKtUS2Tqz3+YeFkvg+DW90dkq7zh7Q1VxU3XwV7lVyk8OXIXRzU9v CTX2Ob2ZT8KcTauT+dnP74Awt/YmbrbcvK+IUPRWcPOCf4Qyo7kG0lCnKojB/OWpLLlr hZwKYimHapYJT5twUuZkwHFepRQ/7wgW6W+LsxEo8IdfGHNqwhSCF/lT2ZqfDfvBK0Bg r/STddZT5gN9YCGO6pPWTVLt8ygtgRUBIxjK9pyHz2nxFCSAZjvrmpXjLSxcRCrBrelB sVZlxMzgsif0HoF+v9p0rwMb5fTiWtOV9bzQhme9mkeJSJzgyBjUkkhfepVGfEv5MnWI 5N6A== MIME-Version: 1.0 X-Received: by 10.58.168.205 with SMTP id zy13mr2226437veb.19.1386976088251; Fri, 13 Dec 2013 15:08:08 -0800 (PST) Received: by 10.220.165.132 with HTTP; Fri, 13 Dec 2013 15:08:08 -0800 (PST) In-Reply-To: <000701cef856$32718760$6b01a8c0@oemcomputer> References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <000701cef856$32718760$6b01a8c0@oemcomputer> Date: Sat, 14 Dec 2013 03:08:08 +0400 Message-ID: From: Mohamad Badra To: Randy Presuhn Content-Type: multipart/alternative; boundary=047d7b6dc2240d655404ed728932 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 13 Dec 2013 23:08:16 -0000 --047d7b6dc2240d655404ed728932 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2013 at 2:53 AM, Randy Presuhn wrote: > Hi - > > > From: "Mohamad Badra" > > To: "Randy Presuhn" > > Cc: > > Sent: Friday, December 13, 2013 2:24 PM > > Subject: Re: [Netconf] Fw: Last Call: > (Transport > Layer Security (TLS= ) > Application Layer > Protocol Negotiation Extension) to Proposed Standard > ... > > NETCONF dosn't have the issue of version negotiation as with the case o= f > > HTTP1&2, so how can this document be useful for this WG? > > Abstract claims: > For instances in which the TLS connection is established over a well > known TCP/IP port not associated with the desired application layer > protocol, this extension allows the application layer to negotiate > which protocol will be used within the TLS session. > > Seems directly applicable to 5539bis, reducing or possibly eliminating > the need for a separate port. =E2=80=8BBut there is already a port assigned for NETCONF over TLS since ye= ars. =E2=80=8BBest regards Badra=E2=80=8B --047d7b6dc2240d655404ed728932 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 14, 2013 = at 2:53 AM, Randy Presuhn <r= andy_presuhn@mindspring.com> wrote:
Hi -

> From: "Mohamad Badra" <mbadra@gmail.com>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <netconf@ietf.org> > Sent: Friday, December 13, 2013 2:24 PM
> Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-tls-applayerproto= neg-03.txt> (Transport > Layer Security (TLS) Application Layer
Protocol Negotiation Extension) to Proposed Standard
...
> NETCONF dosn't have the issue of version negotia= tion as with the case of
> HTTP1&2, so how can this document be useful for this WG?

Abstract claims:
=C2=A0 =C2=A0For instances in which the TLS connection is= established over a well
=C2=A0 =C2=A0known TCP/IP port not associated with the desired application = layer
=C2=A0 =C2=A0protocol, this extension allows the application layer to negot= iate
=C2=A0 =C2=A0which protocol will be used within the TLS session.

Seems directly applicable to 5539bis, reducing or possibly eliminatin= g
the need for a separate port.
=C2=A0

<= div>
=E2=80=8BBut there is already a port assigned for NETCONF over TLS s= ince years.

=E2=80=8BBest regards
Badra=E2=80=8B

--047d7b6dc2240d655404ed728932-- From randy_presuhn@mindspring.com Sat Dec 14 01:06:06 2013 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 0B6F41ADF84 for ; Sat, 14 Dec 2013 01:06:06 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 LKx1q6UYWB3u for ; Sat, 14 Dec 2013 01:05:34 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id BF3091AE11E for ; Sat, 14 Dec 2013 01:03:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=D/0eC0Di3O0h9j1WDfRoyWA89lLCUm2JP7BHcdwY6V1Ot3wOqtjUAot7Ez05dGjV; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vrl8D-0002pc-OC; Sat, 14 Dec 2013 04:03:29 -0500 Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Sat, 14 Dec 2013 04:03:29 -0500 Message-ID: <11835102.1387011809496.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 01:03:29 -0800 (GMT-08:00) From: Randy Presuhn To: Mohamad Badra Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbdceac24c9d7df2fd9f7733360a5935ad350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 09:06:06 -0000 Hi - >From: Mohamad Badra >Sent: Dec 13, 2013 3:08 PM >To: Randy Presuhn >Cc: "netconf@ietf.org" >Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation= Extension) to Proposed Standard ... >> Seems directly applicable to 5539bis, reducing or possibly eliminating >> the need for a separate port. > > > >=E2=80=8BBut there is already a port assigned for NETCONF over TLS since y= ears. By using a single port for multiple types of (encrypted) traffic, traffic analysis attacks, such as those associated with pervasive monitoring, may be made somewhat more difficult. Randy From mbadra@gmail.com Sat Dec 14 02:51:30 2013 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 30E901ADF51 for ; Sat, 14 Dec 2013 02:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 GHXR2ljGUIra for ; Sat, 14 Dec 2013 02:51:13 -0800 (PST) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3BA31ACCE8 for ; Sat, 14 Dec 2013 02:51:12 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id jw12so2137742veb.3 for ; Sat, 14 Dec 2013 02:51: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=5CLoJbsrsb34QO2MEIThYl/S/JRKTYMNbgOLDidzepU=; b=G0mN2txtrBZqxFDFaGKBqCMpUKjupd8RlwhfwaTaGPskU/lqbAFEe4Ho7EGziQ7JEH FyWLRj4FY85Vvcd7drVIM7C5JwFMWebrm+icyFjZVxc6qd2M98B9iFyLeEWtrHBTlmfP XfDoO5bfMHuhuSguMNg3lmE0RI6goxCxlMWL13jn7URJsPVHgQRlyyzF0wGWHsDdEryg hTG1rWZvs+rcVZT9wWtHmdw+nHdEbUQrfOP4agNZw52GuT0B7n0JWrZHLLNYt4+AA6S7 JJVx0QZsZiQpzRSnJiQNiVHtHGQOpordLiBpWnGHVDc7cgjDP0yvqydxGkJz4w45ma2p 8phw== MIME-Version: 1.0 X-Received: by 10.220.124.68 with SMTP id t4mr228024vcr.52.1387018266201; Sat, 14 Dec 2013 02:51:06 -0800 (PST) Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 02:51:06 -0800 (PST) In-Reply-To: <11835102.1387011809496.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> References: <11835102.1387011809496.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 14:51:06 +0400 Message-ID: From: Mohamad Badra To: Randy Presuhn Content-Type: multipart/alternative; boundary=089e013a29080dd3fe04ed7c5b1b Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 10:51:34 -0000 --089e013a29080dd3fe04ed7c5b1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2013 at 1:03 PM, Randy Presuhn wrote: > Hi - > > >From: Mohamad Badra > >Sent: Dec 13, 2013 3:08 PM > >To: Randy Presuhn > >Cc: "netconf@ietf.org" > >Subject: Re: [Netconf] Fw: Last Call: > (Transport Layer Security (TLS) > Application Layer Protocol Negotiation Extension) to Proposed Standard > ... > >> Seems directly applicable to 5539bis, reducing or possibly eliminating > >> the need for a separate port. > > > > > > > >=E2=80=8BBut there is already a port assigned for NETCONF over TLS since= years. > > By using a single port for multiple types of (encrypted) > traffic, traffic analysis attacks, such as those associated > with pervasive monitoring, may be made somewhat more difficult. This is currently not provided by the draft. The client sends a list of applications type in a TLS extension and the server selects ONLY one from the list. Moreover, the negotiation of application types is achieved in clear text and available for traffic analysis and monitoring. It is true that multiple type of traffic could be negotiated (in clear text) but only one type will use the TLS session. Best regards, Badra=E2=80=8B=E2=80=8B --089e013a29080dd3fe04ed7c5b1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 14, 2013 = at 1:03 PM, Randy Presuhn <r= andy_presuhn@mindspring.com> wrote:
Hi -

>From: Mohamad Badra <mbadra@gmai= l.com>
>Sent: Dec 13, 2013 3:08 PM
>To: Randy Presuhn <r= andy_presuhn@mindspring.com>
>Cc: "netconf@ietf.org"= ; <netconf@ietf.org>
>Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-= tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application= Layer Protocol Negotiation Extension) to Proposed Standard
...
>> Seems directly applicable to 5539bis, redu= cing or possibly eliminating
>> the need for a separate port.
>
>
>
>=E2=80=8BBut there is already a port assigned for NETCONF over TLS sinc= e years.

By using a single port for multiple types of (encrypted)
traffic, traffic analysis attacks, such as those associated
with pervasive monitoring, may be made somewhat more difficult.


This is currently not provided by the dra= ft. The client sends a list of applications type in a TLS extension and the= server selects ONLY one from the list. Moreover, the negotiation of applic= ation types is achieved in clear text and available for traffic analysis an= d monitoring.

It is true that multiple type of traffic could be negotiate= d (in clear text) but only one type will use the TLS session.

Best regards,
Badra=E2=80=8B=E2=80=8B
--089e013a29080dd3fe04ed7c5b1b-- From j.schoenwaelder@jacobs-university.de Sat Dec 14 08:08:22 2013 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 C16F91AE1FB for ; Sat, 14 Dec 2013 08:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 6hsjEQd0dbgY for ; Sat, 14 Dec 2013 08:08:16 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 22AE61AE1F8 for ; Sat, 14 Dec 2013 08:08:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A30A2006B; Sat, 14 Dec 2013 17:08:09 +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 bSfU1vNjqMJd; Sat, 14 Dec 2013 17:08:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FE1E2006A; Sat, 14 Dec 2013 17:08:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3612E2A0038A; Sat, 14 Dec 2013 17:08:04 +0100 (CET) Date: Sat, 14 Dec 2013 17:08:04 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20131214160804.GA87076@elstar.local> Mail-Followup-To: Randy Presuhn , netconf@ietf.org References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <000701cef856$32718760$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000701cef856$32718760$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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: Sat, 14 Dec 2013 16:08:23 -0000 X-List-Received-Date: Sat, 14 Dec 2013 16:08:23 -0000 On Fri, Dec 13, 2013 at 02:53:50PM -0800, Randy Presuhn wrote: > Hi - > > > From: "Mohamad Badra" > > To: "Randy Presuhn" > > Cc: > > Sent: Friday, December 13, 2013 2:24 PM > > Subject: Re: [Netconf] Fw: Last Call: (Transport > Layer Security (TLS) Application Layer > Protocol Negotiation Extension) to Proposed Standard > ... > > NETCONF dosn't have the issue of version negotiation as with the case of > > HTTP1&2, so how can this document be useful for this WG? > > Abstract claims: > For instances in which the TLS connection is established over a well > known TCP/IP port not associated with the desired application layer > protocol, this extension allows the application layer to negotiate > which protocol will be used within the TLS session. > > Seems directly applicable to 5539bis, reducing or possibly eliminating > the need for a separate port. At the next to last IETF, we got input from security folks that swapping roles after the secure channel has been established is not a good idea. I assume this document does the negotiation after the security work, hence this would have the same issues, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbadra@gmail.com Sat Dec 14 10:30:39 2013 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 531A61ADF7E for ; Sat, 14 Dec 2013 10:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 OeTL4CwUAb-q for ; Sat, 14 Dec 2013 10:30:29 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F20CA1AE26C for ; Sat, 14 Dec 2013 10:29:43 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id jx11so2252738veb.6 for ; Sat, 14 Dec 2013 10:29:37 -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 :content-type; bh=e+4M39boOrAA6Exngw2fqNLvfR+vsIFpiaIMFHp2TAI=; b=0EyjiFlfqUff66FAHsqqVs+IWTrpADzPJhS87sfgFDOFV4xiuc2tgPN9b4Zi3N+E8C NLVA+1Vo4HNmu1yQZ+VjiKfAtbeA5wYmOeDvX4RW/taCw/jB3yoa1W1E4O3KxJrFJG+O tM64KitfsSr0uUhvQZivF3SOXIkcKEEwRroGON5ZsF33dsuxLd52+xrldcrsVEBAq668 UMtd3Fw1YHFDHLU6yHsm/6rKJ71qvmiKp56bg4B6KNzSH5vWnxENQFcsXK6Gp+iWlMKi yS1krRDwj4q1oPkZIg4W998P/CnzBTOFP0vXH163v/J31fzMUNsrO9ZQhDCLevkan4+X t3Tg== MIME-Version: 1.0 X-Received: by 10.58.181.165 with SMTP id dx5mr66033vec.52.1387045777057; Sat, 14 Dec 2013 10:29:37 -0800 (PST) Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 10:29:36 -0800 (PST) In-Reply-To: <20131214160804.GA87076@elstar.local> References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <000701cef856$32718760$6b01a8c0@oemcomputer> <20131214160804.GA87076@elstar.local> Date: Sat, 14 Dec 2013 22:29:36 +0400 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Randy Presuhn , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=047d7b673c86d42cd604ed82c257 Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 18:30:39 -0000 --047d7b673c86d42cd604ed82c257 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2013 at 8:08 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Dec 13, 2013 at 02:53:50PM -0800, Randy Presuhn wrote: > > Hi - > > > > > From: "Mohamad Badra" > > > To: "Randy Presuhn" > > > Cc: > > > Sent: Friday, December 13, 2013 2:24 PM > > > Subject: Re: [Netconf] Fw: Last Call: > (Transport > Layer Security (TLS= ) > Application Layer > > Protocol Negotiation Extension) to Proposed Standard > > ... > > > NETCONF dosn't have the issue of version negotiation as with the case > of > > > HTTP1&2, so how can this document be useful for this WG? > > > > Abstract claims: > > For instances in which the TLS connection is established over a well > > known TCP/IP port not associated with the desired application layer > > protocol, this extension allows the application layer to negotiate > > which protocol will be used within the TLS session. > > > > Seems directly applicable to 5539bis, reducing or possibly eliminating > > the need for a separate port. > > At the next to last IETF, we got input from security folks that > swapping roles after the secure channel has been established is not a > good idea. Sometimes security folks say anything :) =E2=80=8B=E2=80=8B > I assume this document does the negotiation after the > security work, hence this would have the same issues, no? > The negotiation is done during the TLS handshake, not after the secure channel has been established! =E2=80=8B=E2=80=8B =E2=80=8BBest regards, Badra=E2=80=8B --047d7b673c86d42cd604ed82c257 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 14, 2013 = at 8:08 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Dec 13, 2013 at 02:53:50PM -0800,= Randy Presuhn wrote:
> Hi -
>
> > From: "Mohamad Badra" <mbadra@gmail.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> > Cc: <netconf@ietf.org&= gt;
> > Sent: Friday, December 13, 2013 2:24 PM
> > Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-tls-applayer= protoneg-03.txt> (Transport > Layer Security (TLS) Application Layer<= br> > Protocol Negotiation Extension) to Proposed Standard
> ...
> > NETCONF dosn't have the issue of version negotiation as with = the case of
> > HTTP1&2, so how can this document be useful for this WG?
>
> Abstract claims:
> =C2=A0 =C2=A0For instances in which the TLS connection is established = over a well
> =C2=A0 =C2=A0known TCP/IP port not associated with the desired applica= tion layer
> =C2=A0 =C2=A0protocol, this extension allows the application layer to = negotiate
> =C2=A0 =C2=A0which protocol will be used within the TLS session.
>
> Seems directly applicable to 5539bis, reducing or possibly eliminating=
> the need for a separate port.

At the next to last IETF, we got input from security folks that
swapping roles after the secure channel has been established is not a
good idea.


Sometimes security= folks say anything :)

=E2=80=8B=E2=80=8B
I assum= e this document does the negotiation after the
security work, hence this would have the same issues, no?
<= div>=C2=A0

The negotiation is done during the TLS ha= ndshake, not after the secure channel has been established!
=E2=80=8B=E2=80=8B
=E2=80=8BBest regards,
Badra=E2=80=8B
--047d7b673c86d42cd604ed82c257-- From j.schoenwaelder@jacobs-university.de Sat Dec 14 11:05:23 2013 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 77DAE1AE27F for ; Sat, 14 Dec 2013 11:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 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.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 2CiuqBk9KbrY for ; Sat, 14 Dec 2013 11:05:16 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 07ED31ADBCB for ; Sat, 14 Dec 2013 11:05:16 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E88CF20067; Sat, 14 Dec 2013 20:05:08 +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 US1ZN_VtnhZ6; Sat, 14 Dec 2013 20:05: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 2542020064; Sat, 14 Dec 2013 20:05:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4F1722A00776; Sat, 14 Dec 2013 20:05:03 +0100 (CET) Date: Sat, 14 Dec 2013 20:05:03 +0100 From: Juergen Schoenwaelder To: Mohamad Badra Message-ID: <20131214190502.GA87542@elstar.local> Mail-Followup-To: Mohamad Badra , Randy Presuhn , "netconf@ietf.org" References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <000701cef856$32718760$6b01a8c0@oemcomputer> <20131214160804.GA87076@elstar.local> 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: Randy Presuhn , "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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: Sat, 14 Dec 2013 19:05:23 -0000 On Sat, Dec 14, 2013 at 10:29:36PM +0400, Mohamad Badra wrote: > > Sometimes security folks say anything :) > I can't tell but they did point out that client/server certificates can have very different properties. > The negotiation is done during the TLS handshake, not after the secure > channel has been established! Yep, so I took a quick look at the I-D. This allows everybody to read which protocol is negotiated - not sure everybody will like this (but won't matter here). I am not sure about the port number - we would change the client/server role and I still believe assuming a management system's call home port is different form the port used by the netconf server on the management system - these might be very different products and assuming they will be easy to configure to share a port may not necessarily be true. That said, are there any implementations of this ALPNE thing to play with? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Sat Dec 14 11:33:37 2013 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 E15011AE19C for ; Sat, 14 Dec 2013 11:33:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 hg_879iqSbgU for ; Sat, 14 Dec 2013 11:33:31 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 40A3F1AE142 for ; Sat, 14 Dec 2013 11:33:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=qZ19LzTnFxh8MfYFnJA5rRYoNBxdjiwriCIHFu+eln47mPVUzrfkEkk2npNr69H6; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vruxm-00064R-K4; Sat, 14 Dec 2013 14:33:22 -0500 Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Sat, 14 Dec 2013 14:33:22 -0500 Message-ID: <20254621.1387049602584.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 11:33:22 -0800 (GMT-08:00) From: Randy Presuhn To: Juergen Schoenwaelder Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edbfaaefd5102fafd8e43fd797f61c216f8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Cc: netconf@ietf.org Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 19:33:37 -0000 Hi - >From: Juergen Schoenwaelder >Sent: Dec 14, 2013 8:08 AM >To: Randy Presuhn >Cc: netconf@ietf.org >Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard > >On Fri, Dec 13, 2013 at 02:53:50PM -0800, Randy Presuhn wrote: >> Hi - >> >> > From: "Mohamad Badra" >> > To: "Randy Presuhn" >> > Cc: >> > Sent: Friday, December 13, 2013 2:24 PM >> > Subject: Re: [Netconf] Fw: Last Call: (Transport > Layer Security (TLS) Application Layer >> Protocol Negotiation Extension) to Proposed Standard >> ... >> > NETCONF dosn't have the issue of version negotiation as with the case of >> > HTTP1&2, so how can this document be useful for this WG? >> >> Abstract claims: >> For instances in which the TLS connection is established over a well >> known TCP/IP port not associated with the desired application layer >> protocol, this extension allows the application layer to negotiate >> which protocol will be used within the TLS session. >> >> Seems directly applicable to 5539bis, reducing or possibly eliminating >> the need for a separate port. > >At the next to last IETF, we got input from security folks that >swapping roles after the secure channel has been established is not a >good idea. I assume this document does the negotiation after the >security work, hence this would have the same issues, no? The client requests the protocol in the clear, before the key exchange. Randy From randy_presuhn@mindspring.com Sat Dec 14 11:49:59 2013 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 9CAD21AE2A8 for ; Sat, 14 Dec 2013 11:49: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, RCVD_IN_DNSWL_NONE=-0.0001] 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 CmOjNJoCz_8i for ; Sat, 14 Dec 2013 11:49:52 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDF41AE07E for ; Sat, 14 Dec 2013 11:49:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZdChSZAhdgy/HNU8aBh/f6hH+2enzp7UZ+/gMpOgJH4qa3zTdCeIlvu5zF/LOHvQ; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrvDd-0005Tr-DR for netconf@ietf.org; Sat, 14 Dec 2013 14:49:45 -0500 Received: from 76.254.54.154 by webmail.earthlink.net with HTTP; Sat, 14 Dec 2013 14:49:45 -0500 Message-ID: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 14:49:45 -0500 (EST) From: Randy Presuhn To: netconf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb73711576058c9be24d76cabd7b8ac76e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 19:50:05 -0000 Hi - >From: Mohamad Badra >Sent: Dec 14, 2013 2:51 AM >To: Randy Presuhn >Cc: "netconf@ietf.org" >Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard ... >> By using a single port for multiple types of (encrypted) >> traffic, traffic analysis attacks, such as those associated >> with pervasive monitoring, may be made somewhat more difficult. > > > >This is currently not provided by the draft. The client sends a list of >applications type in a TLS extension and the server selects ONLY one from >the list. Moreover, the negotiation of application types is achieved in >clear text and available for traffic analysis and monitoring. Thus the "somewhat". However, it does require the attacker to intercept and record connection requests and maintain that state information, rather than just tracking IP destination port numbers. This makes traffic analysis from bulk monitoring *somewhat* more expensive and annoying. >It is true that multiple type of traffic could be negotiated (in clear >text) but only one type will use the TLS session. Think *pervasive* monitoring over the set of *all* sessions involving that port, not just a single one that happens to carry management traffic. Is this an ideal tool? Clearly not, but since it is intended to address a problem very similar to one that has troubled this WG, we need to consider whether it's up to the job. Randy From mbadra@gmail.com Sat Dec 14 12:23:14 2013 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 9C30B1A1EF9 for ; Sat, 14 Dec 2013 12:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 TXqprabkIFl0 for ; Sat, 14 Dec 2013 12:23:11 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2303B1A1DBD for ; Sat, 14 Dec 2013 12:20:25 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so2184823vcb.5 for ; Sat, 14 Dec 2013 12:20: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 :content-type; bh=vpxAg9XUSxolIyro3vSOcg+UMIahH8cGUA/CYM9E8WE=; b=rCwkMARr/drnzwwrJZjNK84ELARM9bHD5odeSY2TbXfOps83zpxKlV8NZg39H/wDoq jlWBLfA/P0DExjNzgM0dQkXtcpMDSfmp3rwUnjGYcrRBMo/VhRR/DuxaJW/90y9cJ71I w/tnYePkMvvgMB79oiCtXXNxMrOzwI53jA3BbbSy2qJIHDSA/V+zcKoJcwdPMAko0DcG 8rbJK52dvZqaAjNjF9EJKEqxQzyfWMi3cn6qNukhwNONbVoeTgblE5nOvPV6Wsuwlo2s qK0V2h5dhUTdp0QRc6d/ftj+OnrfiyRGS8mFY8u6Cj9NDp2VRBkwcrCL7/HAJqoGCV5Q rvNQ== MIME-Version: 1.0 X-Received: by 10.52.240.201 with SMTP id wc9mr172477vdc.60.1387052418155; Sat, 14 Dec 2013 12:20:18 -0800 (PST) Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 12:20:18 -0800 (PST) In-Reply-To: <20131214190502.GA87542@elstar.local> References: <24706270.1386962450258.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <000701cef856$32718760$6b01a8c0@oemcomputer> <20131214160804.GA87076@elstar.local> <20131214190502.GA87542@elstar.local> Date: Sun, 15 Dec 2013 00:20:18 +0400 Message-ID: From: Mohamad Badra To: Juergen Schoenwaelder , Mohamad Badra , Randy Presuhn , "netconf@ietf.org" Content-Type: multipart/alternative; boundary=20cf307ca518ab489104ed844e90 Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 20:23:15 -0000 --20cf307ca518ab489104ed844e90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2013 at 11:05 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Sat, Dec 14, 2013 at 10:29:36PM +0400, Mohamad Badra wrote: > > > > > Sometimes security folks say anything :) > > > > I can't tell but they did point out that client/server certificates can > have very different properties. > > > The negotiation is done during the TLS handshake, not after the secure > > channel has been established! > > Yep, so I took a quick look at the I-D. This allows everybody to read > which protocol is negotiated - not sure everybody will like this (but > won't matter here). I am not sure about the port number - we would > change the client/server role and I still believe assuming a > management system's call home port is different form the port used by > the netconf server on the management system - these might be very > different products and assuming they will be easy to configure to > share a port may not necessarily be true. > > That said, are there any implementations of this ALPNE thing to play > with? MS Open Tech has contributed an open-source reference implementation of ALPN. Available as OpenSSL, Apache and mod_spdy patches: http://html5labs.interopbridges.com/prototypes/alpn/alpn/info Reference: http://www.ietf.org/proceedings/86/slides/slides-86-tls-1.pptx Best regards Badra=E2=80=8B=E2=80=8B --20cf307ca518ab489104ed844e90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 14, 2013 = at 11:05 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Dec 14, 2013 at 10:29:36PM +0400, Mohamad Badra wrote:

>
> Sometimes security folks say anything :)
>

I can't tell but they did point out that client/server certificat= es can
have very different properties.

> The negotiation is done during the TLS handshake, not after the secure=
> channel has been established!

Yep, so I took a quick look at the I-D. This allows everybody to read=
which protocol is negotiated - not sure everybody will like this (but
won't matter here). I am not sure about the port number - we would
change the client/server role and I still believe assuming a
management system's call home port is different form the port used by the netconf server on the management system - these might be very
different products and assuming they will be easy to configure to
share a port may not necessarily be true.

That said, are there any implementations of this ALPNE thing to play
with?

MS Open Tech has contributed an open-source = reference implementation of ALPN.
= Available as OpenSSL, Apache an= d mod_spdy patches:
htt= p://html5labs.interopbridges.com/prototypes/alpn/alpn/info
=

Reference:=C2=A0= = http://www.ietf.org/proceedings/86/slides/slides-86-tls-1.pptx

Best regards
Badra=E2=80=8B=E2=80=8B
--20cf307ca518ab489104ed844e90-- From mbadra@gmail.com Sat Dec 14 12:30:50 2013 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 293321A1F5B for ; Sat, 14 Dec 2013 12:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 VIHidx9CJd9b for ; Sat, 14 Dec 2013 12:30:31 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D751A1A1F3E for ; Sat, 14 Dec 2013 12:30:30 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id la4so2258073vcb.29 for ; Sat, 14 Dec 2013 12:30:24 -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=b1uaPKPaXLmtNNPg9Ne3gVaGgnBpAMdhU1Nq8ayScHg=; b=vZKDPm3j4eIxOPNExCbpi3dH8bOyBCTQwCotAiPavJh749fwrle74+5DG2sntBTAtn NZMck5//yQ/tUTb4QIYi1SRorFzA1KOWiQL+Yym4n55OAJiuwmt4YFFiAlk8H2OmrHmj dLQ8gxXsKrM3zQ0giHdh1bIet5ZejdbGs+ErB43IDVRCeHB4wHUgPc4mlEUBG3LOGMmb ulVznSksYG2LcYIAdH6jeSTCcMWK7fB7S6vSjiXx3ei3myee/l4C1mNONn++CX5K9LZ6 sH9/GS3qulbY4J++WwO8OQla1eMTnidnw3Dq2ZlX8FhZgeUXcJ3vW0n6EfRrrjXGDX1I BlSQ== MIME-Version: 1.0 X-Received: by 10.58.29.37 with SMTP id g5mr252257veh.38.1387053023940; Sat, 14 Dec 2013 12:30:23 -0800 (PST) Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 12:30:23 -0800 (PST) In-Reply-To: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> References: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Sun, 15 Dec 2013 00:30:23 +0400 Message-ID: From: Mohamad Badra To: Randy Presuhn Content-Type: multipart/alternative; boundary=047d7b6786fec6d6aa04ed8472f8 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 20:30:51 -0000 --047d7b6786fec6d6aa04ed8472f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 14, 2013 at 11:49 PM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > > since it is > intended to address a problem very similar to one that has > troubled this WG, we need to consider whether it's up to > the job. Sorry Randy, what kind of problems you are talking about? Is this related to rfc5539bis? Best regards Badra=E2=80=8B=E2=80=8B --047d7b6786fec6d6aa04ed8472f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 14, 2013 = at 11:49 PM, Randy Presuhn <= randy_presuhn@mindspring.com> wrote:

=C2=A0since it is
intended to address a problem very similar to one that has
troubled this WG, we need to consider whether it's up to
the job.

Sorry Randy, what kind of problems y= ou are talking about? Is this related to rfc5539bis?
Best regards
Badra=E2=80=8B=E2=80=8B
--047d7b6786fec6d6aa04ed8472f8-- From randy_presuhn@mindspring.com Sat Dec 14 12:55:07 2013 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 161121AC4C5 for ; Sat, 14 Dec 2013 12:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 5g3c_RohN0lF for ; Sat, 14 Dec 2013 12:55:01 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 93BB11AC404 for ; Sat, 14 Dec 2013 12:55:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=md185eWtjjT8NUFabq4EEnh65QCsXbheV5l08fOQHTlqmZ+WebAT822VLy4nxnkw; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.154] (helo=oemcomputer) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VrwEf-00041B-JN for netconf@ietf.org; Sat, 14 Dec 2013 15:54:53 -0500 Message-ID: <001701cef90e$f9448a00$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Sat, 14 Dec 2013 12:56:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb1234f667817b47615740e32d896d9ce7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.154 Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 20:55:07 -0000 Hi - > From: "Mohamad Badra" > To: "Randy Presuhn" > Cc: > Sent: Saturday, December 14, 2013 12:30 PM > Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard ... > Sorry Randy, what kind of problems you are talking about? (1) The need to reserve a port. (2) The need to reserve a different port for call home. It clearly addresses (1). As Jurgen indicated, (2) needs some thought. > Is this related to rfc5539bis? Yes. Randy From mbadra@gmail.com Sat Dec 14 13:41:50 2013 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 A3E8B1AD8F7 for ; Sat, 14 Dec 2013 13:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 0PHJF2-yM9JU for ; Sat, 14 Dec 2013 13:41:34 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3651AD8DB for ; Sat, 14 Dec 2013 13:41:34 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ks9so2273133vcb.12 for ; Sat, 14 Dec 2013 13:41:27 -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=KFwOEW7p98F2ij/dtR7GJ1vjGHUNYtfhOoToWJj9ztQ=; b=nWLzbrUgHF+FllDCRK3CPnkToKAeipuG1+/lCnyIDKnsQ1xi/I/Ovl3PHc40fXWv2d LPwY2iMiLEM4D9o4y57OFF2SuREXOrezf3yzc50M8dq53YfMGfjlOR2d6af7HVWitOis Zd1uYjBQI2kX002tyx8da2zJFXBJtGtuzLGz4ZLbc1pGe1NI9qKQpdHT2qMeIGq6AkaE VvjSZPyOxlSy31xTBPT3BOMmKkLc4jVeiNJ9pAAv7rjKnPkp5b7ewm9BYxUvoxWVBlHA 6P9A/2BbjjpB5aeo/cAsiymczY/IrZAfdR1OD8E8l+fkY9B4aONH5gSxkt3KCnWgbCBD 8lOQ== MIME-Version: 1.0 X-Received: by 10.58.178.239 with SMTP id db15mr4876916vec.9.1387057287106; Sat, 14 Dec 2013 13:41:27 -0800 (PST) Received: by 10.220.165.132 with HTTP; Sat, 14 Dec 2013 13:41:27 -0800 (PST) In-Reply-To: <001701cef90e$f9448a00$6b01a8c0@oemcomputer> References: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> <001701cef90e$f9448a00$6b01a8c0@oemcomputer> Date: Sun, 15 Dec 2013 01:41:27 +0400 Message-ID: From: Mohamad Badra To: Randy Presuhn Content-Type: multipart/alternative; boundary=047d7b672a96e1971c04ed857012 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 21:41:51 -0000 --047d7b672a96e1971c04ed857012 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 15, 2013 at 12:56 AM, Randy Presuhn < randy_presuhn@mindspring.com> wrote: > > From: "Mohamad Badra" > > > Sorry Randy, what kind of problems you are talking about? > > (1) The need to reserve a port. > It clearly addresses (1). > It is not clear to me how does the document address the need to reverse a port. AFAIK, the document resolves the issue of not assigning a port number for a service, but negotiating it via a TLS extension. However, I cannot see how this document reverse the role of the client and the server in the context of rfc5539bis =E2=80=8B=E2=80=8B > =E2=80=8B > =E2=80=8B > (2) The need to reserve a different port for call home. =E2=80=8B > As Jurgen indicated, (2) needs some thought. This could be done by using a TLS extension and send the port number in a way similar to FTP pasv command. The client and the server establish a TLS with call_home extension (TBD). When it is sent by the TLS client, the content of the extension contains a port number in which the client will be listening for an incoming TCP connection from the server. Best regards, Badra=E2=80=8B=E2=80=8B --047d7b672a96e1971c04ed857012 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 15, 2013 = at 12:56 AM, Randy Presuhn <= randy_presuhn@mindspring.com> wrote:
> From: "Mohamad Badra" <mbadra@gmail.com>

> Sorry Randy, what kind of problems you are t= alking about?

(1) The need to reserve a port.
It clearly addresses (1).


= It is not clear to me how does the document address the need to reverse a p= ort. AFAIK, the document resolves the issue of not assigning a port number = for a service, but negotiating it via a TLS extension. =C2=A0However, I can= not see how this document reverse the role of the client and the server in = the context of rfc5539bis

=E2=80=8B=E2=80=8B
=E2=80=8B
=E2=80=8B
(2) The n= eed to reserve a different port for call home.
=E2=80=8B
As Jurgen indicated, (2) needs some thought.

This could be done by using a TLS extension and send the por= t number in a way similar to FTP pasv command.
The client and the server establish a TLS with call_home extension= (TBD). When it is sent by the TLS client, the content of the extension con= tains a port number in which the client will be listening=C2=A0for an incoming TCP connection from = the server.

Best regards,
Badra=E2=80=8B=E2=80=8B
--047d7b672a96e1971c04ed857012-- From randy_presuhn@mindspring.com Sat Dec 14 13:50:36 2013 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 C52FF1AD94A for ; Sat, 14 Dec 2013 13:50:36 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 p0Jz75SdqU7C for ; Sat, 14 Dec 2013 13:50:28 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADC1AD948 for ; Sat, 14 Dec 2013 13:50:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=n538F+58xtu3u3XJQS34hlDEJmNpXJ59jpl+V0avj1iCj6QeCVrCtSgDunPyDw9K; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.54.154] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Vrx6H-0001nW-3U; Sat, 14 Dec 2013 16:50:17 -0500 Message-ID: <000b01cef916$b649a700$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: "Mohamad Badra" References: <20557024.1387050585341.JavaMail.root@elwamui-huard.atl.sa.earthlink.net><001701cef90e$f9448a00$6b01a8c0@oemcomputer> Date: Sat, 14 Dec 2013 13:51:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d8889e105617274a0edb578223fa9eb89037c894b56f129af23a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.54.154 Cc: netconf@ietf.org Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard 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, 14 Dec 2013 21:50:37 -0000 Hi - > From: "Mohamad Badra" > To: "Randy Presuhn" > Cc: > Sent: Saturday, December 14, 2013 1:41 PM > Subject: Re: [Netconf] Fw: Last Call: (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard ... > > (1) The need to reserve a port. > > It clearly addresses (1). > > It is not clear to me how does the document address the need to reverse a > port. It appears you may have mis-read what I wrote. "reserve", not "reverse". Big difference. Randy From bertietf@bwijnen.net Wed Dec 18 02:39:50 2013 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 6EDC11ADFD5 for ; Wed, 18 Dec 2013 02:39:50 -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 GLmJkRftnrTt for ; Wed, 18 Dec 2013 02:39:48 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEE21AE143 for ; Wed, 18 Dec 2013 02:39:48 -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 1VtEXY-0003ar-MQ; Wed, 18 Dec 2013 11:39:46 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest39.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VtEXY-00015m-K3; Wed, 18 Dec 2013 11:39:44 +0100 Message-ID: <52B17B74.1050200@bwijnen.net> Date: Wed, 18 Dec 2013 11:39:48 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Netconf References: 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: 86ab03e524994f79ca2c75a176445dd4bf767d13ea6842823138ccf6b38ad386 Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 10:39:50 -0000 We've had many emails on our WG mailing list, so maybe this one did escape your attention. Please let us (WG hcairs) know if you have any issues with this draft new WG charter. If we do not hear any by Dec 20th, we will pss it to our AD for approval by th IESG. It is always nice to hear that WG participants do agree too! Bert and Mehmet On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > we had two consensus calls ended on December 4, 2013. > > * Verifing session consensus with the maillist on RFC5539bis new port and YANG module separation > _http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html_ > * Verifing session consensus on RESTCONF as WG item with the maillist > _http://www.ietf.org/mail-archive/web/netconf/current/msg08444.html_ > > The co-chairs think that there was support for the action points and no objections to the consensus from the Vancouver NETCONF session. > We think we can go one step further.The co-chairs agreed to have Reverse SSH as a separate document for the time being. > Below is the relevant part of the draft charter. Please comment by December 20, 2013 EOB PT. > We will then pass it on to our AD for approval by IESG. > Bert & Mehmet > --------------- > 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 protocol (RESTCONF) that provides a programmatic > interface for accessing data defined in YANG, using the datastores > defined in NETCONF. The two parts concerning RESTCONF protocol over > HTTP and the YANG patch operation will be prepared in separate drafts. > 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 > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From dromasca@avaya.com Wed Dec 18 06:17:41 2013 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 322851AE117 for ; Wed, 18 Dec 2013 06:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wNDFAvc1TEdx for ; Wed, 18 Dec 2013 06:17:39 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 10F111AE0B9 for ; Wed, 18 Dec 2013 06:17:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAGStsVKHCzI1/2dsb2JhbABZgmkhOE8GuBNPgRsWdIIlAQEBAQMBAQEPKDQXBAIBCA0EBAEBAQoUCQcnCxQJCAIEARIIAQsOh2IBBwWmOKM0F44mGwEBHjMFBoMdgRMEnwKFcYU3gW2BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,508,1384318800"; d="scan'208";a="41579361" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Dec 2013 09:17:36 -0500 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2013 09:06:41 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 09:17:34 -0500 From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO+919qCVFIStNh0yva+xw3sPUeJpZ/gQQ Date: Wed, 18 Dec 2013 14:17:34 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> References: <52B17B74.1050200@bwijnen.net> In-Reply-To: <52B17B74.1050200@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 14:17:41 -0000 Hi, I raised questions in Vancouver about the wisdom of doing RESTCONF in the s= ame WG as NETCONF. I still think that RESTCONF is a different protocol, and= that doing two protocols - the continuation of the development of NETCONF = and a new protocol RESTCONF - in the same WG called NETCONF may be confusin= g for people who are not part of this community, and create doubts about th= e status and stability of NETCONF. I acknowledge that I am on the rough par= t of the consensus.=20 Regards, Dan > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen > (IETF) > Sent: Wednesday, December 18, 2013 12:40 PM > To: Netconf > Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > charter after consensus call >=20 > We've had many emails on our WG mailing list, so maybe this one did > escape your attention. Please let us (WG hcairs) know if you have any > issues with this draft new WG charter. If we do not hear any by Dec > 20th, we will pss it to our AD for approval by th IESG. >=20 > It is always nice to hear that WG participants do agree too! >=20 > Bert and Mehmet >=20 > On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Dear NETCONF WG, > > we had two consensus calls ended on December 4, 2013. > > > > * Verifing session consensus with the maillist on RFC5539bis new > port and YANG module separation > > _http://www.ietf.org/mail- > archive/web/netconf/current/msg08445.html_ > > * Verifing session consensus on RESTCONF as WG item with the > maillist > > > > _http://www.ietf.org/mail-archive/web/netconf/current/msg08444.html_ > > > > The co-chairs think that there was support for the action points and > no objections to the consensus from the Vancouver NETCONF session. > > We think we can go one step further.The co-chairs agreed to have > Reverse SSH as a separate document for the time being. > > Below is the relevant part of the draft charter. Please comment by > December 20, 2013 EOB PT. > > We will then pass it on to our AD for approval by IESG. > > Bert & Mehmet > > --------------- > > 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 protocol (RESTCONF) that provides a > programmatic > > interface for accessing data defined in YANG, using the datastores > > defined in NETCONF. The two parts concerning RESTCONF protocol over > > HTTP and the YANG patch operation will be prepared in separate > drafts. > > 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 > > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed > > Standard > > > > > > _______________________________________________ > > 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 From ietfdbh@comcast.net Wed Dec 18 09:41:35 2013 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 1E7EB1AE021 for ; Wed, 18 Dec 2013 09:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 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, RP_MATCHES_RCVD=-0.538, 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 k9QiJpEMq4-e for ; Wed, 18 Dec 2013 09:41:33 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA541AC448 for ; Wed, 18 Dec 2013 09:41:33 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 30lB1n0041wpRvQ5D5hXeK; Wed, 18 Dec 2013 17:41:31 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta18.westchester.pa.mail.comcast.net with comcast id 35hX1n0022yZEBF3e5hXg9; Wed, 18 Dec 2013 17:41:31 +0000 From: "ietfdbh" To: "'Romascanu, Dan \(Dan\)'" , "'Bert Wijnen \(IETF\)'" , "'Netconf'" References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> Date: Wed, 18 Dec 2013 12:41:26 -0500 Message-ID: <02e501cefc18$60dddb10$22999130$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEmI7IVCFtaF9PUijB0b9MDthTEjwJk+F3/AeK431qbiarHgA== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1387388491; bh=QLCm39EsehXElSJLmRmNuILEO/W6cyXAyFvulyfwUgo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=IBmSjhGzkxXlAgA7JNtEYlamjzvnSbOae5Hlt62Uw98Buaq4qzEt9/011i4VZfuB1 vClHRnmRZ5Fes0Jl5i4s4C39xQM6l6OyboQ9Tf+Ma44KgSH5IIWRUOwX7uWBlOIXgS EE2rbkLEZqPkVttMX8S8ijKhO9j1oqVNIPg8YHG6umDpBGDLMdpy3wlcUutOuZS9a5 4w9sjQRUo+pRW4QjaK0NpvsID9zzzYgdp/VEDu7zbL7o1JnIlunKFMDJIFyCPZHd3h eTfqinXs/RD0f+kpBaLiUybNvhaYy6D3HqI0i5E5a0eFMyY8BatsdIzr5EbUUkQK2/ 01Abx2qXBSoxA== Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 17:41:35 -0000 Hi, I agree with Dan that starting a RESTCONF effort in the same WG could be destabilizing. I think it might be better to do this work in a separate WG that works closely with NETCONF. David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, > Dan (Dan) > Sent: Wednesday, December 18, 2013 9:18 AM > To: Bert Wijnen (IETF); Netconf > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > charter after consensus call > > Hi, > > I raised questions in Vancouver about the wisdom of doing RESTCONF in the > same WG as NETCONF. I still think that RESTCONF is a different protocol, and > that doing two protocols - the continuation of the development of NETCONF > and a new protocol RESTCONF - in the same WG called NETCONF may be > confusing for people who are not part of this community, and create doubts > about the status and stability of NETCONF. I acknowledge that I am on the > rough part of the consensus. > > Regards, > > Dan > > > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert > Wijnen > > (IETF) > > Sent: Wednesday, December 18, 2013 12:40 PM > > To: Netconf > > Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > > charter after consensus call > > > > We've had many emails on our WG mailing list, so maybe this one did > > escape your attention. Please let us (WG hcairs) know if you have any > > issues with this draft new WG charter. If we do not hear any by Dec > > 20th, we will pss it to our AD for approval by th IESG. > > > > It is always nice to hear that WG participants do agree too! > > > > Bert and Mehmet > > > > On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > Dear NETCONF WG, > > > we had two consensus calls ended on December 4, 2013. > > > > > > * Verifing session consensus with the maillist on RFC5539bis new > > port and YANG module separation > > > _http://www.ietf.org/mail- > > archive/web/netconf/current/msg08445.html_ > > > * Verifing session consensus on RESTCONF as WG item with the > > maillist > > > > > > _http://www.ietf.org/mail- > archive/web/netconf/current/msg08444.html_ > > > > > > The co-chairs think that there was support for the action points and > > no objections to the consensus from the Vancouver NETCONF session. > > > We think we can go one step further.The co-chairs agreed to have > > Reverse SSH as a separate document for the time being. > > > Below is the relevant part of the draft charter. Please comment by > > December 20, 2013 EOB PT. > > > We will then pass it on to our AD for approval by IESG. > > > Bert & Mehmet > > > --------------- > > > 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 protocol (RESTCONF) that provides a > > programmatic > > > interface for accessing data defined in YANG, using the datastores > > > defined in NETCONF. The two parts concerning RESTCONF protocol over > > > HTTP and the YANG patch operation will be prepared in separate > > drafts. > > > 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 > > > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed > > > Standard > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From repenno@cisco.com Wed Dec 18 09:51:56 2013 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 065791AE0CC for ; Wed, 18 Dec 2013 09:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.039 X-Spam-Level: X-Spam-Status: No, score=-15.039 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.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 tMtwvqyKQkpU for ; Wed, 18 Dec 2013 09:51:54 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 03ABF1ADFAF for ; Wed, 18 Dec 2013 09:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6475; q=dns/txt; s=iport; t=1387389113; x=1388598713; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=KR/c6fe/e30PmmgcdqhKrVEeMINZC8a09wZTRinmo4A=; b=HOAKddyj+YdUYjrZvNCASay6JZUevJalueG1H0HPVDHiSJm0gp48NpwD vAj2Uz7XW+vdlSFgP1Ttrmjx8pH9DU+4FBYSgGZgYDQJkUC8WH6zbqHtL KHJeeuRUwoePaSSBMaSEt5T0lLeWhvmIpumxLE5yzLARnsTwajwGGeGX+ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAIffsVKtJXG9/2dsb2JhbABWA4MKOE8GuCNPgRsWdIIlAQEBBAEBATc0FwQCAQgRBAEBAQoUCQcnCxQJCAIEARIIAQuHXAMRCAXDKwiHAReOJhsBAR4hFwYLgxKBEwSkc4U3gW2BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,508,1384300800"; d="scan'208";a="292426076" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 18 Dec 2013 17:51:52 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBIHpplx003428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 17:51:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 11:51:51 -0600 From: "Reinaldo Penno (repenno)" To: ietfdbh , "'Romascanu, Dan (Dan)'" , "'Bert Wijnen (IETF)'" , "'Netconf'" Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO/BhouP1kP7yg+ke/u+UHxhy+a5paOkGH Date: Wed, 18 Dec 2013 17:51:51 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B77EF59@xmb-rcd-x04.cisco.com> References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com>, <02e501cefc18$60dddb10$22999130$@comcast.net> In-Reply-To: <02e501cefc18$60dddb10$22999130$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.194] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 17:51:56 -0000 I would prefer that RESTconf is done in Netconf since there is where Netcon= f knowledge resides. Although RESTconf uses HTTP as transport, the protocol= contract is almost the same as Netconf.=0A= =0A= If we go to another WG, we would need Netconf folks to attend that other gr= oup as well. =0A= =0A= We had a similar discussion in Netmod: Should we standardize Yang models fo= r, say, ACLs in Netmod or the Internet area WG? If we go to Internet Area, = Netconf/yang folks would need to attend, if we stay in Netmod, router folks= would need to attend.=0A= =0A= =0A= =0A= ________________________________________=0A= From: Netconf [netconf-bounces@ietf.org] on behalf of ietfdbh [ietfdbh@comc= ast.net]=0A= Sent: Wednesday, December 18, 2013 9:41 AM=0A= To: 'Romascanu, Dan (Dan)'; 'Bert Wijnen (IETF)'; 'Netconf'=0A= Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft cha= rter after consensus call=0A= =0A= Hi,=0A= =0A= I agree with Dan that starting a RESTCONF effort in the same WG could be=0A= destabilizing.=0A= I think it might be better to do this work in a separate WG that works=0A= closely with NETCONF.=0A= =0A= David Harrington=0A= ietfdbh@comcast.net=0A= +1-603-828-1401=0A= =0A= > -----Original Message-----=0A= > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu,= =0A= > Dan (Dan)=0A= > Sent: Wednesday, December 18, 2013 9:18 AM=0A= > To: Bert Wijnen (IETF); Netconf=0A= > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft=0A= > charter after consensus call=0A= >=0A= > Hi,=0A= >=0A= > I raised questions in Vancouver about the wisdom of doing RESTCONF in the= =0A= > same WG as NETCONF. I still think that RESTCONF is a different protocol,= =0A= and=0A= > that doing two protocols - the continuation of the development of NETCONF= =0A= > and a new protocol RESTCONF - in the same WG called NETCONF may be=0A= > confusing for people who are not part of this community, and create doubt= s=0A= > about the status and stability of NETCONF. I acknowledge that I am on the= =0A= > rough part of the consensus.=0A= >=0A= > Regards,=0A= >=0A= > Dan=0A= >=0A= >=0A= >=0A= >=0A= > > -----Original Message-----=0A= > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert=0A= > Wijnen=0A= > > (IETF)=0A= > > Sent: Wednesday, December 18, 2013 12:40 PM=0A= > > To: Netconf=0A= > > Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft=0A= > > charter after consensus call=0A= > >=0A= > > We've had many emails on our WG mailing list, so maybe this one did=0A= > > escape your attention. Please let us (WG hcairs) know if you have any= =0A= > > issues with this draft new WG charter. If we do not hear any by Dec=0A= > > 20th, we will pss it to our AD for approval by th IESG.=0A= > >=0A= > > It is always nice to hear that WG participants do agree too!=0A= > >=0A= > > Bert and Mehmet=0A= > >=0A= > > On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:=0A= > > > Dear NETCONF WG,=0A= > > > we had two consensus calls ended on December 4, 2013.=0A= > > >=0A= > > > * Verifing session consensus with the maillist on RFC5539bis new=0A= > > port and YANG module separation=0A= > > > _http://www.ietf.org/mail-=0A= > > archive/web/netconf/current/msg08445.html_=0A= > > > * Verifing session consensus on RESTCONF as WG item with the=0A= > > maillist=0A= > > >=0A= > > > _http://www.ietf.org/mail-=0A= > archive/web/netconf/current/msg08444.html_=0A= > > >=0A= > > > The co-chairs think that there was support for the action points and= =0A= > > no objections to the consensus from the Vancouver NETCONF session.=0A= > > > We think we can go one step further.The co-chairs agreed to have=0A= > > Reverse SSH as a separate document for the time being.=0A= > > > Below is the relevant part of the draft charter. Please comment by=0A= > > December 20, 2013 EOB PT.=0A= > > > We will then pass it on to our AD for approval by IESG.=0A= > > > Bert & Mehmet=0A= > > > ---------------=0A= > > > In the current phase of NETCONF's incremental development the=0A= > > workgroup=0A= > > > will focus on following items:=0A= > > > 1. Develop the call home mechanism for the mandatory SSH binding= =0A= > > (Reverse=0A= > > > SSH) providing a server-initiated session establishment.=0A= > > > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e.,= =0A= > > update=0A= > > > RFC 5539) and add the call home mechanism to provide a server-=0A= > > initiated=0A= > > > session establishment.=0A= > > > 3. Combine the server configuration data models from Reverse SSH= =0A= > > and=0A= > > > RFC5539bis drafts in a separate YANG module.=0A= > > > 4. Develop a RESTful protocol (RESTCONF) that provides a=0A= > > programmatic=0A= > > > interface for accessing data defined in YANG, using the datastores= =0A= > > > defined in NETCONF. The two parts concerning RESTCONF protocol ove= r=0A= > > > HTTP and the YANG patch operation will be prepared in separate=0A= > > drafts.=0A= > > > Goals and Milestones:=0A= > > > Jan 2014 - Submit initial WG drafts for RESTCONF as WG item=0A= > > > Apr 2014 - WGLC for RFC5539bis=0A= > > > Apr 2014 - WGLC for Reverse SSH=0A= > > > Apr 2014 - WGLC for NETCONF server configuration data model=0A= > > > May 2014 - Submit Reverse SSH to AD/IESG for consideration as=0A= > > Proposed Standard=0A= > > > May 2014 - Submit RFC5539bis to AD/IESG for consideration as=0A= > > Proposed Standard=0A= > > > Jun 2014 - WGLC for RESTCONF=0A= > > > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Propose= d=0A= > > > Standard=0A= > > >=0A= > > >=0A= > > > _______________________________________________=0A= > > > Netconf mailing list=0A= > > > Netconf@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/netconf=0A= > > >=0A= > > _______________________________________________=0A= > > Netconf mailing list=0A= > > Netconf@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/netconf=0A= > _______________________________________________=0A= > Netconf mailing list=0A= > Netconf@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netconf=0A= =0A= _______________________________________________=0A= Netconf mailing list=0A= Netconf@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netconf=0A= From lhotka@nic.cz Wed Dec 18 11:37:27 2013 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 19D041AE1D6 for ; Wed, 18 Dec 2013 11:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_EQ_CZ=0.904] 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 eEPBLv96fx_i for ; Wed, 18 Dec 2013 11:37:24 -0800 (PST) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6A1AE197 for ; Wed, 18 Dec 2013 11:37:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 167AD54027A; Wed, 18 Dec 2013 20:37:21 +0100 (CET) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y+fWkTChqtT; Wed, 18 Dec 2013 20:37:16 +0100 (CET) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 898ED540150; Wed, 18 Dec 2013 20:37:11 +0100 (CET) From: Ladislav Lhotka To: "Romascanu\, Dan \(Dan\)" , "Bert Wijnen \(IETF\)" , Netconf In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> User-Agent: Notmuch/0.16+154~g96c0ce2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Date: Wed, 18 Dec 2013 20:37:10 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 19:37:27 -0000 Hi, "Romascanu, Dan (Dan)" writes: > Hi, > > I raised questions in Vancouver about the wisdom of doing RESTCONF in the same WG as NETCONF. I still think that RESTCONF is a different protocol, and that doing two protocols - the continuation of the development of NETCONF and a new protocol RESTCONF - in the same WG called NETCONF may be confusing for people who are not part of this community, and create doubts about the status and stability of NETCONF. I acknowledge that I am on the rough part of the consensus. I support the current charter proposal, i.e. developing RESTCONF in NETCONF. >From my previous experience, people that don't closely follow NETCONF and NETMOD are often confused by the split between these two WGs. Having three groups with significantly overlapping topics and active participants, separate mailing lists etc., would make things worse. Also, RESTCONF in fact is not a new protocol, it is, for the most part, an application of existing and well-established stuff: HTTP plus REST principles, plus of course YANG. Lada > > Regards, > > Dan > > > > >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen >> (IETF) >> Sent: Wednesday, December 18, 2013 12:40 PM >> To: Netconf >> Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft >> charter after consensus call >> >> We've had many emails on our WG mailing list, so maybe this one did >> escape your attention. Please let us (WG hcairs) know if you have any >> issues with this draft new WG charter. If we do not hear any by Dec >> 20th, we will pss it to our AD for approval by th IESG. >> >> It is always nice to hear that WG participants do agree too! >> >> Bert and Mehmet >> >> On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> > Dear NETCONF WG, >> > we had two consensus calls ended on December 4, 2013. >> > >> > * Verifing session consensus with the maillist on RFC5539bis new >> port and YANG module separation >> > _http://www.ietf.org/mail- >> archive/web/netconf/current/msg08445.html_ >> > * Verifing session consensus on RESTCONF as WG item with the >> maillist >> > >> > _http://www.ietf.org/mail-archive/web/netconf/current/msg08444.html_ >> > >> > The co-chairs think that there was support for the action points and >> no objections to the consensus from the Vancouver NETCONF session. >> > We think we can go one step further.The co-chairs agreed to have >> Reverse SSH as a separate document for the time being. >> > Below is the relevant part of the draft charter. Please comment by >> December 20, 2013 EOB PT. >> > We will then pass it on to our AD for approval by IESG. >> > Bert & Mehmet >> > --------------- >> > 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 protocol (RESTCONF) that provides a >> programmatic >> > interface for accessing data defined in YANG, using the datastores >> > defined in NETCONF. The two parts concerning RESTCONF protocol over >> > HTTP and the YANG patch operation will be prepared in separate >> drafts. >> > 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 >> > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed >> > Standard >> > >> > >> > _______________________________________________ >> > 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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From dromasca@avaya.com Wed Dec 18 11:56:06 2013 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 A56051AE17A for ; Wed, 18 Dec 2013 11:56:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.138 X-Spam-Level: X-Spam-Status: No, score=-3.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fuE3ud9creqd for ; Wed, 18 Dec 2013 11:56:05 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7822C1ADF70 for ; Wed, 18 Dec 2013 11:56:05 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFABb9sVKHCzI1/2dsb2JhbABZgmkhOFW4f4EbFnSCJQEBAQECARIoRAsCAQgNCA0UEDIlAgQBEggah1oIAaZfo2AXjmE4gyOBEwSfAosogW2BPoIq X-IronPort-AV: E=Sophos;i="4.95,508,1384318800"; d="scan'208";a="41637336" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Dec 2013 14:56:03 -0500 Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 18 Dec 2013 14:45:07 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Wed, 18 Dec 2013 20:56:02 +0100 From: "Romascanu, Dan (Dan)" To: Ladislav Lhotka , "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO+919qCVFIStNh0yva+xw3sPUeJpZ/gQQgACvKAD//7Bx4w== Date: Wed, 18 Dec 2013 19:56:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA129F4DBA@AZ-FFEXMB04.global.avaya.com> References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.152.73.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 19:56:06 -0000 Hi Lada,=0A= =0A= As I said, I do not mind being on the rough side of the consensus. I believ= e that RESTCONF is important work, and it is more important that it's done = than where it's done. =0A= =0A= However, as you used the argument - what does the scope below has with NETC= ONF? If at all, it has more to do with NETMOD. =0A= =0A= Regards,=0A= =0A= Dan=0A= =0A= ________________________________________=0A= From: Ladislav Lhotka [lhotka@nic.cz]=0A= =0A= =0A= > Also, RESTCONF in fact is not a new protocol, it is, for the most part, a= n application of existing and well-established stuff: HTTP plus REST princi= ples, plus of course YANG.=0A= =0A= Lada=0A= =0A= From lhotka@nic.cz Wed Dec 18 12:47:16 2013 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 94D021AE138 for ; Wed, 18 Dec 2013 12:47:16 -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 b3odpattbKg3 for ; Wed, 18 Dec 2013 12:47:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7181A1DFA for ; Wed, 18 Dec 2013 12:47:14 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D969C13F65D; Wed, 18 Dec 2013 21:47:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1387399632; bh=KQ7UfQXO+2Xv8tQpyRNafSnZhgoAUpMGL0d1LZIg0AA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=m0a7ZmwQeTd0fOfp9eg4/mMooGn4RGo+DzXEm6CEsAXGEc/sV/mXLqTurc7hJF+fi G+ve/xQppk99Ca4KTice4Rg5oGwjToJ2zWbfTaEOXOz1U54ZoZxOq7nyE4AyUzoiEo wwF5Pg0BUEyMKLxhpLwGKYOGvkX2Tjndwut8Cdc0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA129F4DBA@AZ-FFEXMB04.global.avaya.com> Date: Wed, 18 Dec 2013 21:47:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com>, <9904FB1B0159DA42B0B887B7FA8119CA129F4DBA@AZ-FFEXMB04.global.avaya.com> To: Dan Romascanu 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] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 20:47:16 -0000 On 18 Dec 2013, at 20:56, Romascanu, Dan (Dan) = wrote: > Hi Lada, >=20 > As I said, I do not mind being on the rough side of the consensus. I = believe that RESTCONF is important work, and it is more important that = it's done than where it's done. Absolutely, and it is also important to do it soon, otherwise it will be = done sort of over our heads. > =20 >=20 > However, as you used the argument - what does the scope below has with = NETCONF? If at all, it has more to do with NETMOD. Well, the expanded title of NETCONF WG is =93Network Configuration=94. = :-) Lada > =20 >=20 > Regards, >=20 > Dan >=20 > ________________________________________ > From: Ladislav Lhotka [lhotka@nic.cz] >=20 >=20 >> Also, RESTCONF in fact is not a new protocol, it is, for the most = part, an application of existing and well-established stuff: HTTP plus = REST principles, plus of course YANG. >=20 > Lada >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Dec 18 13:15:07 2013 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 6C1FE1AE01E for ; Wed, 18 Dec 2013 13:15:07 -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 5qeHNZeie6Cs for ; Wed, 18 Dec 2013 13:15:04 -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 A97351ADFFA for ; Wed, 18 Dec 2013 13:15:04 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id c9so202915qcz.30 for ; Wed, 18 Dec 2013 13:15:03 -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=iHiEemaD/432i5M4DYZRyltTzBEZCl2KxJUzcRCT9W8=; b=UUJbm1aBmM876CHxJK3QTNk7sES05cguMaIj79PsVzFthoaB3huGAtoUMYNfU0cJah AZCG0+yEYnOFfFskwJePgWaeArXg5xDDg1Z1SpnwHShjprsGpL9w5+0Ne/wt2dTP3r8R 6gPHQTk3WHUz6rWAI9lWRjh2nRbGmmm+Yi7IfrCStQGd2JkBbijK6wwbyyZ6f7+Qq7Bf d31BbxDHZwarqdIMLVUpBNjs/LIaYGvAN2MXz8asCRBBcpf6LG1tBGmdk//kfnVYOhlF 2IcCMGH/gvBENb+arHGhcbNex/jk8tuUVggJUQpQwiN3EGobDprpUT2IvWuItMQMt42D Hb5Q== X-Gm-Message-State: ALoCoQkTPiDs4w8S4TNokgkLP6c7qN/cp/Wz4JYSPzSIKZYzqnMGYS0Rd64jlxFGe6GRqnZ6ymVy MIME-Version: 1.0 X-Received: by 10.224.8.72 with SMTP id g8mr57375759qag.83.1387401302919; Wed, 18 Dec 2013 13:15:02 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 18 Dec 2013 13:15:02 -0800 (PST) In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B77EF59@xmb-rcd-x04.cisco.com> References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> <02e501cefc18$60dddb10$22999130$@comcast.net> <45A697A8FFD7CF48BCF2BE7E106F06040B77EF59@xmb-rcd-x04.cisco.com> Date: Wed, 18 Dec 2013 13:15:02 -0800 Message-ID: From: Andy Bierman To: "Reinaldo Penno (repenno)" Content-Type: multipart/alternative; boundary=001a11c2478ed2ddd204edd58953 Cc: Netconf Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 21:15:07 -0000 --001a11c2478ed2ddd204edd58953 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 18, 2013 at 9:51 AM, Reinaldo Penno (repenno) wrote: > I would prefer that RESTconf is done in Netconf since there is where > Netconf knowledge resides. Although RESTconf uses HTTP as transport, the > protocol contract is almost the same as Netconf. > > I do not have a strong opinion on this topic, so mild +1. I think RESTCONF is visible on the radar and the interested people will show up no matter where it is hosted. > If we go to another WG, we would need Netconf folks to attend that other > group as well. > > We had a similar discussion in Netmod: Should we standardize Yang models > for, say, ACLs in Netmod or the Internet area WG? If we go to Internet > Area, Netconf/yang folks would need to attend, if we stay in Netmod, router > folks would need to attend. > > This is a different issue -- is YANG mature enough to let individual WGs manage their own YANG development? IMO, yes. It should be done on a case-by-case basis. E.g., The ACL module might be done in NETMOD rather than spin up a WG just for that. But Topology might end up being done in I2RS because they are already chartered to work on topology. Andy > > ________________________________________ > From: Netconf [netconf-bounces@ietf.org] on behalf of ietfdbh [ > ietfdbh@comcast.net] > Sent: Wednesday, December 18, 2013 9:41 AM > To: 'Romascanu, Dan (Dan)'; 'Bert Wijnen (IETF)'; 'Netconf' > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > charter after consensus call > > Hi, > > I agree with Dan that starting a RESTCONF effort in the same WG could be > destabilizing. > I think it might be better to do this work in a separate WG that works > closely with NETCONF. > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Romascanu, > > Dan (Dan) > > Sent: Wednesday, December 18, 2013 9:18 AM > > To: Bert Wijnen (IETF); Netconf > > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > > charter after consensus call > > > > Hi, > > > > I raised questions in Vancouver about the wisdom of doing RESTCONF in the > > same WG as NETCONF. I still think that RESTCONF is a different protocol, > and > > that doing two protocols - the continuation of the development of NETCONF > > and a new protocol RESTCONF - in the same WG called NETCONF may be > > confusing for people who are not part of this community, and create > doubts > > about the status and stability of NETCONF. I acknowledge that I am on the > > rough part of the consensus. > > > > Regards, > > > > Dan > > > > > > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert > > Wijnen > > > (IETF) > > > Sent: Wednesday, December 18, 2013 12:40 PM > > > To: Netconf > > > Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > > > charter after consensus call > > > > > > We've had many emails on our WG mailing list, so maybe this one did > > > escape your attention. Please let us (WG hcairs) know if you have any > > > issues with this draft new WG charter. If we do not hear any by Dec > > > 20th, we will pss it to our AD for approval by th IESG. > > > > > > It is always nice to hear that WG participants do agree too! > > > > > > Bert and Mehmet > > > > > > On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > > > > Dear NETCONF WG, > > > > we had two consensus calls ended on December 4, 2013. > > > > > > > > * Verifing session consensus with the maillist on RFC5539bis new > > > port and YANG module separation > > > > _http://www.ietf.org/mail- > > > archive/web/netconf/current/msg08445.html_ > > > > * Verifing session consensus on RESTCONF as WG item with the > > > maillist > > > > > > > > _http://www.ietf.org/mail- > > archive/web/netconf/current/msg08444.html_ > > > > > > > > The co-chairs think that there was support for the action points and > > > no objections to the consensus from the Vancouver NETCONF session. > > > > We think we can go one step further.The co-chairs agreed to have > > > Reverse SSH as a separate document for the time being. > > > > Below is the relevant part of the draft charter. Please comment by > > > December 20, 2013 EOB PT. > > > > We will then pass it on to our AD for approval by IESG. > > > > Bert & Mehmet > > > > --------------- > > > > 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 protocol (RESTCONF) that provides a > > > programmatic > > > > interface for accessing data defined in YANG, using the datastores > > > > defined in NETCONF. The two parts concerning RESTCONF protocol > over > > > > HTTP and the YANG patch operation will be prepared in separate > > > drafts. > > > > 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 > > > > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as > Proposed > > > > Standard > > > > > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c2478ed2ddd204edd58953 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 18, 2013 at 9:51 AM, Reinaldo Penno (repenno) <repenno= @cisco.com> wrote:
I would prefer that RESTconf is done in Netc= onf since there is where Netconf knowledge resides. Although RESTconf uses = HTTP as transport, the protocol contract is almost the same as Netconf.



I do not have a strong = opinion on this topic, so mild +1.
I think RESTCONF is visible on= the radar and the interested people
will show up no matter where= it is hosted.

=A0
If we go to another WG, we would need Netconf folks to attend that other gr= oup as well.

We had a similar discussion in Netmod: Should we standardize Yang models fo= r, say, ACLs in Netmod or the Internet area WG? If we go to Internet Area, = Netconf/yang folks would need to attend, if we stay in Netmod, router folks= would need to attend.



This is a different iss= ue -- is YANG mature enough to let individual WGs manage
their ow= n YANG development? =A0IMO, yes. =A0It should be done on a case-by-case bas= is.
E.g., The ACL module might be done in NETMOD rather than spin up a WG = just for that.
But Topology might end up being done in I2RS becau= se they are already chartered
to work on topology.


Andy




________________________________________
From: Netconf [netconf-bounces@= ietf.org] on behalf of ietfdbh [= ietfdbh@comcast.net]
Sent: Wednesday, December 18, 2013 9:41 AM
To: 'Romascanu, Dan (Dan)'; 'Bert Wijnen (IETF)'; 'Netc= onf'
Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft =A0c= harter after consensus call

Hi,

I agree with Dan that starting a RESTCONF effort in the same WG could be destabilizing.
I think it might be better to do this work in a separate WG that works
closely with NETCONF.

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

> -----Original Message-----
> From: Netconf [mailto:netc= onf-bounces@ietf.org] On Behalf Of Romascanu,
> Dan (Dan)
> Sent: Wednesday, December 18, 2013 9:18 AM
> To: Bert Wijnen (IETF); Netconf
> Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft=
> charter after consensus call
>
> Hi,
>
> I raised questions in Vancouver about the wisdom of doing RESTCONF in = the
> same WG as NETCONF. I still think that RESTCONF is a different protoco= l,
and
> that doing two protocols - the continuation of the development of NETC= ONF
> and a new protocol RESTCONF - in the same WG called NETCONF may be
> confusing for people who are not part of this community, and create do= ubts
> about the status and stability of NETCONF. I acknowledge that I am on = the
> rough part of the consensus.
>
> Regards,
>
> Dan
>
>
>
>
> > -----Original Message-----
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert
> Wijnen
> > (IETF)
> > Sent: Wednesday, December 18, 2013 12:40 PM
> > To: Netconf
> > Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draf= t
> > charter after consensus call
> >
> > We've had many emails on our WG mailing list, so maybe this o= ne did
> > escape your attention. Please let us (WG hcairs) know if you have= any
> > issues with this draft new WG charter. If we do not hear any by D= ec
> > 20th, we will pss it to our AD for approval by th IESG.
> >
> > It is always nice to hear that WG participants do agree too!
> >
> > Bert and Mehmet
> >
> > On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote:
> > > Dear NETCONF WG,
> > > we had two consensus calls ended on December 4, 2013.
> > >
> > > =A0 * Verifing session consensus with the maillist on RFC553= 9bis new
> > port and YANG module separation
> > > =A0 =A0 _http://www.ietf.org/mail-
> > archive/web/netconf/current/msg08445.html_
> > > =A0 * Verifing session consensus on RESTCONF as WG item with= the
> > maillist
> > >
> > > _htt= p://www.ietf.org/mail-
> archive/web/netconf/current/msg08444.html_
> > >
> > > The co-chairs think that there was support for the action po= ints and
> > no objections to the consensus from the Vancouver NETCONF session= .
> > > We think we can go one step further.The co-chairs agreed to = have
> > Reverse SSH as a separate document for the time being.
> > > Below is the relevant part of the draft charter. Please comm= ent by
> > December 20, 2013 EOB PT.
> > > We will then pass it on to our AD for approval by IESG.
> > > Bert & Mehmet
> > > ---------------
> > > =A0 =A0In the current phase of NETCONF's incremental dev= elopment the
> > workgroup
> > > =A0 =A0will focus on following items:
> > > =A0 =A01. Develop the call home mechanism for the mandatory = SSH binding
> > (Reverse
> > > =A0 =A0SSH) providing a server-initiated session establishme= nt.
> > > =A0 =A02. Advance NETCONF over TLS to be in-line with NETCON= F 1.1 (i.e.,
> > update
> > > =A0 =A0RFC 5539) and add the call home mechanism to provide = a server-
> > initiated
> > > =A0 =A0session establishment.
> > > =A0 =A03. Combine the server configuration data models from = Reverse SSH
> > and
> > > =A0 =A0RFC5539bis drafts in a separate YANG module.
> > > =A0 =A04. Develop a RESTful protocol (RESTCONF) that provide= s a
> > programmatic
> > > =A0 =A0interface for accessing data defined in YANG, using t= he datastores
> > > =A0 =A0defined in NETCONF. The two parts concerning RESTCONF= protocol over
> > > =A0 =A0HTTP and the YANG patch operation will be prepared in= separate
> > drafts.
> > > Goals and Milestones:
> > > =A0 =A0Jan 2014 - Submit initial WG drafts for RESTCONF as W= G item
> > > =A0 =A0Apr 2014 - WGLC for RFC5539bis
> > > =A0 =A0Apr 2014 - WGLC for Reverse SSH
> > > =A0 =A0Apr 2014 - WGLC for NETCONF server configuration data= model
> > > =A0 =A0May 2014 - Submit Reverse SSH to AD/IESG for consider= ation as
> > Proposed Standard
> > > =A0 =A0May 2014 - Submit RFC5539bis to AD/IESG for considera= tion as
> > Proposed Standard
> > > =A0 =A0Jun 2014 - WGLC for RESTCONF
> > > =A0 =A0Aug 2014 - Submit RESTCONF to AD/IESG for considerati= on as Proposed
> > > Standard
> > >
> > >
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a11c2478ed2ddd204edd58953-- From mehmet.ersue@nsn.com Wed Dec 18 13:30:17 2013 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 ABEEF1AE239 for ; Wed, 18 Dec 2013 13:30:17 -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 TPU8Iwb2EhVh for ; Wed, 18 Dec 2013 13:30:14 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E71AE192 for ; Wed, 18 Dec 2013 13:30:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBILU5q8013332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Dec 2013 22:30:05 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBILU4bb011841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 22:30:04 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Dec 2013 22:30:04 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.117]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 22:30:04 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Ladislav Lhotka , "Romascanu, Dan (Dan)" , "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO/DhQ3KRpE0E8xEGBT0yCv76enA== Date: Wed, 18 Dec 2013 21:30:03 +0000 Message-ID: References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.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.124] 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: 6364 X-purgate-ID: 151667::1387402205-00001A6F-DF468BEA/0-0/0-0 Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 21:30:17 -0000 Hi Dan, All, speaking as a technical contributor, I see a huge value in it, if RESTCONF = gets developed in NETCONF WG. Some might see RESTCONF as a new protocol but it isn't. Looking at it from = configuration management pov. RESTCONF builds on and uses the mechanisms NE= TCONF introduced. That said I don't want RESTCONF to compete with NETCONF, which most likely = will happen, if it is developed independent of NETCONF. It is rather in the interest of NETCONF developers and users, if the two pr= otocols are aligned and kept aligned over the time. This parallel development and continuous alignment of the two sister protoc= ols can only be done appropriately, if they are developed in the same WG. Regards,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ladislav= Lhotka > Sent: Wednesday, December 18, 2013 8:37 PM > To: Romascanu, Dan (Dan); Bert Wijnen (IETF); Netconf > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft ch= arter > after consensus call >=20 > Hi, >=20 > "Romascanu, Dan (Dan)" writes: >=20 > > Hi, > > > > I raised questions in Vancouver about the wisdom of doing RESTCONF in t= he same > WG as NETCONF. I still think that RESTCONF is a different protocol, and t= hat doing two > protocols - the continuation of the development of NETCONF and a new prot= ocol > RESTCONF - in the same WG called NETCONF may be confusing for people who = are not > part of this community, and create doubts about the status and stability = of NETCONF. I > acknowledge that I am on the rough part of the consensus. >=20 > I support the current charter proposal, i.e. developing RESTCONF in NETCO= NF. >=20 > From my previous experience, people that don't closely follow NETCONF and= NETMOD > are often confused by the split between these two WGs. Having three group= s with > significantly overlapping topics and active participants, separate mailin= g lists etc., would > make things worse. >=20 > Also, RESTCONF in fact is not a new protocol, it is, for the most part, a= n application of > existing and well-established stuff: HTTP plus REST principles, plus of c= ourse YANG. >=20 > Lada >=20 > > > > Regards, > > > > Dan > > > > > > > > > >> -----Original Message----- > >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijn= en > >> (IETF) > >> Sent: Wednesday, December 18, 2013 12:40 PM > >> To: Netconf > >> Subject: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft > >> charter after consensus call > >> > >> We've had many emails on our WG mailing list, so maybe this one did > >> escape your attention. Please let us (WG hcairs) know if you have any > >> issues with this draft new WG charter. If we do not hear any by Dec > >> 20th, we will pss it to our AD for approval by th IESG. > >> > >> It is always nice to hear that WG participants do agree too! > >> > >> Bert and Mehmet > >> > >> On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > >> > Dear NETCONF WG, > >> > we had two consensus calls ended on December 4, 2013. > >> > > >> > * Verifing session consensus with the maillist on RFC5539bis new > >> port and YANG module separation > >> > _http://www.ietf.org/mail- > >> archive/web/netconf/current/msg08445.html_ > >> > * Verifing session consensus on RESTCONF as WG item with the > >> maillist > >> > > >> > _http://www.ietf.org/mail-archive/web/netconf/current/msg08444.html_ > >> > > >> > The co-chairs think that there was support for the action points and > >> no objections to the consensus from the Vancouver NETCONF session. > >> > We think we can go one step further.The co-chairs agreed to have > >> Reverse SSH as a separate document for the time being. > >> > Below is the relevant part of the draft charter. Please comment by > >> December 20, 2013 EOB PT. > >> > We will then pass it on to our AD for approval by IESG. > >> > Bert & Mehmet > >> > --------------- > >> > 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 protocol (RESTCONF) that provides a > >> programmatic > >> > interface for accessing data defined in YANG, using the datastore= s > >> > defined in NETCONF. The two parts concerning RESTCONF protocol ov= er > >> > HTTP and the YANG patch operation will be prepared in separate > >> drafts. > >> > 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 > >> > Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Propos= ed > >> > Standard > >> > > >> > > >> > _______________________________________________ > >> > 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 > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From repenno@cisco.com Wed Dec 18 14:03:30 2013 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 D9B911AE260 for ; Wed, 18 Dec 2013 14:03:30 -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 Z0L8a_m1dosk for ; Wed, 18 Dec 2013 14:03:29 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCD71AE24E for ; Wed, 18 Dec 2013 14:03:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7937; q=dns/txt; s=iport; t=1387404207; x=1388613807; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=93FTj0+gYCBUUM9k60TC8XR7ja6l8sqZAM/txSJ5U+E=; b=fTjOdH3EFg1JtczOp8v+4HEY5lwJ9RvR3/beuqGELwfjoyNzZ27/4VHo YxKTICo9rwuhKEMWu1wYkMV721bQ/B03ubMN3IPOqlRHQKuH9sO5bSDux 5cfLvd8jZZ2QXPHTw0zwj95fQqwod0ryHmdlhG3+uFG+SBcYo6C2UN1ph c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAHUaslKtJV2d/2dsb2JhbABZgkZEOFW5HoEdFnSCJQECBHkSAQgRAwECKDkUCQgCBA4Fh3ADEcNLCIcBF48BEQeENgSYFpIUgW2BPoIq X-IronPort-AV: E=Sophos;i="4.95,509,1384300800"; d="scan'208,217";a="7739864" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 18 Dec 2013 22:03:26 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rBIM3RU4029320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 22:03:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 16:03:26 -0600 From: "Reinaldo Penno (repenno)" To: Andy Bierman Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO/DY4mP8nGUIIXE2ynTV5Q3ELsJpaX/0A Date: Wed, 18 Dec 2013 22:03:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.242.89] Content-Type: multipart/alternative; boundary="_000_CED75AB475BDrepennociscocom_" MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 18 Dec 2013 22:03:31 -0000 --_000_CED75AB475BDrepennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see as the same issue, different name. If somebody wants to use some other transport besides HTTP should the work = be done on some other WG or in Netconf? If Netconf was mature enough it co= uld be done in the other WG, otherwise in Netconf. At this point I believe Netconf is the proper home for RESTconf. Thanks, Reinaldo From: Andy Bierman > Date: Wednesday, December 18, 2013 at 1:15 PM To: Cisco Employee > Cc: ietfdbh >, "Romascanu, = Dan (Dan)" >, "Bert Wijnen (I= ETF)" >, Netconf > Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft char= ter after consensus call If we go to another WG, we would need Netconf folks to attend that other gr= oup as well. We had a similar discussion in Netmod: Should we standardize Yang models fo= r, say, ACLs in Netmod or the Internet area WG? If we go to Internet Area, = Netconf/yang folks would need to attend, if we stay in Netmod, router folks= would need to attend. This is a different issue -- is YANG mature enough to let individual WGs ma= nage their own YANG development? IMO, yes. It should be done on a case-by-case= basis. E.g., The ACL module might be done in NETMOD rather than spin up a WG just = for that. But Topology might end up being done in I2RS because they are already chart= ered to work on topology. --_000_CED75AB475BDrepennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
I see as the same issue, different name.  

If somebody wants to use some other transport besides HTTP should the = work be done on some other WG or in Netconf?  If Netconf was mature en= ough it could be done in the other WG, otherwise in Netconf.  
At this point I believe Netconf is the proper home for RESTconf.

Thanks,

Reinaldo

From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, December 18, 2013 = at 1:15 PM
To: Cisco Employee <repenno@cisco.com>
Cc: ietfdbh <ietfdbh@comcast.net>, "Romascanu, Dan (Dan)= " <dromasca@avaya.com>= , "Bert Wijnen (IETF)" <bertietf@bwijnen.net>, Netconf <netconf@ietf.org> Subject: Re: [Netconf] Reminder: Ac= tion by Dec 20th 2013 PLEASE: Draft charter after consensus call

If we go to another WG, we would need Netconf folks to attend that other gr= oup as well.

We had a similar discussion in Netmod: Should we standardize Yang models fo= r, say, ACLs in Netmod or the Internet area WG? If we go to Internet Area, = Netconf/yang folks would need to attend, if we stay in Netmod, router folks= would need to attend.



This is a different issue -- is YANG mature enough to let individual WGs ma= nage
their own YANG development?  IMO, yes.  It should be done on a ca= se-by-case basis.
E.g., The ACL module might be done in NETMOD rather than spin up a WG just = for that.
But Topology might end up being done in I2RS because they are already chart= ered
to work on topology.
 --_000_CED75AB475BDrepennociscocom_-- From j.schoenwaelder@jacobs-university.de Thu Dec 19 06:53:29 2013 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 D3F201ADFA9 for ; Thu, 19 Dec 2013 06:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 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.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 VnxnRDu-9Y88 for ; Thu, 19 Dec 2013 06:53:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2F21ADFB3 for ; Thu, 19 Dec 2013 06:53:28 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38F1F2019E; Thu, 19 Dec 2013 15:53:26 +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 KTaQAksefKGh; Thu, 19 Dec 2013 15:53:26 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 734F22002E; Thu, 19 Dec 2013 15:53:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 43CDE2A0BFD7; Thu, 19 Dec 2013 15:53:20 +0100 (CET) Date: Thu, 19 Dec 2013 15:53:20 +0100 From: Juergen Schoenwaelder To: ietfdbh Message-ID: <20131219145319.GE4249@elstar.local> Mail-Followup-To: ietfdbh , "'Romascanu, Dan (Dan)'" , "'Bert Wijnen (IETF)'" , 'Netconf' References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> <02e501cefc18$60dddb10$22999130$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02e501cefc18$60dddb10$22999130$@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 'Netconf' Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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: Thu, 19 Dec 2013 14:53:30 -0000 On Wed, Dec 18, 2013 at 12:41:26PM -0500, ietfdbh wrote: > Hi, > > I agree with Dan that starting a RESTCONF effort in the same WG could be > destabilizing. > I think it might be better to do this work in a separate WG that works > closely with NETCONF. > While RESTCONF may be seen as a competitor to NETCONF by some, I think it does not matter at all where it is done in the IETF. In fact, I could easily find reasons why a separate WG could be seen even more as developing a competitor to NETCONF. To ensure that NETCONF and RESTCONF stay aligned and since to a large extend the same people are involved, I think doing RESTCONF in the NETCONF WG makes a lot of sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From alex@cisco.com Thu Dec 19 11:49:48 2013 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 019611AE180 for ; Thu, 19 Dec 2013 11:49:48 -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 MCipb1adr3rQ for ; Thu, 19 Dec 2013 11:49:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 524151AE165 for ; Thu, 19 Dec 2013 11:49:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2281; q=dns/txt; s=iport; t=1387482584; x=1388692184; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jrcQ9vL1IoQigMbXSA7MibYo20hL06tm13Wo06sy/nc=; b=cx2lEngp3SeYKYLjyQv1iDuuWctxp69049yo6PkCGnJsvqZi+55+HBBs SEzJP9uHKxRfNLQWTaM4M7A+DOGhXLOWHTltb4OPUNveof7ZozsX83KUV qcimRi3ZPMhEv05DMlysSh+jjIh1W8pJiBfONhIOwkKrNH11SvdRf4puQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAGhNs1KtJXG//2dsb2JhbABWA4MLOFW4YE+BFxZ0giUBAQEEAQEBNzQLDAICAgEIDgIBBAEBAQoUCQcbDAsUCQgCBAENBQiHfA3KdxcEjiI7IRAHBguDEoETBKoqgW2BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,514,1384300800"; d="scan'208";a="7981000" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 19 Dec 2013 19:49:42 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBJJngJO013712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 19:49:42 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.73]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 13:49:42 -0600 From: "Alexander Clemm (alex)" To: Juergen Schoenwaelder , ietfdbh Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO/MoXy69Wyvr0z0OK47s6NYmBnJpb6KzA Date: Thu, 19 Dec 2013 19:49:42 +0000 Message-ID: References: <52B17B74.1050200@bwijnen.net> <9904FB1B0159DA42B0B887B7FA8119CA129F44E8@AZ-FFEXMB04.global.avaya.com> <02e501cefc18$60dddb10$22999130$@comcast.net> <20131219145319.GE4249@elstar.local> In-Reply-To: <20131219145319.GE4249@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.15] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Netconf' Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 19 Dec 2013 19:49:48 -0000 To Bert's original question, I support this charter. IMHO I think it is fine for RESTCONF and NETCONF be in the same working gro= up. If it causes confusion, perhaps a change in name for the working group= can be considered (Protocols and transports for YANG datamodels in Netconf= datastores). I also think the wording of point 4 could be slightly improv= ed, but this is a minor item ("4. Develop a RESTful protocol (RESTCONF) tha= t provides a programmatic interface for accessing data defined in YANG, usi= ng the datastores defined in NETCONF. " - I find the blurring between "pro= grammatic interface" and "protocol" not very clear; isn't the goal not real= ly a programmatic interface per se but to simply provide REST developers wi= th a simple access to Netconf datastores for applications that do not requi= re many of the richer services that are provided through Netconf?) Thanks --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoen= waelder Sent: Thursday, December 19, 2013 6:53 AM To: ietfdbh Cc: 'Netconf' Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft char= ter after consensus call On Wed, Dec 18, 2013 at 12:41:26PM -0500, ietfdbh wrote: > Hi, >=20 > I agree with Dan that starting a RESTCONF effort in the same WG could=20 > be destabilizing. > I think it might be better to do this work in a separate WG that works=20 > closely with NETCONF. >=20 While RESTCONF may be seen as a competitor to NETCONF by some, I think it d= oes not matter at all where it is done in the IETF. In fact, I could easily= find reasons why a separate WG could be seen even more as developing a com= petitor to NETCONF. To ensure that NETCONF and RESTCONF stay aligned and si= nce to a large extend the same people are involved, I think doing RESTCONF = in the NETCONF WG makes a lot of sense. /js --=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 yihuan@cisco.com Thu Dec 19 12:21:42 2013 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 186F81AE581 for ; Thu, 19 Dec 2013 12:21:42 -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 07G06jAvEw4P for ; Thu, 19 Dec 2013 12:21:40 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 10B3E1AE235 for ; Thu, 19 Dec 2013 12:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1387484498; x=1388694098; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=4ETa3r3tYNkII3kYVS0qymc+IuSZpduo7931oxKetx0=; b=Ncb6LLf50cl4q9Gh94Gwuxc4oHk+bjPSLDdvWA83Eiv/fLq3jvXmeqdf kzL7VSRR3FxSRgjUZwVupNrBEStSe5kdkBVmQ7PHSdK8AfH2vo9WP5GF/ KOB/9+NPjpazxz5R6uJhPEiwid7oNXKEJzWfwSQrAJt7kQqv5TlmtaeBi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGZUs1KtJXG8/2dsb2JhbABZgws4VbhgT4EYFnSCJQEBAQQBAQE3NB0BCBgeNwslAgQBEgmHew3KbxeOJhsBAVEFhDYEmBaSFIFtgT6BcTk X-IronPort-AV: E=Sophos;i="4.95,514,1384300800"; d="scan'208";a="7987213" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-3.cisco.com with ESMTP; 19 Dec 2013 20:21:37 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBJKLbEi000690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 20:21:37 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.155]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 14:21:36 -0600 From: "Lisa Huang (yihuan)" To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call Thread-Index: AQHO9njRcsoTthT74EWvwxfLqjMn65paMpUAgAGuxYA= Date: Thu, 19 Dec 2013 20:21:36 +0000 Message-ID: In-Reply-To: <52B17B74.1050200@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.86.218] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Reminder: Action by Dec 20th 2013 PLEASE: Draft charter after consensus call 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, 19 Dec 2013 20:21:42 -0000 I support this charter. Here is my opinion on item 4: I believe the goal is not to provide programmatic interface, but a set of standards about how to relate restful path with yang path and how to simplify RESTful application to access Netconf datastore, etc. On 12/18/13 2:39 AM, "Bert Wijnen (IETF)" wrote: >We've had many emails on our WG mailing list, so maybe this one >did escape your attention. Please let us (WG hcairs) know if you >have any issues with this draft new WG charter. If we do not hear >any by Dec 20th, we will pss it to our AD for approval by th IESG. > >It is always nice to hear that WG participants do agree too! > >Bert and Mehmet > >On 12/11/13 2:56 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: >> Dear NETCONF WG, >> we had two consensus calls ended on December 4, 2013. >> >> * Verifing session consensus with the maillist on RFC5539bis new port >>and YANG module separation >> _http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html_ >> * Verifing session consensus on RESTCONF as WG item with the maillist >> _http://www.ietf.org/mail-archive/web/netconf/current/msg08444.html_ >> >> The co-chairs think that there was support for the action points and no >>objections to the consensus from the Vancouver NETCONF session. >> We think we can go one step further.The co-chairs agreed to have >>Reverse SSH as a separate document for the time being. >> Below is the relevant part of the draft charter. Please comment by >>December 20, 2013 EOB PT. >> We will then pass it on to our AD for approval by IESG. >> Bert & Mehmet >> --------------- >> 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 protocol (RESTCONF) that provides a programmatic >> interface for accessing data defined in YANG, using the datastores >> defined in NETCONF. The two parts concerning RESTCONF protocol over >> HTTP and the YANG patch operation will be prepared in separate >>drafts. >> 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 >> Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed >>Standard >> >> >> _______________________________________________ >> 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 From andy@yumaworks.com Sat Dec 21 12:26:42 2013 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 2D28A1AE046 for ; Sat, 21 Dec 2013 12:26:42 -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 ZvKANKDYicYm for ; Sat, 21 Dec 2013 12:26:40 -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 CCC961AE044 for ; Sat, 21 Dec 2013 12:26:39 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id e16so3611385qcx.27 for ; Sat, 21 Dec 2013 12:26:37 -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=zMD9vSpvBsMlgo7v6N9j6wcIza2+ydkzYMQV+hugppo=; b=AVgMD8V1sRaQ1zoqcj0z9JjPrPRC66yITK8PuBRDwMeAFmuFwLGIRyzIn6fOc75Dhf 1t6d9fjum6kXLlSCyWJ36LQdf4oQclVQJQ/byAXEeRKbaRUp/dr4ph6jCSNDCUkh0gEX 3ZSESsectHSlmIQnkRfS/D1Wrx0L0c4vAdCIv8J+v6GpqbdW7DaL9sAU4ggGGvYVtwQV 6jJP7LE58jN2XLLZwwzGQEsNrynZb90x9SgcmmvF8cMEHCldzXiTX1bsHAnKv+0loGwU f4xMpRbo7aAXNw/0DUdF/mmY/eTU07S85IHbofbAUzvAq33CU2kdPyWyyKrgFmBBmmUH 1IDw== X-Gm-Message-State: ALoCoQmUvSNZHefrng87eOE45A1cfWDn5yX176XIBKUkzTG5GYE+3DvxHbYrGoNpx+JzDJdk/gmH MIME-Version: 1.0 X-Received: by 10.49.76.66 with SMTP id i2mr27424894qew.35.1387657597074; Sat, 21 Dec 2013 12:26:37 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sat, 21 Dec 2013 12:26:37 -0800 (PST) In-Reply-To: <20131221202305.29593.70148.idtracker@ietfa.amsl.com> References: <20131221202305.29593.70148.idtracker@ietfa.amsl.com> Date: Sat, 21 Dec 2013 12:26:37 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=047d7bea3f4c24d63004ee113611 Subject: [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, 21 Dec 2013 20:26:42 -0000 --047d7bea3f4c24d63004ee113611 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7bea3f4c24d63004ee113611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

This version of RESTCONF addresses= many of the issues raised at the last IETF.
See the change log f= or 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 director= ies.


=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-restconf-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-netconf-= restconf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 3

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-ne= tconf-restconf-03


Please note that it may take a couple of minutes from the time of submissio= n
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

--047d7bea3f4c24d63004ee113611-- From andy@yumaworks.com Sat Dec 21 12:30:46 2013 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 B78521AE059 for ; Sat, 21 Dec 2013 12:30:46 -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 xYxCPJObshIc for ; Sat, 21 Dec 2013 12:30:44 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id B8EB01AE058 for ; Sat, 21 Dec 2013 12:30:44 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id n7so3456326qcx.5 for ; Sat, 21 Dec 2013 12:30:42 -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=oy0shzds1jb83jRdz3SJf1iKkNmuM43wlhK5Ov89f+0=; b=hI0hUhf3X7OufBYGK2REsyVVszy4eVxNPokm71CH88aZXhtH25kNfWGJxfL/WLbhEh O8ZeQvrQfdn2Ha5EDUIpECFyREU9tmxVMoR8pt5tn35sMAWZaPeLRIFIdh32kDiyUbEm V+IizZ7hdaejwiv6NToL0rNrnBVMd5WPnsprUK8oRAQICI6xPZbZIEcFsU5MqMqm+FFb TXwnqYjZJ5Vn6r8MxF3QoihBx8GD5/kb+iv8iuDYbfgQcJ9KtZ/hqGlL4nde2fyWFkEx EJAn2gdA2T//lePOtDLQAnAppZ0ThIi0AOg19wtEvr5vW7mIq3zhaFfWVQAoFRB+/7Sc Ptiw== X-Gm-Message-State: ALoCoQmzhNjdTs+sc3pImxVdf5Mn8bO2aUrFw8gmHMtHXH76CLAyMEAwN9CR3cSvMyekHyVROzl8 MIME-Version: 1.0 X-Received: by 10.49.75.10 with SMTP id y10mr27520294qev.56.1387657842058; Sat, 21 Dec 2013 12:30:42 -0800 (PST) Received: by 10.140.48.75 with HTTP; Sat, 21 Dec 2013 12:30:42 -0800 (PST) In-Reply-To: <20131221202855.507.36359.idtracker@ietfa.amsl.com> References: <20131221202855.507.36359.idtracker@ietfa.amsl.com> Date: Sat, 21 Dec 2013 12:30:42 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=047d7bea409cbf01d504ee114404 Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-yang-patch-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: Sat, 21 Dec 2013 20:30:46 -0000 --047d7bea409cbf01d504ee114404 Content-Type: text/plain; charset=ISO-8859-1 FYI, This is the YANG Patch document split out from RESTCONF-02. Andy ---------- Forwarded message ---------- From: Date: Sat, Dec 21, 2013 at 12:28 PM Subject: I-D Action: draft-bierman-netconf-yang-patch-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-bierman-netconf-yang-patch-00.txt Pages : 30 Date : 2013-12-21 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-yang-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-yang-patch-00 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 --047d7bea409cbf01d504ee114404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

This is the YANG Patch document sp= lit out from RESTCONF-02.


Andy


---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
= Date: Sat, Dec 21, 2013 at 12:28 PM
Subject: I-D Action: draft-bierman-n= etconf-yang-patch-00.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : YANG Patch Media Type
=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-yang-patch-= 00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-21

Abstract:
=A0 =A0This document describes a method for applying patches to NETCONF
=A0 =A0datastores using data defined with the YANG data modeling language.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netcon= f-yang-patch/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-yang-pat= ch-00


Please note that it may take a couple of minutes from the time of submissio= n
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

--047d7bea409cbf01d504ee114404--