Draft Agenda for IETF #74 NETCONF Session

On Wed, Feb 6, 2013 at 5:43 PM, Phil Sha= fer <phil@juniper.net> wrote:

>Riddle me this: two NETCONF clients connect to the same NETCONF server.=
>One client locks the candidate datastore, which is already a copy of th= e
>running datastore, and then pauses, during which the other client execu= tes
><discard-changes> - what RPC-reply should the 2nd client receive?=
>
>Possible answers:
>
> =C2=A0 =C2=A01. <rpc-error> =C2=A0 - lock is tested before reque= st is considered
>
> =C2=A0 =C2=A02. <ok/> =C2=A0 =C2=A0 =C2=A0 =C2=A0 - request is c= onsidered first and, since there were
>no changes
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 to discard, there was no need to check the lock's
>status
>
> =C2=A0 =C2=A03. Up to vendor =C2=A0- RFC 6241 is underspecified

6241 says:

=C2=A0 =C2=A0 =C2=A0 When the lock is acquired, the server MUST prevent any= changes to
=C2=A0 =C2=A0 =C2=A0 the locked resource other than those requested by this= session.

and:

=C2=A0 =C2=A0 =C2=A0 When a lock is active, using the <edit-config> o= peration
=C2=A0 =C2=A0 =C2=A0 on the locked configuration datastore and using the lo= cked
=C2=A0 =C2=A0 =C2=A0 configuration as a target of the <copy-config> o= peration will be
=C2=A0 =C2=A0 =C2=A0 disallowed by any other NETCONF session. =C2=A0Additio= nally, the system
=C2=A0 =C2=A0 =C2=A0 will ensure that these locked configuration resources = will not be
=C2=A0 =C2=A0 =C2=A0 modified by other non-NETCONF management operations su= ch as SNMP
=C2=A0 =C2=A0 =C2=A0 and CLI.

The <discard-changes> section doesn't discuss locks.

So (3) is definitely true, but (1) seems fairly obviously the
right behavior.

We return an 'in-use' error -t= ag (1).

We test the lock before checking if there are really any = changes to discard.

Thanks,
=C2=A0Phil

Andy

--047d7b339887ee7e0b04d518afec-- From mbj@tail-f.com Thu Feb 7 00:07:27 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45EF221F8455 for ; Thu, 7 Feb 2013 00:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSWUiBEQhgDa for ; Thu, 7 Feb 2013 00:07:26 -0800 (PST) Received: from mx.tail-f.com (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by ietfa.amsl.com (Postfix) with ESMTP id C237D21F8906 for ; Thu, 7 Feb 2013 00:07:15 -0800 (PST) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mx.tail-f.com (Postfix) with ESMTP id 11F57410DF1; Thu, 7 Feb 2013 09:07:14 +0100 (CET) Date: Thu, 07 Feb 2013 09:07:13 +0100 (CET) Message-Id: <20130207.090713.240243713919466522.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <201302070143.r171hBdr098273@idle.juniper.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: netconf@ietf.org Subject: Re: [Netconf] clarification on X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 08:07:27 -0000 Andy Bierman wrote: > On Wed, Feb 6, 2013 at 5:43 PM, Phil Shafer wrote: > > > >Riddle me this: two NETCONF clients connect to the same NETCONF server. > > >One client locks the candidate datastore, which is already a copy of the > > >running datastore, and then pauses, during which the other client executes > > > - what RPC-reply should the 2nd client receive? > > > > > >Possible answers: > > > > > > 1. - lock is tested before request is considered > > > > > > 2. - request is considered first and, since there were > > >no changes > > > to discard, there was no need to check the lock's > > >status > > > > > > 3. Up to vendor - RFC 6241 is underspecified > > > > 6241 says: > > > > When the lock is acquired, the server MUST prevent any changes to > > the locked resource other than those requested by this session. > > > > and: > > > > When a lock is active, using the operation > > on the locked configuration datastore and using the locked > > configuration as a target of the operation will be > > disallowed by any other NETCONF session. Additionally, the system > > will ensure that these locked configuration resources will not be > > modified by other non-NETCONF management operations such as SNMP > > and CLI. > > > > The section doesn't discuss locks. > > > > So (3) is definitely true, but (1) seems fairly obviously the > > right behavior. +1 > We return an 'in-use' error -tag (1). > We test the lock before checking if there are really any changes to discard. So do we. /martin From mehmet.ersue@nsn.com Mon Feb 11 01:31:14 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F42721F86A3 for ; Mon, 11 Feb 2013 01:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO+RJ-SGPg9Z for ; Mon, 11 Feb 2013 01:31:13 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68F21F8667 for ; Mon, 11 Feb 2013 01:31:13 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1B9V8R3015172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 11 Feb 2013 10:31:08 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1B9V7N1030294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 11 Feb 2013 10:31:08 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 10:31:07 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: netconf - Requested session has been scheduled for IETF 86 Thread-Index: AQHOBXGSLWV3CRFA40CTkmte2VNVHZh0Y2mw Date: Mon, 11 Feb 2013 09:31:07 +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.126] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: 1844 X-purgate-ID: 151667::1360575070-0000215D-6FEFD235/0-0/0-0 Subject: [Netconf] FW: netconf - Requested session has been scheduled for IETF 86 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 09:31:14 -0000 RGVhciBOZXRjb25mIFdHLA0KDQpUaGUgV0cgc2Vzc2lvbiBpbiBJRVRGIDg2IGhhcyBiZWVuIHNj aGVkdWxlZCBmb3IgTW9uZGF5IGFmdGVybm9vbiBhdCAxNTQwLTE3MTAuDQoNCldlIHdvdWxkIGxp a2UgdG8gYXNrIHRoZSBkcmFmdCBhdXRob3JzIHRvIHJlZ2FyZCB0aGUgc3VibWlzc2lvbiBkZWFk bGluZXMuDQpUaGUgZG9jdW1lbnRzIG5lZWQgYSByZXZpZXcgYW5kIGRpc2N1c3Npb24gYmVmb3Jl IHRoZSBtZWV0aW5nLg0KDQrigKIgIDIwMTMtMDItMTggKE1vbmRheSk6IEludGVybmV0IERyYWZ0 IEN1dC1vZmYgZm9yIGluaXRpYWwgZG9jdW1lbnQgKC0wMCkgc3VibWlzc2lvbiBieSBVVEMgMjQ6 MDAsIHVwbG9hZCB1c2luZyBJRVRGIElEIFN1Ym1pc3Npb24gVG9vbC4gDQrigKIgIDIwMTMtMDIt MjUgKE1vbmRheSk6IEludGVybmV0IERyYWZ0IGZpbmFsIHN1Ym1pc3Npb24gY3V0LW9mZiBieSBV VEMgMjQ6MDAsIHVwbG9hZCB1c2luZyBJRVRGIElEIFN1Ym1pc3Npb24gVG9vbC4NCg0KV2Ugd291 bGQgbGlrZSB0byBlbmNvdXJhZ2UgdGhlIGF1dGhvcnMgb2YgdGhlIFdHIGl0ZW0gcmZjNTUzOWJp cyBkcmFmdCB0byBzdWJtaXQgZWFybHkgdG8gZW5hYmxlIGEgcmV2aWV3IGFuZCBpc3N1ZSBzb2x2 aW5nLiBBcyBwbGFubmVkIHRoZSBuZXh0IHN0ZXAgaXMgYSBuZXcgV0dMQy4NCg0KTWVobWV0ICYg QmVydA0KIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogIklFVEYgU2VjcmV0 YXJpYXQiIFttYWlsdG86YWdlbmRhQGlldGYub3JnXSANClNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAwNywgMjAxMyA5OjI4IFBNDQpUbzogRXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ0K Q2M6IG5ldGNvbmYtYWRzQHRvb2xzLmlldGYub3JnOyBiZXJ0aWV0ZkBid2lqbmVuLm5ldDsgRXJz dWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKTsgd2xvQGFtc2wuY29tDQpTdWJqZWN0OiBuZXRj b25mIC0gUmVxdWVzdGVkIHNlc3Npb24gaGFzIGJlZW4gc2NoZWR1bGVkIGZvciBJRVRGIDg2DQoN CkRlYXIgTWVobWV0IEVyc3VlLA0KDQpUaGUgc2Vzc2lvbihzKSB0aGF0IHlvdSBoYXZlIHJlcXVl c3RlZCBoYXZlIGJlZW4gc2NoZWR1bGVkLg0KQmVsb3cgaXMgdGhlIHNjaGVkdWxlZCBzZXNzaW9u IGluZm9ybWF0aW9uIGZvbGxvd2VkIGJ5DQp0aGUgb3JpZ2luYWwgcmVxdWVzdC4gDQoNCm5ldGNv bmYgU2Vzc2lvbiAxICgxOjMwOjAwKQ0KICAgIE1vbmRheSwgQWZ0ZXJub29uIFNlc3Npb24gSUkg MTU0MC0xNzEwDQogICAgUm9vbSBOYW1lOiBCb2NhIDENCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCg== From j.schoenwaelder@jacobs-university.de Tue Feb 12 07:13:58 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696C821F8EA7 for ; Tue, 12 Feb 2013 07:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ti8lLn6dn-Mx for ; Tue, 12 Feb 2013 07:13:57 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 67E6621F8E9C for ; Tue, 12 Feb 2013 07:13:57 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9358120BDA; Tue, 12 Feb 2013 16:13:56 +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 O4h9LRsX4sAA; Tue, 12 Feb 2013 16:13:56 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C5B12062F; Tue, 12 Feb 2013 16:13:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6A03C2479952; Tue, 12 Feb 2013 16:14:02 +0100 (CET) Date: Tue, 12 Feb 2013 16:14:02 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20130212151402.GA2752@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Feb 2013 15:13:58 -0000 Hi, I have a question concerning the YANG API draft. If I have a data model that is nested lets say three levels deep, a { b { c { } } } does a server need to implement all possible datastore resources, that is: /yang-api/datastore/a /yang-api/datastore/a/b /yang-api/datastore/a/b/c Note that not all those resources may be 'useful' to support, the closer you get to the root, the larger the data gets one is operating on. /js PS: Did you really mean this: A RESTful client using YANG-API will not use any data modelling language to define the application-specific content of the API. The client would discover each new child resource as it traverses the URIs return as Location IDs to discover the server capabilities. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Feb 12 07:39:24 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56F21F8EE1 for ; Tue, 12 Feb 2013 07:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.014 X-Spam-Level: X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm4Rbx-H9VB4 for ; Tue, 12 Feb 2013 07:39:23 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCD21F8EDF for ; Tue, 12 Feb 2013 07:39:23 -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 DAD2F1200054; Tue, 12 Feb 2013 16:39:21 +0100 (CET) Date: Tue, 12 Feb 2013 16:39:21 +0100 (CET) Message-Id: <20130212.163921.1368938996418479237.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130212151402.GA2752@elstar.local> References: <20130212151402.GA2752@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:39:24 -0000 Juergen Schoenwaelder wrote: > Hi, > > I have a question concerning the YANG API draft. If I have a data model > that is nested lets say three levels deep, > > a { > b { > c { > } > } > } > > does a server need to implement all possible datastore resources, > that is: > > /yang-api/datastore/a > /yang-api/datastore/a/b > /yang-api/datastore/a/b/c > Currently the answer is "yes". But there is an open issue listed in section 12 o Should every YANG data node be a data resource and every YANG RPC statement an operation resource? Is a YANG extension needed to allow data modeler control of resource boundaries? Maybe you have some experience regarding this? > Note that not all those resources may be 'useful' to support, the > closer you get to the root, the larger the data gets one is operating > on. > > /js > > PS: Did you really mean this: > > A RESTful client using YANG-API will not use any data modelling > language to define the application-specific content of the API. The > client would discover each new child resource as it traverses the > URIs return as Location IDs to discover the server capabilities. This goes back to what RESTful really means. It seems that from a pure REST point of view, clients should treat the URIs as opaque strings. A proper RESTful client would never construct a URI; it would just follow links. YANG-API supports such clients, while at the same time it also supports clients that do construct URIs. /martin From andy@yumaworks.com Tue Feb 12 07:45:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A0B21F8F15 for ; Tue, 12 Feb 2013 07:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4k4kTTJ2j64I for ; Tue, 12 Feb 2013 07:45:53 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1855221F8F12 for ; Tue, 12 Feb 2013 07:45:52 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k11so280718iea.10 for ; Tue, 12 Feb 2013 07:45:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=pRcqiWTlV0N0nsS+8FuYWFNbDvPxg3Iib6PWaBWQ64c=; b=Ca/qjufhoiFXr2tfms+YxzQQV592QevsP/WJU61zVChAQLYvO0CC0imJsM2l7/5wuZ dFs4LGUdIntIMQxcz7nDa/wanW5ImUp6mN9sqW//hriSzNA/jI5/l3GUyJT8I4zFF28p DgvkMkEQw+S1WGeR5VgYPh4fSt+4OxxPbOiOQVTFyscWlIT52uM6zQgwNtqdabRblTqu E3PT/nn8Wpt4hJZ6GlhlvhVD0aQrv58seVe8J2INj6/E93KUUYnWyqTZQO314iFhG4f/ 4gqGB1wPmoMwaj72y8D10hqQd+DIpDVaLCaVSHMQ+mn7Xk+8ZsuDKoMHy6M2SK/hSugM 9hCA== MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr4076441igc.96.1360683952395; Tue, 12 Feb 2013 07:45:52 -0800 (PST) Received: by 10.231.93.132 with HTTP; Tue, 12 Feb 2013 07:45:52 -0800 (PST) In-Reply-To: <20130212151402.GA2752@elstar.local> References: <20130212151402.GA2752@elstar.local> Date: Tue, 12 Feb 2013 07:45:52 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , netconf@ietf.org Content-Type: multipart/alternative; boundary=14dae9340fe1a2566504d588eb48 X-Gm-Message-State: ALoCoQkJAnpCZD1zwnkml3wilAQxNMCYG/rs9niHRZug5Cvrkvk+LwdytBUYnspvohdZlVgABY/7 Subject: Re: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:45:53 -0000 --14dae9340fe1a2566504d588eb48 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 12, 2013 at 7:14 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I have a question concerning the YANG API draft. If I have a data model > that is nested lets say three levels deep, > > a { > b { > c { > } > } > } > > does a server need to implement all possible datastore resources, > that is: > > /yang-api/datastore/a > /yang-api/datastore/a/b > /yang-api/datastore/a/b/c > > Good question -- it probably depends on the method. GET, DELETE, PUT -- yes. PATCH maybe. POST may be up to the capabilities of the server. I have found a couple major design flaws during my implementation that the WG should probably know about: 1) list and leaf-list targets for GET that return multiple instances need a wrapper for XML encoding or else the response will not be a valid XML document. JSON does not have this problem. There is no XML namespace defined yet for or this wrapper. 2) retrieval of 'config=false only' could be very expensive to implement in an optimized (streamed) manner because scaffolding nodes (containers, lists that are config=true) need to be generated before the server knows if any instances of the config=false nodes exist, and pass NACM and other filtering. Since config=false nodes can never contain config=true nodes, the pruning for current is trivial. Few observations: - the distinction between fields and resources is artificial and not useful. My implementation is aligning with and just treating each nest level as a new level wrt/retrieval filtering - netconf-monitoring and notifications are supported (except start-session and end-session are not sent). NETCONF monitoring is somewhat deficient for multiple protocols. It is not clear which counters (if any) apply to YANG-API requests. - It is not clear when a 404 Not Found status would be returned. The draft says to return 400 Bad Request for unknown resources. Note that not all those resources may be 'useful' to support, the > closer you get to the root, the larger the data gets one is operating > on. > The server may need to restrict how many resources can be edited at once. > /js > > PS: Did you really mean this: > > A RESTful client using YANG-API will not use any data modelling > language to define the application-specific content of the API. The > client would discover each new child resource as it traverses the > URIs return as Location IDs to discover the server capabilities. > > No -- this should have been removed. Andy --14dae9340fe1a2566504d588eb48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 7:14 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

Hi,

I have a question concerning the YANG API draft. If I have a data model
that is nested lets say three levels deep,

a {
=C2=A0 b {
=C2=A0 =C2=A0 c {
=C2=A0 =C2=A0 }
=C2=A0 }
}

does a server need to implement all possible datastore resources,
that is:

=C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a
=C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a/b
=C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a/b/c

Good question -- it probably depends o= n the method.

GET, DELETE, PUT -- yes. PATCH maybe. POST may
b= e up to the capabilities of the server.

I have fou= nd a couple major design flaws during my implementation

that the WG should probably know about:

1) li= st and leaf-list targets for GET that return multiple instances
=C2=A0 = =C2=A0 need a <data> wrapper for XML encoding=C2=A0or else the respon= se will
=C2=A0 =C2=A0 not be a valid XML document. =C2=A0JSON does not h= ave this problem.

=C2=A0 =C2=A0 There is no XML namespace defined yet for <errors>= or this <data> wrapper.

2) retrieval of = 9;config=3Dfalse only' could be very expensive to implement in an
= =C2=A0 =C2=A0 optimized (streamed) manner because scaffolding nodes (contai= ners, lists that
=C2=A0 =C2=A0 are config=3Dtrue) need to be generated before the server kno= ws=C2=A0if any instances

=C2=A0 =C2=A0 of the config=3Dfalse node= s exist, and pass NACM and other filtering.

=C2=A0 =C2=A0 Since c= onfig=3Dfalse nodes can never contain config=3Dtrue nodes, the pruning
=C2=A0 =C2=A0 for current <get-config> is trivial.

Few observations:

=C2=A0 - the distinction between fields = and resources is artificial and not useful.

=C2=A0 =C2=A0 My impl= ementation is aligning with <get2> and just treating each nest level<= /div>

=C2=A0 =C2=A0 as a new level wrt/retrieval filtering

=C2=A0 = - netconf-monitoring and notifications are supported (except start-session<= br>=C2=A0 =C2=A0 and end-session are not sent). =C2=A0NETCONF monitoring is= somewhat deficient

=C2=A0 =C2=A0 for multiple protocols. =C2=A0It is not clear which counters = (if any) apply to YANG-API

=C2=A0 =C2=A0 requests.

= =C2=A0- It is not clear when a 404 Not Found status would be returned. The = draft
=C2=A0 =C2=A0says to return 400 Bad Request for unknown resources.=

Note that not all those resources may be 'useful' to support, the closer you get to the root, the larger the data gets one is operating
on.

The server may need to restrict how= many resources can be edited at once.

/js

PS: Did you really mean this:

=C2=A0 =C2=A0A RESTful client using YANG-API will not use any data modellin= g
=C2=A0 =C2=A0language to define the application-specific content of the API= . =C2=A0The
=C2=A0 =C2=A0client would discover each new child resource as it traverses = the
=C2=A0 =C2=A0URIs return as Location IDs to discover the server capabilitie= s.

No -- this should have been removed.

<= /div>
Andy

--14dae9340fe1a2566504d588eb48-- From j.schoenwaelder@jacobs-university.de Tue Feb 12 09:29:33 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E1121F8FE6 for ; Tue, 12 Feb 2013 09:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6ZUS2XD9cPJ for ; Tue, 12 Feb 2013 09:29:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFAC21F8FFE for ; Tue, 12 Feb 2013 09:29:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3453720BDB; Tue, 12 Feb 2013 18:29:32 +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 FFSpkv07_Aa7; Tue, 12 Feb 2013 18:29:32 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C539620A6D; Tue, 12 Feb 2013 18:29:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D4B842479D2F; Tue, 12 Feb 2013 18:29:37 +0100 (CET) Date: Tue, 12 Feb 2013 18:29:37 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130212172935.GB3061@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20130212151402.GA2752@elstar.local> <20130212.163921.1368938996418479237.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130212.163921.1368938996418479237.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 12 Feb 2013 17:29:34 -0000 On Tue, Feb 12, 2013 at 04:39:21PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > I have a question concerning the YANG API draft. If I have a data model > > that is nested lets say three levels deep, > > > > a { > > b { > > c { > > } > > } > > } > > > > does a server need to implement all possible datastore resources, > > that is: > > > > /yang-api/datastore/a > > /yang-api/datastore/a/b > > /yang-api/datastore/a/b/c > > > > Currently the answer is "yes". But there is an open issue listed in > section 12 > > o Should every YANG data node be a data resource and every YANG RPC > statement an operation resource? Is a YANG extension needed to > allow data modeler control of resource boundaries? > > Maybe you have some experience regarding this? I would not say experience, just that it sounds a bit too much. ;-) > > PS: Did you really mean this: > > > > A RESTful client using YANG-API will not use any data modelling > > language to define the application-specific content of the API. The > > client would discover each new child resource as it traverses the > > URIs return as Location IDs to discover the server capabilities. > > This goes back to what RESTful really means. It seems that from a > pure REST point of view, clients should treat the URIs as opaque > strings. A proper RESTful client would never construct a URI; it > would just follow links. YANG-API supports such clients, while at the > same time it also supports clients that do construct URIs. But this text seems to be in conflict of lots of stuff that follows. Anyway, why not have the resource URLs derived from the data model but allow servers to announce the resources they actually provide. The client would then discover whether a server only implements /yang-api/datastore/a/b or multiple of those nested resources. Of course, this moves some work towards the client since the client now needs to adapt to what the server provides. But servers not running a full-blown NETCONF engine in the back will likely become somewhat simpler. /js PS: I have no implementation experience with this yet. So I am just asking questions at the moment (although there are reasons for asking these questions ;-). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Tue Feb 12 10:42:32 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD42A21F909B for ; Tue, 12 Feb 2013 10:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm5ZKc6s9b5Y for ; Tue, 12 Feb 2013 10:42:30 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 843C521F9097 for ; Tue, 12 Feb 2013 10:42:30 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKURqNFpoY5FrCfgHU42hS2b6H0QlBkH+t@postini.com; Tue, 12 Feb 2013 10:42:30 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 12 Feb 2013 10:40:13 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 12 Feb 2013 10:40:13 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.16) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 12 Feb 2013 10:42:57 -0800 Received: from mail178-va3-R.bigfish.com (10.7.14.250) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 18:40:12 +0000 Received: from mail178-va3 (localhost [127.0.0.1]) by mail178-va3-R.bigfish.com (Postfix) with ESMTP id E995FC0121 for ; Tue, 12 Feb 2013 18:40:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zz4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3 (MessageSwitch) id 1360694410811315_3375; Tue, 12 Feb 2013 18:40:10 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.236]) by mail178-va3.bigfish.com (Postfix) with ESMTP id C090B380086; Tue, 12 Feb 2013 18:40:10 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Feb 2013 18:40:10 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.234]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0263.000; Tue, 12 Feb 2013 18:40:08 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Martin Bjorklund , Andy Bierman Thread-Topic: [Netconf] yang api question Thread-Index: AQHOCTO2rUgx04KRvEKD7WPPpqZHUJh2W9mAgAAez4D//7/egA== Date: Tue, 12 Feb 2013 18:40:07 +0000 Message-ID: In-Reply-To: <20130212172935.GB3061@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <5724972FE96CB54FB3CECE4E82321E7D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%JACOBS-UNIVERSITY.DE$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TAIL-F.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:42:32 -0000 > /yang-api/datastore/a > /yang-api/datastore/a/b > /yang-api/datastore/a/b/c When we were designing the REST API for our NMS, an ex-colleague of mine related horror-stories about how this strategy played out for him before. Essentially, he said the bookkeeping was a nightmare. Based on this we decided to use FILTERING for granular-reads and PATCH for granular-writes. That said, we also partitioned our resources as being either an "object" or a "collection" (though we support both primary and secondary collections). For instance, in our system, the following would be legal resources: /users (a primary collection of user-hrefs with some pull-thru data) /users/33 (user #33) /alerts (a primary collection of alert-hrefs with some pull-thru data) /alerts/21 (alert #21) /users/33/alerts (a secondary-collection of user 33's alerts) /users/33/alerts/21 (an href to alert #21, this resource could be DELETE-ed) While none of the following would be legal: /users/33/name /users/33/name/first /users/33/name/last /users/33/address /users/33/address/street /users/33/address/city /users/33/address/state A couple comments about our strategy: 1. We always use system-generated ids for primary keys. We find this helps maintain referential integrity while not being overbearing, since the hrefs are always returned (clients don't have to cook those URLs). We also support secondary keys so collections can be conveniently searched (i.e. find users with last name "smith" and live on a street that contains the substring "parkway") 2. Each of our resources (i.e. objects and collections) are strongly-typed. We use a custom media-type that maps directly to a data-model - we use=20 XSD, but there's no reason why it couldn't be YANG. >>This goes back to what RESTful really means. It seems that from a >> pure REST point of view, clients should treat the URIs as opaque >> strings. A proper RESTful client would never construct a URI; it >> would just follow links. YANG-API supports such clients, while at the >> same time it also supports clients that do construct URIs. We found that this Fielding's vision for HATEOAS was only realizable if there were standard media-types for everything. In the world of web-browsers, it's conceivable to have media-type definitions for all the various image/sound/video resources, and the Atom Protocol does a decent job for RSS feeds, but the reality is that most our clients are NOT generic web-browsers, they are NMS/OSS apps - that said, our NMS's web-based GUI does use the REST API too, but only after downloading tons of business-logic specific JavaScript (far from being generic). This is why we decided on using custom media-types... Thanks, Kent From andy@yumaworks.com Tue Feb 12 10:59:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2221F90D0 for ; Tue, 12 Feb 2013 10:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdNST9KXPfNR for ; Tue, 12 Feb 2013 10:59:50 -0800 (PST) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7803B21F90CB for ; Tue, 12 Feb 2013 10:59:50 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so384360iaf.14 for ; Tue, 12 Feb 2013 10:59:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=iF/2/Qp215r7XFMYaxq3hXs4sH4uEywUU+BH1jv19ZE=; b=E5cikuJiM/vpPSvuUip8Zg8GUrYhP2PbXnduK6MCqt/1PKOcqMQgvKu7b4vuXTqDr6 uI9viyosLBkPCH4k9ITDI3I7iymFDhQmbYgpaK1NTSOo6v0FLEi9ivTOm8zys52CoV64 ycU+Czs+QkC93j2qjetr0F5ucGeWK80XKVaLWurQDSxc4wQcGDY6Gb3Y4zJ+zkvdOnoF nj+/ohOybD8wWUoVLYwv9HC5Fr8+WBUTOotKgbgv88D+1B15Qr8kRfi5SICbdk7+Q/m3 nwjij5scaAY0GnLleD3GD7CsrCDWz5yJrzKE+2sFXXACZZ6mJ0aMhG4fngnkclC5Nb/O NPhg== MIME-Version: 1.0 X-Received: by 10.42.92.72 with SMTP id s8mr25341015icm.0.1360695581451; Tue, 12 Feb 2013 10:59:41 -0800 (PST) Received: by 10.231.93.132 with HTTP; Tue, 12 Feb 2013 10:59:41 -0800 (PST) In-Reply-To: <20130212172935.GB3061@elstar.local> References: <20130212151402.GA2752@elstar.local> <20130212.163921.1368938996418479237.mbj@tail-f.com> <20130212172935.GB3061@elstar.local> Date: Tue, 12 Feb 2013 10:59:41 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org Content-Type: multipart/alternative; boundary=90e6ba5bba1dc7a42f04d58ba090 X-Gm-Message-State: ALoCoQlz9LxT1an1UBRrVGVq7aXwWPCpunDwrxp8FcpM9N5VfaoPkbRFa4FhmuPh7mUuihMDMhOd Subject: Re: [Netconf] yang api question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:59:52 -0000 --90e6ba5bba1dc7a42f04d58ba090 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 12, 2013 at 9:29 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Feb 12, 2013 at 04:39:21PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > I have a question concerning the YANG API draft. If I have a data model > > > that is nested lets say three levels deep, > > > > > > a { > > > b { > > > c { > > > } > > > } > > > } > > > > > > does a server need to implement all possible datastore resources, > > > that is: > > > > > > /yang-api/datastore/a > > > /yang-api/datastore/a/b > > > /yang-api/datastore/a/b/c > > > > > > > Currently the answer is "yes". But there is an open issue listed in > > section 12 > > > > o Should every YANG data node be a data resource and every YANG RPC > > statement an operation resource? Is a YANG extension needed to > > allow data modeler control of resource boundaries? > > > > Maybe you have some experience regarding this? > > I would not say experience, just that it sounds a bit too much. ;-) > > Correct. Some options: 1) exclude a hard-wired set (like all netconf, create-subscription) 2) create a YANG extension to tag the rpc-stmts that should be accessible via YANG-API 3) let the vendor choose There isn't any extra implementation cost to allowing access to all the RPCs that NETCONF can invoke -- just a matter if is the right thing to do or not for YANG-API. I think (3) is good enough. Andy > > PS: Did you really mean this: > > > > > > A RESTful client using YANG-API will not use any data modelling > > > language to define the application-specific content of the API. The > > > client would discover each new child resource as it traverses the > > > URIs return as Location IDs to discover the server capabilities. > > > > This goes back to what RESTful really means. It seems that from a > > pure REST point of view, clients should treat the URIs as opaque > > strings. A proper RESTful client would never construct a URI; it > > would just follow links. YANG-API supports such clients, while at the > > same time it also supports clients that do construct URIs. > > But this text seems to be in conflict of lots of stuff that follows. > Anyway, why not have the resource URLs derived from the data model but > allow servers to announce the resources they actually provide. The client > would then discover whether a server only implements > > /yang-api/datastore/a/b > > or multiple of those nested resources. Of course, this moves some work > towards the client since the client now needs to adapt to what the > server provides. But servers not running a full-blown NETCONF engine > in the back will likely become somewhat simpler. > > /js > > PS: I have no implementation experience with this yet. So I am just > asking questions at the moment (although there are reasons for > asking these questions ;-). > > -- > 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 > --90e6ba5bba1dc7a42f04d58ba090 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 12, 2013 at 9:29 AM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, Feb 12, 2013 at 04:39:21PM +0100, Ma= rtin Bjorklund wrote:
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > Hi,
> >
> > I have a question concerning the YANG API draft. If I have a data= model
> > that is nested lets say three levels deep,
> >
> > a {
> > =C2=A0 b {
> > =C2=A0 =C2=A0 c {
> > =C2=A0 =C2=A0 }
> > =C2=A0 }
> > }
> >
> > does a server need to implement all possible datastore resources,=
> > that is:
> >
> > =C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a
> > =C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a/b
> > =C2=A0 =C2=A0 =C2=A0/yang-api/datastore/a/b/c
> >
>
> Currently the answer is "yes". =C2=A0But there is an open is= sue listed in
> section 12
>
> =C2=A0 =C2=A0o =C2=A0Should every YANG data node be a data resource an= d every YANG RPC
> =C2=A0 =C2=A0 =C2=A0 statement an operation resource? =C2=A0Is a YANG = extension needed to
> =C2=A0 =C2=A0 =C2=A0 allow data modeler control of resource boundaries= ?
>
> Maybe you have some experience regarding this?

I would not say experience, just that it sounds a bit too much. ;-)

=

Correct.
Some options:
=C2=A0 1) exclude a hard-wired set (like all netconf, create-subscription)=

=C2=A0 2) create a YANG extension to tag the rpc-stmts that should
=C2=A0 =C2=A0 =C2=A0 be accessible via YANG-API
=C2=A0 3) = let the vendor choose

There isn't any extra im= plementation cost to allowing access to

all the RPCs that NETCONF can invoke -- just a matter if is
= the right thing to do or not for YANG-API.

I think= (3) is good enough.

Andy

> > PS: Did you really mean this:
> >
> > =C2=A0 =C2=A0A RESTful client using YANG-API will not use any dat= a modelling
> > =C2=A0 =C2=A0language to define the application-specific content = of the API. =C2=A0The
> > =C2=A0 =C2=A0client would discover each new child resource as it = traverses the
> > =C2=A0 =C2=A0URIs return as Location IDs to discover the server c= apabilities.
>
> This goes back to what RESTful really means. =C2=A0It seems that from = a
> pure REST point of view, clients should treat the URIs as opaque
> strings. =C2=A0A proper RESTful client would never construct a URI; it=
> would just follow links. =C2=A0YANG-API supports such clients, while a= t the
> same time it also supports clients that do construct URIs.

But this text seems to be in conflict of lots of stuff that follows.
Anyway, why not have the resource URLs derived from the data model but
allow servers to announce the resources they actually provide. The client would then discover whether a server only implements

=C2=A0 /yang-api/datastore/a/b

or multiple of those nested resources. Of course, this moves some work
towards the client since the client now needs to adapt to what the
server provides. But servers not running a full-blown NETCONF engine
in the back will likely become somewhat simpler.

/js

PS: I have no implementation experience with this yet. So I am just
=C2=A0 =C2=A0 asking questions at the moment (although there are reasons fo= r
=C2=A0 =C2=A0 asking these questions ;-).

--
Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University = Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br= emen, Germany
Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi= ty.de/>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--90e6ba5bba1dc7a42f04d58ba090-- From balazs.lengyel@ericsson.com Tue Feb 19 01:41:38 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1926B21F87A4 for ; Tue, 19 Feb 2013 01:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzJ0Bh4XxbIN for ; Tue, 19 Feb 2013 01:41:37 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40FC021F8692 for ; Tue, 19 Feb 2013 01:41:37 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-67-512348d09b0c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A8.59.10459.0D843215; Tue, 19 Feb 2013 10:41:36 +0100 (CET) Received: from [159.107.197.133] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 19 Feb 2013 10:41:36 +0100 Message-ID: <512348CF.1020402@ericsson.com> Date: Tue, 19 Feb 2013 10:41:35 +0100 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: netconf@ietf.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOJMWRmVeSWpSXmKPExsUyM+Jvje4FD+VAg3075CymbrrN6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ3HmtgKtnFWzFn4gLWBcSl7FyMnh4SAicT1rz2sELaYxIV7 69m6GLk4hAROMkq0vOxngnDWMkpcfrMKrIpXQFtiY9MqFhCbRUBVYtma38wgNpuAkcTU/vNg cVGBKIn3V5uYIeoFJU7OfAIWFxEQkTi64S3YZmEBU4kLlw6BxZkFbCUuzLkOZctLbH87B6xX SEBD4uGFv6wTGPlmIRk1C0nLLCQtCxiZVzGy5yZm5qSXG25iBAbOwS2/dXcwnjoncohRmoNF SZw3zPVCgJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG1rD9pWedLh/zF7p09V6HOuOhsCsN hr1CBRY3CqbfyLty3elN8PG5c01Mko+nPHM2fb/4s+bVZUlyl65MrkiruNhhG7Rkn7mvcc2b 0iVfQoL+Om2KCt8Wy3+yK957249vEtd/77HOWiA0zXmqVFVFTdgH5gmlzJPaIw5cW1x8ff/J M5Zbvlx+oMRSnJFoqMVcVJwIANoZsHXqAQAA Subject: [Netconf] Long lived security Sessions a security risk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:41:38 -0000 Hello All, The netconf notification RFC5277 assumes we have a long running open Netconf session where the node can send its notifications. As the node can have the need to send notifications any time, this means that notification sessions are potentially long lived, being open for days, or even months. I was wondering, is it not a security risk to keep such long lived sessions? 1) The encryption might be broken after some time (OK SSH MAY have rekeying after some time) 2) Reauthentication might be needed after some time. E.g. to avoid the risk from compromised user identities or to allow changes in user identities, periodic re-authentication might be needed. 3) Periodic reauthorisation might be needed after some time for the same reason. What is the best practice to handle the above issues? Shall the Notification session be periodically reestablished? The security considerations in RFC5277 do not say anything about the problem. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From kwatsen@juniper.net Tue Feb 19 08:10:51 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E917A21F8CD2 for ; Tue, 19 Feb 2013 08:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0vCCxypwm4S for ; Tue, 19 Feb 2013 08:10:51 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 3E71421F8B97 for ; Tue, 19 Feb 2013 08:10:51 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUSOkCdtR2KITgZQABzSyJFFimtyvDs5G@postini.com; Tue, 19 Feb 2013 08:10:51 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 19 Feb 2013 08:07:35 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 19 Feb 2013 08:07:34 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 19 Feb 2013 08:16:13 -0800 Received: from mail263-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 16:07:33 +0000 Received: from mail263-ch1 (localhost [127.0.0.1]) by mail263-ch1-R.bigfish.com (Postfix) with ESMTP id 4E62D90009E for ; Tue, 19 Feb 2013 16:07:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -26 X-BigFish: PS-26(zzbb2dI98dI9371I1432I62a3I14ffIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail263-ch1 (localhost.localdomain [127.0.0.1]) by mail263-ch1 (MessageSwitch) id 13612900506959_24817; Tue, 19 Feb 2013 16:07:30 +0000 (UTC) Received: from CH1EHSMHS004.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail263-ch1.bigfish.com (Postfix) with ESMTP id EA41F1700060; Tue, 19 Feb 2013 16:07:29 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CH1EHSMHS004.bigfish.com (10.43.70.4) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 16:07:29 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0263.000; Tue, 19 Feb 2013 16:07:28 +0000 From: Kent Watsen To: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] Long lived security Sessions a security risk Thread-Index: AQHODoVtlyg0pwmb4E66F36gYNoAP5iBBY+A Importance: low X-Priority: 5 Date: Tue, 19 Feb 2013 16:07:27 +0000 Message-ID: In-Reply-To: <512348CF.1020402@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Netconf] Long lived security Sessions a security risk X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:10:52 -0000 SSH implementations since circa 2001 have implemented rekeying. Cryptographically, there is now never enough entropy lost for an attack. Your other concerns seem more a local policy decision - e.g. how often do you change the locks on your house? On 2/19/13 4:41 AM, "Balazs Lengyel" wrote: >Hello All, >The netconf notification RFC5277 assumes we have a long running open >Netconf session where the node can send its notifications. As the node >can have the need to send notifications any time, this means that >notification sessions are potentially long lived, being open for days, >or even months. I was wondering, is it not a security risk to keep such >long lived sessions? >1) The encryption might be broken after some time (OK SSH MAY have >rekeying after some time) >2) Reauthentication might be needed after some time. E.g. to avoid the >risk from compromised user identities or to allow changes in user >identities, periodic re-authentication might be needed. >3) Periodic reauthorisation might be needed after some time for the same >reason. > >What is the best practice to handle the above issues? Shall the >Notification session be periodically reestablished? The security >considerations in RFC5277 do not say anything about the problem. > >regards Balazs > >--=20 >Balazs Lengyel Ericsson Hungary Ltd. >System Manager >ECN: 831 7320 Tel: +36-1-437-7320 >Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > From internet-drafts@ietf.org Thu Feb 21 08:05:36 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9EF21F8ED1; Thu, 21 Feb 2013 08:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRxmnwUv4Gh8; Thu, 21 Feb 2013 08:05:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9D921F8EC8; Thu, 21 Feb 2013 08:05:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221160535.28854.3116.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 08:05:35 -0800 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:05:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Using the NETCONF Protocol over Transport Layer Security= (TLS) Author(s) : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-02.txt Pages : 20 Date : 2013-02-21 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure NETCONF exchanges. This document obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mehmet.ersue@nsn.com Thu Feb 21 10:14:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5212021F8EEA for ; Thu, 21 Feb 2013 10:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO5TPgStU32d for ; Thu, 21 Feb 2013 10:14:15 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 245BE21F8E7F for ; Thu, 21 Feb 2013 10:14:14 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1LIE9pM002365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Feb 2013 19:14:09 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1LIE88p003756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 19:14:09 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 21 Feb 2013 19:14:08 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.02.0328.009; Thu, 21 Feb 2013 19:14:08 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder , "mbadra@gmail.com" , ext Alan Luchuk Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-02.txt Thread-Index: AQHOEE1PPFY0HIx/MUa+szeL6mGMU5iEmrmw Date: Thu, 21 Feb 2013 18:14:07 +0000 Message-ID: References: <20130221160535.28854.3116.idtracker@ietfa.amsl.com> In-Reply-To: <20130221160535.28854.3116.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.118] 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: 2842 X-purgate-ID: 151667::1361470450-0000547A-BCBD2884/0-0/0-0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 18:14:16 -0000 Hi Juergen, Badra, Alan, I appreciate the draft you guys submitted. The document looks good and seem= s to be ready for WGLC.=20 > The identities etc. have been essentially copied from the SNMP=09 configuration model. Are we really happy with this reuse by=09 copying? If so, do we keep the SNMP configuration model names or=09 adapt them to the NETCONF context?=09 Reuse-by-copying is not satisfying. However, if there is no other proposal = I would adapt the configuration model names to NETCONF context (same for tl= s-fingerprint). > Shall we add support for call home, i.e., a device, after=09 initiating and establishing a TCP connection and executing the TLS=09 handshake, would switch role and subsequently act as a NETCONF=09 server. (This would likely also include new port numbers.) If we can provide a solution for the call home issue without causing much e= ffort I would suggest to go for it. Two small edits: s/the those/those/ s/and was/was/ Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > internet-drafts@ietf.org > Sent: Thursday, February 21, 2013 5:06 PM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration Working Group of = the IETF. >=20 > Title : Using the NETCONF Protocol over Transport Layer Securi= ty (TLS) > Author(s) : Mohamad Badra > Alan Luchuk > Juergen Schoenwaelder > Filename : draft-ietf-netconf-rfc5539bis-02.txt > Pages : 20 > Date : 2013-02-21 >=20 > Abstract: > The Network Configuration Protocol (NETCONF) provides mechanisms to > install, manipulate, and delete the configuration of network devices. > This document describes how to use the Transport Layer Security (TLS) > protocol to secure NETCONF exchanges. This document obsoletes RFC > 5539. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Tue Feb 26 14:04:29 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F8721F87D2 for ; Tue, 26 Feb 2013 14:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AF1ZC2MfM7tt for ; Tue, 26 Feb 2013 14:04:29 -0800 (PST) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id F396C21F87C3 for ; Tue, 26 Feb 2013 14:04:28 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKUS0xbPHTb40UGpaZEs1Wj5GFKO9uZJaz@postini.com; Tue, 26 Feb 2013 14:04:29 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 26 Feb 2013 14:00:13 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 26 Feb 2013 14:00:12 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.142) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 26 Feb 2013 14:02:23 -0800 Received: from mail10-db3-R.bigfish.com (10.3.81.228) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 22:00:10 +0000 Received: from mail10-db3 (localhost [127.0.0.1]) by mail10-db3-R.bigfish.com (Postfix) with ESMTP id C6F4D10039E for ; Tue, 26 Feb 2013 22:00:10 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zzc85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h8275bhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail10-db3 (localhost.localdomain [127.0.0.1]) by mail10-db3 (MessageSwitch) id 1361916008763434_22385; Tue, 26 Feb 2013 22:00:08 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.254]) by mail10-db3.bigfish.com (Postfix) with ESMTP id B6CED16004B for ; Tue, 26 Feb 2013 22:00:08 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 26 Feb 2013 22:00:04 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0263.000; Tue, 26 Feb 2013 22:00:03 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqQ== Date: Tue, 26 Feb 2013 22:00:03 +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.1.130117 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CD529A91224ACkwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Netconf] draft-kwatsen-conditional-enablement-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:04:29 -0000 --_000_CD529A91224ACkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable NETCONF WG, The following draft has been submitted for your consideration: http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 Thanks, Kent --_000_CD529A91224ACkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <74E43455D791314B87E571395940D87F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

NETCONF W= G,

The follo= wing draft has been submitted for your consideration:

&n= bsp; http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

Thanks,

Kent

--_000_CD529A91224ACkwatsenjunipernet_-- From andy@yumaworks.com Tue Feb 26 14:43:11 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED3C21F889C for ; Tue, 26 Feb 2013 14:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkgrb6fwYQ+Q for ; Tue, 26 Feb 2013 14:43:10 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 93E2721F8895 for ; Tue, 26 Feb 2013 14:43:10 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id k13so5035318iea.7 for ; Tue, 26 Feb 2013 14:43:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=u1wl8ceag6FRtUubX44cB7+3ZwBmMbhjSl7l595tY9Y=; b=kkXVqFcop719rajxpqRVNC+X5bCZhXxUfEtWYDkXli3nb5g1FIXtQ+5mtLDP2nksMR /HYyNWY9XdvGfa/K5xf8lbPVNgBQCkLHX1ZBOFN7VCSSKvfsrZie9PxuVkRFAMe3c+9e C72UEyaAwoIle7X3JkCQgSLekm1YyCw6Ob2y1gBc5q3HbCqg7Fovm8vJgokAHsPymwnh rUyhyXtKOzrYYcWgQ8Dl4ejx3BkrBiciUz9Zj12o+sX6wy9l9rTApMVtNM/sRr5HQgq/ FbJdkID4VIpQRlogy9Kae1RLKOCaaUmbTJrm2SWTxlNpWNSbdGk4SqietbCzvbmvbKAB zwYA== MIME-Version: 1.0 X-Received: by 10.42.91.209 with SMTP id q17mr6986580icm.50.1361918590142; Tue, 26 Feb 2013 14:43:10 -0800 (PST) Received: by 10.231.235.201 with HTTP; Tue, 26 Feb 2013 14:43:09 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 14:43:09 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=90e6ba5bbe13c76f9004d6a8612c X-Gm-Message-State: ALoCoQmLuuhPkF5hrgHqWtEPFh/Lbp9Ax+0bdZIILYQitNX1+1/0uLrHiMDtVd0EG4pSAiMTMqRc Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 22:43:11 -0000 --90e6ba5bbe13c76f9004d6a8612c Content-Type: text/plain; charset=UTF-8 Hi Kent, I'll bite first ;-) YANG can already do this with when-stmt and XPath. I know when-stmt for config=true can only point to other config=true, but I look at the "platform config" an an access control issue, and it is just more config that is only set by a privileged system user. groups { my-group-g1 { system { hostname xyz; } when { model tx1000; routing-engine re0; time 2am to 4am; } } } If the 'model', routine-engine', and range begin/end variables were YANG leafs then when-stmt can be used to describe the condition. IMO, inventing a new expression syntax when we already have 1 is not needed. Andy On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen wrote: > NETCONF WG, > > The following draft has been submitted for your consideration: > > http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --90e6ba5bbe13c76f9004d6a8612c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kent,

I'll bite first ;-)

YANG can already do this with when-stmt and XPath.

I know when-= stmt for config=3Dtrue can only point to other config=3Dtrue,

but= I look at the "platform config" an an access control issue, and<= /div>

it is just more config that is only set by a privileged system user.

     groups {
           my-group-g1 {
               system {
                   hostname xyz;
               }
           when {
               model tx1000;
               routing-engine re0;
               time 2am to 4am;
           }
         }
       }

If the 'model', routine-engin=
e', and range begin/end variables were YANG leafs
then when-stmt can be used=
 to describe the condition.

IMO, inventing a new expression syntax when we already have 1=
 is not needed.

Andy

On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen <kwatsen@juniper.net&g= t; wrote:

NETCONF WG,

The following draft has been submitt= ed for your consideration:

=C2=A0 =C2=A0 = http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

Thanks,

Kent

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

--90e6ba5bbe13c76f9004d6a8612c-- From kwatsen@juniper.net Tue Feb 26 16:38:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4929821F86DE for ; Tue, 26 Feb 2013 16:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EypkmFsffFEx for ; Tue, 26 Feb 2013 16:38:52 -0800 (PST) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7E59021F86D8 for ; Tue, 26 Feb 2013 16:38:52 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUS1VnDbo53HwFVdbtxHzNNpE1/inEbt3@postini.com; Tue, 26 Feb 2013 16:38:52 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 26 Feb 2013 16:38:36 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 26 Feb 2013 16:38:35 -0800 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 26 Feb 2013 16:40:46 -0800 Received: from mail10-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 27 Feb 2013 00:38:35 +0000 Received: from mail10-tx2 (localhost [127.0.0.1]) by mail10-tx2-R.bigfish.com (Postfix) with ESMTP id 22DAF3E03AC for ; Wed, 27 Feb 2013 00:38:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -23 X-BigFish: PS-23(zz98dI9371Ic85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch18de19h1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1155h) Received: from mail10-tx2 (localhost.localdomain [127.0.0.1]) by mail10-tx2 (MessageSwitch) id 1361925513364054_31364; Wed, 27 Feb 2013 00:38:33 +0000 (UTC) Received: from TX2EHSMHS018.bigfish.com (unknown [10.9.14.254]) by mail10-tx2.bigfish.com (Postfix) with ESMTP id 54DA6C0065; Wed, 27 Feb 2013 00:38:33 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by TX2EHSMHS018.bigfish.com (10.9.99.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 27 Feb 2013 00:38:33 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.117]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0263.000; Wed, 27 Feb 2013 00:38:31 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] draft-kwatsen-conditional-enablement-00 Thread-Index: AQHOFGyhBDGXg9PhXkKLEOJGTSvqqZiMvHOA///MZgA= Date: Wed, 27 Feb 2013 00:38:30 +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.3.1.130117 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CD52BE5822527kwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 00:38:53 -0000 --_000_CD52BE5822527kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, Thanks for your comments and biting first ;) I think the with YANG's when-statement is that it applies to the schema as = a whole, whereas this solution works on distinct data elements. For instan= ce, envision a list of interfaces, we may want some (but not all) interfac= es to enabled conditionally, and then, perhaps with different policies. Thanks, Kent From: Andy Bierman > Date: Tuesday, February 26, 2013 5:43 PM To: Kent Watsen > Cc: NetConf > Subject: Re: [Netconf] draft-kwatsen-conditional-enablement-00 Hi Kent, I'll bite first ;-) YANG can already do this with when-stmt and XPath. I know when-stmt for config=3Dtrue can only point to other config=3Dtrue, but I look at the "platform config" an an access control issue, and it is just more config that is only set by a privileged system user. groups { my-group-g1 { system { hostname xyz; } when { model tx1000; routing-engine re0; time 2am to 4am; } } } If the 'model', routine-engine', and range begin/end variables were YANG le= afs then when-stmt can be used to describe the condition. IMO, inventing a new expression syntax when we already have 1 is not needed= . Andy On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen > wrote: NETCONF WG, The following draft has been submitted for your consideration: http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_CD52BE5822527kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <7FB77EC32957984E9B2CA9421E9ACBC7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Andy,

Thanks for your comments and biting first ;)

I think the with YANG's when-statement is that it applies to the schem= a as a whole, whereas this solution works on distinct data elements. = For instance, envision a list of interfaces, we may want some (but not all)= interfaces to enabled conditionally, and then, perhaps with different policies.

Thanks,

Kent

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 26, 2013 5:= 43 PM
To: Kent Watsen <kwatsen@juniper.net>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] draft-kwatse= n-conditional-enablement-00

Hi Kent,

I'll bite first ;-)

YANG can already do this with when-stmt and XPath.

I know when-stmt for config=3Dtrue can only point to other config=3Dtr= ue,

but I look at the "platform config" an an access control iss= ue, and

it is just more config that is only set by a privileged system user.

     groups {
           my-group-g1 {
               system {
                   hostname xyz;
               }
           when {
               model tx1000;
               routing-engine re0;
               time 2am to 4am;
           }
         }
       }

If the 'model', routine-engine', and range begin/end varia=
bles were YANG leafs
then when-stmt can be used to describe the condition.

IMO, inventing a new expression syntax when we already have 1=
 is not needed.

Andy

On Tue, Feb 26, 2013 at 2:00 PM, Kent Watsen <kwatsen@junipe= r.net> wrote:

NETCONF WG,

The following draft has been submitt= ed for your consideration:

http://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00

Thanks,

Kent

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

--_000_CD52BE5822527kwatsenjunipernet_-- From mehmet.ersue@nsn.com Thu Feb 28 05:37:35 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EA721F85E8 for ; Thu, 28 Feb 2013 05:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.564 X-Spam-Level: X-Spam-Status: No, score=-106.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX9Uq0uL9Wpw for ; Thu, 28 Feb 2013 05:37:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D26D321F853A for ; Thu, 28 Feb 2013 05:37:33 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1SDbOfu030839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Feb 2013 14:37:27 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1SDbIUq009142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Feb 2013 14:37:24 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Feb 2013 14:37:21 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 14:37:20 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Agenda for IETF #86 NETCONF Session Thread-Index: AQHOFbi7k007uQev70+iuWB7r6osUg== Date: Thu, 28 Feb 2013 13:37:19 +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.124] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F80520EEDEMUMBX005nsnintr_" 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: 4901 X-purgate-ID: 151667::1362058648-0000547A-812AB7D3/0-0/0-0 Subject: [Netconf] Agenda for IETF #86 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 13:37:35 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F80520EEDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we uploaded the agenda for the NETCONF session in IETF #86. http://www.ietf.org/proceedings/86/agenda/agenda-86-netconf Please let us know your comments and/or any slot requests. Mehmet & Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F80520EEDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft Agenda for IETF #74 NETCONF Session

Dear NETCONF WG,<= /span>

we uploaded the agenda for t= he NETCONF session in IETF #86.

http://www.ietf.org/proceedings= /86/agenda/agenda-86-netconf

Please let us know your comm= ents and/or any slot requests.

Mehmet & Bert

--_000_E4DE949E6CE3E34993A2FF8AE79131F80520EEDEMUMBX005nsnintr_-- From mehmet.ersue@nsn.com Thu Feb 28 05:44:16 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB48221F8A96 for ; Thu, 28 Feb 2013 05:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.566 X-Spam-Level: X-Spam-Status: No, score=-106.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okksIU0EeVHH for ; Thu, 28 Feb 2013 05:44:16 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 20E8F21F8A40 for ; Thu, 28 Feb 2013 05:44:15 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r1SDiEkP016586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 28 Feb 2013 14:44:14 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r1SDiEHf021948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Feb 2013 14:44:14 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 28 Feb 2013 14:44:14 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.216]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 14:44:13 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WGLC for draft-ietf-netconf-rfc5539bis-02 Thread-Index: Ac2Saa4rBrh95h0ERw6mxs3XcPWMZSDT23Dg Date: Thu, 28 Feb 2013 13:44:12 +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.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: 463 X-purgate-ID: 151667::1362059054-0000547A-F773B3C7/0-0/0-0 Subject: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 13:44:17 -0000 Dear NETCONF WG, rfc5539bis authors submitted the document draft-ietf-netconf-rfc5539bis-02 addressing the issues we discussed in the last meeting=20 (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02). This is a new WGLC for the RFC5539bis document, which is going to be published on the standards track and will obsolete RFC 5539.=20 Please review the document and comment by March 14, 2013 (any timezone). Thank you. Mehmet & Bert From j.schoenwaelder@jacobs-university.de Thu Feb 28 05:53:15 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B8221F88A2 for ; Thu, 28 Feb 2013 05:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbmPY8mUkOGA for ; Thu, 28 Feb 2013 05:53:05 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CA08321F87EA for ; Thu, 28 Feb 2013 05:53:00 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CF8D620BE1; Thu, 28 Feb 2013 14:52:59 +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 aFO5xqWNMEqw; Thu, 28 Feb 2013 14:52:59 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C58C205A3; Thu, 28 Feb 2013 14:52:59 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E313A24C515A; Thu, 28 Feb 2013 14:53:08 +0100 (CET) Date: Thu, 28 Feb 2013 14:53:08 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20130228135308.GA85320@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netconf@ietf.org" Subject: Re: [Netconf] WGLC for draft-ietf-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 13:53:15 -0000 On Thu, Feb 28, 2013 at 01:44:12PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > rfc5539bis authors submitted the document draft-ietf-netconf-rfc5539bis-02 > addressing the issues we discussed in the last meeting > (http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-02). > > This is a new WGLC for the RFC5539bis document, which is going to be > published on the standards track and will obsolete RFC 5539. > > Please review the document and comment by March 14, 2013 (any > timezone). Thank you. Input on the open issues (appendix A.1) would also be very welcome. /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 Thu Feb 28 08:27:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E128821F857E for ; Thu, 28 Feb 2013 08:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kum2BYLrcV3x for ; Thu, 28 Feb 2013 08:27:26 -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 69E6E21F854D for ; Thu, 28 Feb 2013 08:27:25 -0800 (PST) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UB6KJ-0003RI-Sa for netconf@ietf.org; Thu, 28 Feb 2013 17:27:24 +0100 Received: from kitten.ripe.net ([193.0.1.240] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1UB6KJ-0006Wd-MM for netconf@ietf.org; Thu, 28 Feb 2013 17:27:23 +0100 Message-ID: <512F856B.1030506@bwijnen.net> Date: Thu, 28 Feb 2013 17:27:23 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20130228 clean 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: 86ab03e524994f79ca2c75a176445dd44c0c3bdf13ce10cbf39d0be2c52e1e46 Subject: [Netconf] test - pls ignore X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 16:27:27 -0000 From teramoto@net.ist.i.kyoto-u.ac.jp Thu Feb 28 23:32:00 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46AC21F85BF for ; Thu, 28 Feb 2013 23:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x5D+1-mhfAl for ; Thu, 28 Feb 2013 23:31:59 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [133.3.248.237]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0321F858E for ; Thu, 28 Feb 2013 23:31:59 -0800 (PST) Received: from smtp-auth.kuins.kyoto-u.ac.jp (smtp-auth.kuins.kyoto-u.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE451100B0; Fri, 1 Mar 2013 16:31:57 +0900 (JST) Received: from h134.104.228.10.103219.vlan.kuins.net (h134.104.228.10.103219.vlan.kuins.net [10.228.104.134]) by smtp-auth.kuins.kyoto-u.ac.jp (Postfix) with ESMTP id A8DB4100A9; Fri, 1 Mar 2013 16:31:57 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 $1499$) From: Teramoto Yasuhiro Date: Fri, 1 Mar 2013 16:31:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130225212537.8997.433.idtracker@ietfa.amsl.com> To: netconf@ietf.org X-Mailer: Apple Mail (2.1499) Cc: Yasuo Okabe Subject: [Netconf] draft-teramoto-experience-network-management-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 07:32:00 -0000 Dear all, We submitted this I-D that describes the experience from creating a local area network management system. This document includes a discussion about my thought on the NETCONF = protocol. We think this may give some information to you. > Title: Experience of Designing Network Management = System > Creation date: 2013-02-26 > Number of pages: 10 > URL: = http://www.ietf.org/internet-drafts/draft-teramoto-experience-network-mana= gement-01.txt > Status: = http://datatracker.ietf.org/doc/draft-teramoto-experience-network-manageme= nt > Htmlized: = http://tools.ietf.org/html/draft-teramoto-experience-network-management-01= >=20 > Abstract: > This document describes our experiences from designing and > implementing a large-scale local area network management system = using > mainly NETCONF. We designed the data models for device > configurations and implemented NETCONF client to centrally control > multiple devices of various vendors. The document provides insight > on strong and weak points of current NETCONF approach. The document > also makes some recommendations about NETCONF and future network > management protocols.