From mehmet.ersue@nsn.com Thu Aug 1 02:16:25 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 2B6EC21F85B3 for ; Thu, 1 Aug 2013 02:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBPL-7ByXJ63 for ; Thu, 1 Aug 2013 02:16:20 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59021E80AD for ; Thu, 1 Aug 2013 02:16:19 -0700 (PDT) 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 r719GHws013314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Aug 2013 11:16:18 +0200 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 r719G7vv009427 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 11:16:17 +0200 Received: from DEMUHTC020.nsn-intra.net (10.159.42.51) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 1 Aug 2013 11:16:08 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC020.nsn-intra.net ([10.159.42.51]) with mapi id 14.03.0123.003; Thu, 1 Aug 2013 11:16:08 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: NETCONF Thread-Topic: Summary of the NETCONF Session at IETF 87 Thread-Index: Ac6Ol8FhCpwfktBtTgWBoogQDuH6hg== Date: Thu, 1 Aug 2013 09:16:08 +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.98] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8163F66DEMUMBX005nsnintr_" 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: 9431 X-purgate-ID: 151667::1375348578-00002EAE-812F31BF/0-0/0-0 Subject: [Netconf] Summary of the NETCONF Session at IETF 87 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, 01 Aug 2013 09:16:25 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8163F66DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below is a summary and action items from the NETCONF WG session on July 31,= 2013 in Berlin, Germany. The agenda is available at: http://www.ietf.org/p= roceedings/87/agenda/agenda-87-netconf - We had approx. 51 participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We went through the chartered WG items and had a discussion also on three= non-chartered documents. - Note takers were: Lada Lhotka and Robert Varga. The Jabber scribe was Pet= er Saint-Andre. Status of the documents (http://www.ietf.org/proceedings/87/slides/slides-8= 7-netconf-6.ppt): NETCONF Over TLS - RFC 5539bis has been updated addressing the issues and t= he call-home mechanism. Reverse SSH addressing the call-home mechanism has been adopted as WG item.= Long discussion on the maillist on security. Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause consiste= ncy issues if the base module gets updated repeatedly partly. To solve the = issue replacing the base module for an update has been proposed. Community = poll: 9 in favor, 5 against. AI: Check on the maillist. Option 3 for swapping the roles on slide 5 (http://www.ietf.org/proceedings= /87/slides/slides-87-netconf-7.pdf), i.e. swapping directly after establish= ing the TCP connection, has been supported by the security experts in the r= oom. Juergen will specify the 3rd option and the session discussion will be veri= fied on the maillist. A security review is needed and will be initiated onc= e the draft is ready. Juergen will further discuss potential security issue= s with TLS experts. The solution seems to be a generic solution but only fo= r network management scenarios. Next step is WGLC and TLS WG review. Andy Bierman on YANG API: Concerning the notifications we need to understan= d the need and the possible solutions. Kent Watsen is going to co-author. T= he community had already showed interest in diverse meetings. Once we have = a new draft available we can start discussing officially how to adopt. (htt= p://www.ietf.org/proceedings/87/slides/slides-87-netconf-0.pdf) Kent Watsen on Reverse Secure Shell: It was very useful that the security e= xperts for SSH were in the room. It has been stated that the configuration = of the NMS should be also mandatory. Issues to solve are authentication, in= itial secure state, validating the host key, identification and Zero-config= uration. The latter has been seen as essentially important and should be do= ne in a separate draft. Steve Hanna volunteered to work on this together wi= th Kent. Manuel configuration will be done in the Reverse SSH draft. Steve Hanna will further provide a draft on the applicability statement for= the TLS and SSH solutions. Kent will update the draft based on the session discussion and provide the = draft update for discussion and get comments of the security experts. Based on show-hands there is a huge interest to proceed with this draft as = discussed in the session. Tal Mizrahi on Time Capability in NETCONF: The time capability allows a tim= e-triggered configuration. Show-hands showed no hands in favor or opposed. = The draft should be taken again to the maillist for discussion. Robert Varga on Efficient XML Interchange Capability for NETCONF: 12 attend= ees were in favor and nobody against. As the WG cannot re-charter right now= the document should be further discussed and updated. Shouchuan Yang on NETCONF rpc-error extension: There were 2 persons in favo= r and 6 against. The draft should be further discussed on the maillist to w= in peoples interest. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8163F66DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
below is a summary and action items from the NETCONF WG session on Jul= y 31, 2013 in Berlin, Germany. The agenda is available at: htt= p://www.ietf.org/proceedings/87/agenda/agenda-87-netconf
 
- We had approx. 51 participants in the 2 hour NETCONF session,
- We reviewed the status of the WG,
- We went through the chartered WG items and had a discussion also on = three non-chartered documents.
- Note takers were: Lada Lhotka and Robert Varga. The Jabber scribe wa= s Peter Saint-Andre.
 
NETCONF Over TLS - RFC 5539bis has been updated addressing the issues = and the call-home mechanism.
Reverse SSH addressing the call-home mechanism has been adopted as WG = item. Long discussion on the maillist on security.
 
Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause con= sistency issues if the base module gets updated repeatedly partly. To solve= the issue replacing the base module for an update has been proposed. Commu= nity poll: 9 in favor, 5 against. AI: Check on the maillist.
Option 3 for swapping the roles on slide 5 (http://www.ietf.org/pro= ceedings/87/slides/slides-87-netconf-7.pdf), i.e. swapping directly aft= er establishing the TCP connection, has been supported by the security experts in the room.
Juergen will specify the 3rd option and the session discussion will be= verified on the maillist. A security review is needed and will be initiate= d once the draft is ready. Juergen will further discuss potential security = issues with TLS experts. The solution seems to be a generic solution but only for network management scenarios. N= ext step is WGLC and TLS WG review.
 
Andy Bierman on YANG API: Concerning the notifications we need to unde= rstand the need and the possible solutions. Kent Watsen is going to co-auth= or. The community had already showed interest in diverse meetings. Once we = have a new draft available we can start discussing officially how to adopt. (http://www.ietf.org/proceedin= gs/87/slides/slides-87-netconf-0.pdf)
 
Kent Watsen on Reverse Secure Shell: It was very useful that the secur= ity experts for SSH were in the room. It has been stated that the configura= tion of the NMS should be also mandatory. Issues to solve are authenticatio= n, initial secure state, validating the host key, identification and Zero-configuration. The latter has been se= en as essentially important and should be done in a separate draft. Steve H= anna volunteered to work on this together with Kent. Manuel configuration w= ill be done in the Reverse SSH draft.
Steve Hanna will further provide a draft on the applicability statemen= t for the TLS and SSH solutions.
Kent will update the draft based on the session discussion and provide= the draft update for discussion and get comments of the security experts.<= /div>
Based on show-hands there is a huge interest to proceed with this draf= t as discussed in the session.
 
Tal Mizrahi on Time Capability in NETCONF: The time capability allows = a time-triggered configuration. Show-hands showed no hands in favor or oppo= sed. The draft should be taken again to the maillist for discussion.
 
Robert Varga on Efficient XML Interchange Capability for NETCONF: 12 a= ttendees were in favor and nobody against. As the WG cannot re-charter righ= t now the document should be further discussed and updated.
 
Shouchuan Yang on NETCONF rpc-error extension: There were 2 persons in= favor and 6 against. The draft should be further discussed on the maillist= to win peoples interest.
&nbs= p;
Cheers,
Mehmet
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8163F66DEMUMBX005nsnintr_-- From j.schoenwaelder@jacobs-university.de Thu Aug 1 04:24:17 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 94CDB21E80AB for ; Thu, 1 Aug 2013 04:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPpDHu8M6tGY for ; Thu, 1 Aug 2013 04:24:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C00E321E80B2 for ; Thu, 1 Aug 2013 04:24:10 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4443020C06; Thu, 1 Aug 2013 13:23:56 +0200 (CEST) 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 kJ3_anrh5Rw4; Thu, 1 Aug 2013 13:23:56 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BD3CD20BFD; Thu, 1 Aug 2013 13:23:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B8EF127A2173; Thu, 1 Aug 2013 13:23:51 +0200 (CEST) Date: Thu, 1 Aug 2013 13:23:50 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20130801112350.GA25489@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , NETCONF 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 Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 01 Aug 2013 11:24:17 -0000 On Thu, Aug 01, 2013 at 09:16:08AM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > > Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause consistency issues if the base module gets updated repeatedly partly. To solve the issue replacing the base module for an update has been proposed. Community poll: 9 in favor, 5 against. AI: Check on the maillist. I think this is not stated well - there is no consistency issue in both options. Let me try to restate it in a neutral way: The WG discussed the usage of submodules and a single namespace for NETCONF configuration YANG models (current I-D) or the usage of separate modules with different namespaces. Community poll: 9 in favor of separate modules with different namespaces, 5 in favor of submodules with a single namespace. AI: Check on the maillist. /js PS: I love to have this recorded clearly so that later I can point to this. ;-) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Fri Aug 2 07:40:41 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 65BF511E8252 for ; Fri, 2 Aug 2013 07:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VL61kXrzOfzT for ; Fri, 2 Aug 2013 07:40:37 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9360F11E82F0 for ; Fri, 2 Aug 2013 07:40:36 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r72EeYNr004617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 2 Aug 2013 16:40:34 +0200 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r72EeYwF006319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 Aug 2013 16:40:34 +0200 Received: from DEMUHTC020.nsn-intra.net (10.159.42.51) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 2 Aug 2013 16:40:33 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC020.nsn-intra.net ([10.159.42.51]) with mapi id 14.03.0123.003; Fri, 2 Aug 2013 16:40:33 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] Summary of the NETCONF Session at IETF 87 Thread-Index: Ac6Ol8FhCpwfktBtTgWBoogQDuH6hgAAROcAAD0fAvA= Date: Fri, 2 Aug 2013 14:40:32 +0000 Message-ID: References: <20130801112350.GA25489@elstar.local> In-Reply-To: <20130801112350.GA25489@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.97] 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: 1763 X-purgate-ID: 151667::1375454434-0000471E-136B76BD/0-0/0-0 Cc: NETCONF Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 02 Aug 2013 14:40:41 -0000 Hi Juergen, the chairs agree with your correction. There is also a very short version available on the OPS Wiki provided to Be= noit as input for the IESG meeting: http://trac.tools.ietf.org/area/ops/trac/wiki/IETF87summary Cheers,=20 Mehmet=20 > -----Original Message----- > From: ext Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university= .de] > Sent: Thursday, August 01, 2013 1:24 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: NETCONF > Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 >=20 > On Thu, Aug 01, 2013 at 09:16:08AM +0000, Ersue, Mehmet (NSN - DE/Munich) > wrote: > > > > Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause > consistency issues if the base module gets updated repeatedly partly. To = solve the > issue replacing the base module for an update has been proposed. Communit= y poll: 9 > in favor, 5 against. AI: Check on the maillist. >=20 > I think this is not stated well - there is no consistency issue in > both options. Let me try to restate it in a neutral way: >=20 > The WG discussed the usage of submodules and a single namespace for > NETCONF configuration YANG models (current I-D) or the usage of > separate modules with different namespaces. Community poll: 9 in > favor of separate modules with different namespaces, 5 in favor > of submodules with a single namespace. AI: Check on the maillist. >=20 > /js >=20 > PS: I love to have this recorded clearly so that later I can point > to this. ;-) >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From jclarke@cisco.com Fri Aug 2 19:04: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 8667F21F9995 for ; Fri, 2 Aug 2013 19:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kc-CvLvO-zaQ for ; Fri, 2 Aug 2013 19:04:46 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3C11E8155 for ; Fri, 2 Aug 2013 19:04:45 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7324jqX025110 for ; Fri, 2 Aug 2013 22:04:45 -0400 (EDT) Received: from rtp-vpn5-1164.cisco.com (rtp-vpn5-1164.cisco.com [10.82.236.144]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7324f4m024856 for ; Fri, 2 Aug 2013 22:04:41 -0400 (EDT) Message-ID: <51FC6538.4070503@cisco.com> Date: Fri, 02 Aug 2013 22:04:40 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: netconf@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] Comments on draft-mm-netconf-time-capability-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: Sat, 03 Aug 2013 02:04:51 -0000 After the WG session, I spoke with Tal to get some clarity on the intended use case of this draft. After speaking with him, I support the capability and I do see a need for it. One of the concerns that was raised during the WG session was deterministic application of config. For example, many vendors' devices prioritize tasks like routing more highly than management, so if I say that a config should be applied at time T, it may not get applied until time T+10 because of other tasks happening on the device. I think the draft tries to address this fact in Section 3.2. Even so, I feel there is an important use case here. If I have a number of devices that need a specific config applied and need to stay relatively in sync to avoid disconnect (say I'm changing a management IP), I may want a time-based deployment. While they may not all apply EXACTLY at the same time, they will receive the instruction and deploy within a reasonable time of each other thus maintaining connectivity. In terms of things that need to be done to the draft, I think it needs a section on error-handling specifically around what happens if the clock on the device is insane or if a time is specified in the past. I think there needs to be some direction about how far in the future one can set the timer or how many pending operations can be outstanding. This is not a solution for scheduled deployment where an NMS could be the one doing the scheduling. One nit, I think Section 4.2 Dependencies should mention a dependency on a time synchronization protocol. It's called out elsewhere in the draft, and perhaps this is the right place to formally set that out as a dependency before time-parameters will be accepted. Joe -- Joe Marcus Clarke, CCIE #5384, | | SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| Distinguished Services Engineer ..:|||||||||::|||||||||:.. Phone: +1 (919) 392-2867 c i s c o S y s t e m s Email: jclarke@cisco.com ---------------------------------------------------------------------------- From andy@yumaworks.com Fri Aug 2 23:41:42 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 F383021E80C2 for ; Fri, 2 Aug 2013 23:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-ltLrIm-1q2 for ; Fri, 2 Aug 2013 23:41:37 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0995D21F8528 for ; Fri, 2 Aug 2013 23:41:32 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id v10so1396716pde.24 for ; Fri, 02 Aug 2013 23:41:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=90DZsListGq4cz+I8sOy8vTenar9we8tuIQBWcUq9vU=; b=PpyCxej9J4J+mWdhFoI+Y72x1RSPR4uoiK1aUGfPQWZQxMey2XTSe3bMO22bYZOf/X 5AFfCXLpJ82/EWE1Gpbbjb8+qKguub9FCT0/EQWCkLLCVuAYgcDVda8j2IJUPxqdcR5f 7K7Tn1LCjtU/v7YoUW9IYqbN0P6MC5djyLlaXt4YDi0RFadrmRkKnLskcMybQhdmtBJL hUn1w7xOcwOlbB4MA3XXQMLrdQPaPjOVyV5dzx19dzJZ6aHsoEGOO5p5wfgDBsEMWkwZ lLV79RQwxnzz9MP/2dmNyToErxOYoJ0E1TFSkyRbYAocbRVf3PUeF2oTosEbiHC65HuU 0X+Q== MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr14433458pab.38.1375512092609; Fri, 02 Aug 2013 23:41:32 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Fri, 2 Aug 2013 23:41:32 -0700 (PDT) Date: Fri, 2 Aug 2013 23:41:32 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org, Netconf Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl6QBQ0Z7t6GGLFpfHIYPvFVrJmsadsCQZ5I+w5uOiTVdtkU2nRrpz19BtYW42stOYOTI17 Subject: [Netconf] development plan 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: Sat, 03 Aug 2013 06:41:42 -0000 Hi, I wold like the NETMOD and NETCONF WGs to establish a development plan and roadmap for the work that will be attempted over the next 1 to 3 years. One draft after another gets presented. Some, like the ACL draft or draft have had almost unanimous support as a problem that needs to be solved. Then quickly forgotten. The complete lack of any development plan discourages people from participating and probably encourages others who are just wasting their time submitting drafts to these WGs. I don't agree with the assertion that NETCONF/YANG will only be useful when it "manages everything" (like the proprietary CLI). It is useful now, but in order to be essential, the community needs to know that it is stable and understand when and how new functionality will be added. Andy From mehmet.ersue@nsn.com Sat Aug 3 01:58:30 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 EB95221F8B35; Sat, 3 Aug 2013 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2-RQTIyaQRq; Sat, 3 Aug 2013 01:58:25 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2221F9C34; Sat, 3 Aug 2013 01:58:25 -0700 (PDT) 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 r738wOXr000626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 3 Aug 2013 10:58:24 +0200 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 r738wNZj012912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Aug 2013 10:58:24 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Sat, 3 Aug 2013 10:58:23 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: ext Andy Bierman , "netmod@ietf.org" , Netconf Thread-Topic: [Netconf] development plan Thread-Index: AQHOkBSbZaVYLzrrfEypVvCB71Bls5mDLUGw Date: Sat, 3 Aug 2013 08:58:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.105] 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: 1446 X-purgate-ID: 151667::1375520304-0000471E-D6FE16C3/0-0/0-0 Subject: Re: [Netconf] development plan 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: Sat, 03 Aug 2013 08:58:30 -0000 We need to start somewhere to discuss the priorities. So, let's start here. What would be your proposal for the development plan?=20 Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Andy Bierman > Sent: Saturday, August 03, 2013 8:42 AM > To: netmod@ietf.org; Netconf > Subject: [Netconf] development plan >=20 > Hi, >=20 > I wold like the NETMOD and NETCONF WGs to establish a > development plan and roadmap for the work that will be attempted > over the next 1 to 3 years. >=20 > One draft after another gets presented. > Some, like the ACL draft or draft have had almost unanimous > support as a problem that needs to be solved. Then quickly forgotten. >=20 > The complete lack of any development plan discourages people > from participating and probably encourages others who are just > wasting their time submitting drafts to these WGs. >=20 > I don't agree with the assertion that NETCONF/YANG will only > be useful when it "manages everything" (like the proprietary CLI). > It is useful now, but in order to be essential, the community needs > to know that it is stable and understand when and how new functionality w= ill > be added. >=20 >=20 >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Sat Aug 3 02:13:09 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 16F8111E810C for ; Sat, 3 Aug 2013 02:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OREf4t+tfomf for ; Sat, 3 Aug 2013 02:13:05 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 329D511E8162 for ; Sat, 3 Aug 2013 02:12:57 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r11so992758lbv.8 for ; Sat, 03 Aug 2013 02:12:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PbmKdy6GcRNCRcjS4P7bU0zb2mrHEVnctroMEg7zJ80=; b=oVqIoBHX/1pNPONuXZdhJ1FFsoRynJuDA9qJpQKptUGj6Gq+wS/SOzmCWzT5ixq2u9 7Pdx/SoBCPmVQRtI3qR94B61Et/NKyoz+aEAnUakWeNQBhwwoiuo46WLbA/uosRjQBZ+ nRNMPaioqR1R5P70uTfSfLgpfB56eWdDqVPMKcqw337fXkO9ULi7EpbmuospAlCO17oC Q2vKKv9Xvm8JKXUexv8fie6Ppd/F+PDlxp1OUaKi6t1iUF9hs8fkId4O8C3QwTuldWF7 R0Psd8fUzEJgVAps96v2C5LZQQv9JqD+Z2iLCWLfgBVD6PYRlZd5hUsGXNagmlv6Dc28 CtDw== MIME-Version: 1.0 X-Received: by 10.152.27.9 with SMTP id p9mr4619284lag.4.1375521174687; Sat, 03 Aug 2013 02:12:54 -0700 (PDT) Received: by 10.112.30.136 with HTTP; Sat, 3 Aug 2013 02:12:54 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Aug 2013 02:12:54 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmhnLKzbNqGG/4PNjSe1TSk4gESwNbA6Zo2F9aULVSAGMBLXOO9jnsbeIF62W14aqQUCHwo Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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: Sat, 03 Aug 2013 09:13:09 -0000 On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > We need to start somewhere to discuss the priorities. So, let's start here. > > What would be your proposal for the development plan? > This will take some time to work out, so I will just start with some design principles and fill in the details later. 1) current functionality that the community agrees is useful MUST NOT be broken in any way 2) current functionality that the community agrees is not useful SHOULD be removed 3) YANG needs to be a multi-protocol DML, but that does not mean written for unknown protocols. The protocol-independent and protocol-dependent aspects need to be clearly separated, allowing specific protocol mapping RFCs to be easily standardized 4) Important module infrastructure such as ACLs and topology need to be standardized in an extensible manner, allowing future (currently unknown) applications to build on these modules and not start over 5) The private candidate datastore is a disaster for multi-client deployments. A real transaction mechanism that does not rely on global or even predictive locking is needed. Concurrent transactions that do not collide can be processed in parallel. 6) Protocol performance and scaling properties need to be addressed 7) Network-wide applications need to be supported in a way that does not break existing single-server use cases > Cheers, > Mehmet Andy > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >> Andy Bierman >> Sent: Saturday, August 03, 2013 8:42 AM >> To: netmod@ietf.org; Netconf >> Subject: [Netconf] development plan >> >> Hi, >> >> I wold like the NETMOD and NETCONF WGs to establish a >> development plan and roadmap for the work that will be attempted >> over the next 1 to 3 years. >> >> One draft after another gets presented. >> Some, like the ACL draft or draft have had almost unanimous >> support as a problem that needs to be solved. Then quickly forgotten. >> >> The complete lack of any development plan discourages people >> from participating and probably encourages others who are just >> wasting their time submitting drafts to these WGs. >> >> I don't agree with the assertion that NETCONF/YANG will only >> be useful when it "manages everything" (like the proprietary CLI). >> It is useful now, but in order to be essential, the community needs >> to know that it is stable and understand when and how new functionality will >> be added. >> >> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Sat Aug 3 13:49: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 843E321F9EF5 for ; Sat, 3 Aug 2013 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbuJlIOStrql for ; Sat, 3 Aug 2013 13:49:21 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB0C21F8EB2 for ; Sat, 3 Aug 2013 13:49:21 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id CAAA11200045; Sat, 3 Aug 2013 22:49:19 +0200 (CEST) Date: Sat, 03 Aug 2013 22:49:19 +0200 (CEST) Message-Id: <20130803.224919.208391324.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130801112350.GA25489@elstar.local> References: <20130801112350.GA25489@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] Summary of the NETCONF Session at IETF 87 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: Sat, 03 Aug 2013 20:49:27 -0000 Hi, Juergen Schoenwaelder wrote: > On Thu, Aug 01, 2013 at 09:16:08AM +0000, Ersue, Mehmet (NSN - > DE/Munich) wrote: > > > > Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause > > consistency issues if the base module gets updated repeatedly > > partly. To solve the issue replacing the base module for an update has > > been proposed. Community poll: 9 in favor, 5 against. AI: Check on the > > maillist. > > I think this is not stated well - there is no consistency issue in > both options. Let me try to restate it in a neutral way: > > The WG discussed the usage of submodules and a single namespace for > NETCONF configuration YANG models (current I-D) or the usage of > separate modules with different namespaces. Community poll: 9 in > favor of separate modules with different namespaces, 5 in favor > of submodules with a single namespace. AI: Check on the maillist. Listening to the audio recording of the meeting, this is not what I heard. The discussion was about the method of updating a previous RFC whenever the main module is revisioned. 5 was in favor of this, and 9 opposed. But I did not hear any vote (or discussion) about the alternative using separate modules (and different namespaces). Andy expressed the opinion that in order to use submodules, we'd have to obsolete the previous RFC and re-publish the old submodules whenever the main module is updated. I can see at least two alternatives to this approach: 1. Keep the design with submodules, but publish the main module in its own RFC. When a new submodule is added, the main-module-rfc gets re-published, (obsoletes the old one). 2. Keep the design with submodules, but let IANA maintain the main module. /martin From lhotka@nic.cz Mon Aug 5 03:03:12 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 87E9B21F9E6C; Mon, 5 Aug 2013 03:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.936 X-Spam-Level: X-Spam-Status: No, score=-0.936 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm4Zduc-OM3t; Mon, 5 Aug 2013 03:02:45 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id A07CC21F8A53; Mon, 5 Aug 2013 02:58:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C0236540289; Mon, 5 Aug 2013 11:56:27 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtVBqclMwsUk; Mon, 5 Aug 2013 11:56:21 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2894F5401AF; Mon, 5 Aug 2013 11:56:15 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , "Ersue\, Mehmet \(NSN - DE\/Munich\)" In-Reply-To: References: User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Andy Bierman , "Ersue\, Mehmet \(NSN - DE\/Munich\)" , Netconf , "netmod\@ietf.org" Date: Mon, 05 Aug 2013 11:56:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 10:03:13 -0000 Andy Bierman writes: > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> We need to start somewhere to discuss the priorities. So, let's start here. >> >> What would be your proposal for the development plan? >> > > This will take some time to work out, so I will just start with some > design principles > and fill in the details later. > > 1) current functionality that the community agrees is useful MUST NOT be broken > in any way > > 2) current functionality that the community agrees is not useful > SHOULD be removed > > 3) YANG needs to be a multi-protocol DML, but that does not mean written for > unknown protocols. The protocol-independent and protocol-dependent aspects > need to be clearly separated, allowing specific protocol mapping RFCs to be > easily standardized IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. Apart form this, there are several other areas that should be considered. One that comes to my mind are XPath extension functions. An interesting question is whether YANG 2.0 could/should also be made independent of the output encoding so that e.g. JSON is directly supported. > > 4) Important module infrastructure such as ACLs and topology need to > be standardized > in an extensible manner, allowing future (currently unknown) > applications to build > on these modules and not start over The priority for the NETMOD group should be to work on vendor-neutral data models that can be used right away or mapped to vendor-specific data models. > > 5) The private candidate datastore is a disaster for multi-client > deployments. A real > transaction mechanism that does not rely on global or even > predictive locking is needed. > Concurrent transactions that do not collide can be processed in parallel. +1, and I'd also add a sound model of configuration, state data and their interaction. Lada > > 6) Protocol performance and scaling properties need to be addressed > > 7) Network-wide applications need to be supported in a way that does not break > existing single-server use cases > > >> Cheers, >> Mehmet > > Andy > >> >>> -----Original Message----- >>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >>> Andy Bierman >>> Sent: Saturday, August 03, 2013 8:42 AM >>> To: netmod@ietf.org; Netconf >>> Subject: [Netconf] development plan >>> >>> Hi, >>> >>> I wold like the NETMOD and NETCONF WGs to establish a >>> development plan and roadmap for the work that will be attempted >>> over the next 1 to 3 years. >>> >>> One draft after another gets presented. >>> Some, like the ACL draft or draft have had almost unanimous >>> support as a problem that needs to be solved. Then quickly forgotten. >>> >>> The complete lack of any development plan discourages people >>> from participating and probably encourages others who are just >>> wasting their time submitting drafts to these WGs. >>> >>> I don't agree with the assertion that NETCONF/YANG will only >>> be useful when it "manages everything" (like the proprietary CLI). >>> It is useful now, but in order to be essential, the community needs >>> to know that it is stable and understand when and how new functionality will >>> be added. >>> >>> >>> >>> Andy >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 05:24:06 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 3F22321F9E94 for ; Mon, 5 Aug 2013 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jznk-MULp7B for ; Mon, 5 Aug 2013 05:23:59 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id F235321F9E6E for ; Mon, 5 Aug 2013 05:23:56 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id xb4so3309717pbc.22 for ; Mon, 05 Aug 2013 05:23:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=Sh6wGC0cpGmQ1ucLvvuQTraHb6xXi6SNdJff3lmNTdo=; b=lqG5YzfTzx3GCOcuDFJiHyIXjKohwjhoff++Ys5T0F710+cZcWZIEa9+u2UJ940JDS km0UTuiaoacAu8H0tT+HiC/usoYYXxmuL7sXW8JnSP6Cn8sQA+rUJ69UweIZf7DTSxzW kprQY+uFhSiNw5GAVBocnYlGcEFsb+0Qj2EGYSP2kPm7QmlTZD4wDcsSIhmwruE7Ov39 AJj8ALvru6SbTBqn4FHOuG/nTgpaCnyrVmGLE/OyEJjRlxfc1Ye+N8bBMk+Ph4hmP1mU mKPk8Qo8NIVtOO5qe+bwHBQETEeS9Nt21zqJ0E6Q5v6rl7hDW18TXfG6FCxx7wa+Bt2k VWGA== MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr22099254pbe.140.1375705436348; Mon, 05 Aug 2013 05:23:56 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 05:23:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 05:23:56 -0700 Message-ID: From: Andy Bierman To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmRkyIs+/VBGyb6j4Evl54mY/uFGA6U08F0nHa6VYIRFeF8Yy9o+hex+UNQswhTppbPhmd1 Subject: Re: [Netconf] development plan 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, 05 Aug 2013 12:24:07 -0000 On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > >> On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> We need to start somewhere to discuss the priorities. So, let's start here. >>> >>> What would be your proposal for the development plan? >>> >> >> This will take some time to work out, so I will just start with some >> design principles >> and fill in the details later. >> >> 1) current functionality that the community agrees is useful MUST NOT be broken >> in any way >> >> 2) current functionality that the community agrees is not useful >> SHOULD be removed >> >> 3) YANG needs to be a multi-protocol DML, but that does not mean written for >> unknown protocols. The protocol-independent and protocol-dependent aspects >> need to be clearly separated, allowing specific protocol mapping RFCs to be >> easily standardized > > IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > > Apart form this, there are several other areas that should be considered. One that comes to my mind are XPath extension functions. > I don't think it is a good time to start a 6020bis RFC and tell the community YANG 1.0 is unstable and being replaced. > An interesting question is whether YANG 2.0 could/should also be made independent of the output encoding so that e.g. JSON is directly supported. > I don't want YANG 2.0. New standard YANG extensions are OK for now. >> >> 4) Important module infrastructure such as ACLs and topology need to >> be standardized >> in an extensible manner, allowing future (currently unknown) >> applications to build >> on these modules and not start over > > The priority for the NETMOD group should be to work on vendor-neutral data models that can be used right away or mapped to vendor-specific data models. > >> >> 5) The private candidate datastore is a disaster for multi-client >> deployments. A real >> transaction mechanism that does not rely on global or even >> predictive locking is needed. >> Concurrent transactions that do not collide can be processed in parallel. > > +1, and I'd also add a sound model of configuration, state data and their interaction. > I think Kent's conditional enablement draft is the foundation for all the corner-case config state and operational CM requirements. We currently have a very simplistic model for the device configuration. The running config is either there or it is deleted and forgotten. IMO this is #1 or 2 priority for the NETCONF WG. > Lada > Andy >> >> 6) Protocol performance and scaling properties need to be addressed >> >> 7) Network-wide applications need to be supported in a way that does not break >> existing single-server use cases >> >> >>> Cheers, >>> Mehmet >> >> Andy >> >>> >>>> -----Original Message----- >>>> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] Behalf Of ext >>>> Andy Bierman >>>> Sent: Saturday, August 03, 2013 8:42 AM >>>> To: netmod@ietf.org; Netconf >>>> Subject: [Netconf] development plan >>>> >>>> Hi, >>>> >>>> I wold like the NETMOD and NETCONF WGs to establish a >>>> development plan and roadmap for the work that will be attempted >>>> over the next 1 to 3 years. >>>> >>>> One draft after another gets presented. >>>> Some, like the ACL draft or draft have had almost unanimous >>>> support as a problem that needs to be solved. Then quickly forgotten. >>>> >>>> The complete lack of any development plan discourages people >>>> from participating and probably encourages others who are just >>>> wasting their time submitting drafts to these WGs. >>>> >>>> I don't agree with the assertion that NETCONF/YANG will only >>>> be useful when it "manages everything" (like the proprietary CLI). >>>> It is useful now, but in order to be essential, the community needs >>>> to know that it is stable and understand when and how new functionality will >>>> be added. >>>> >>>> >>>> >>>> Andy >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 05:35: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 A2BA921F969F for ; Mon, 5 Aug 2013 05:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4lpys770JSG for ; Mon, 5 Aug 2013 05:35:33 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B18821F9473 for ; Mon, 5 Aug 2013 05:35:33 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so3334315pbb.28 for ; Mon, 05 Aug 2013 05:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NsIXeR5mensLEg+4IXikSgeytvnQGiOZ1nClGvPe6Ks=; b=iTsc+0s4BfdayWBPjk7Ggt9dwuGptoPHE0HNGFp56iZsWnfIS4qe1mhwZltQ8Ua7Ib 20WqfPycx4UM4mThOLUHC9kwEujpwCICkDy8ZZMAXDAsSy5kzRiIer97zr0t0lNB8XVg fJkynmhtnZTrLiKyjjSIfmlJPAtYg7I8saaPgPFirPDCSdWC7EH6+4cVcfoeJA3VPI50 IduvrWZBv20WPE3MDy3daT0HpDLVHc3OcxzKKx+lpkXPGP+tdWsvN50VHQaLHs6XBYIX Nto0MvzbxJQwcHk7OsA1kTK45TvkS9FqeAxIxZ2lGwDEhKUDYkLrdvi/bUfAtxX8ips3 8BYg== MIME-Version: 1.0 X-Received: by 10.68.189.162 with SMTP id gj2mr14291797pbc.96.1375706130515; Mon, 05 Aug 2013 05:35:30 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 05:35:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 05:35:30 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmLfTg+OE1bLYbdbiSY/I0oj57uLTJbca3EDXwooHBPDGPVmNQtYnIcpIoMOqTxwm0U6/6K Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 12:35:38 -0000 On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > We need to start somewhere to discuss the priorities. So, let's start here. > > What would be your proposal for the development plan? > Here is my development plan priorities: NETCONF WG: #1) RESTCONF (was YANG-API) #2) Config state, operational state, conditional enablement (IMO, all these are related problems) #3) Private Candidates (concurrent transactions) NETMOD WG: #1) Finish current base modules (either publish or abandon) #2) Transition to IETF support mode -- help other WGs create YANG modules for NETCONF and RESTCONF. Start with ACLs and topology. Help other WGs like SACM and I2RS use YANG. Coordinate all new work through YANG Doctors. ** Wait 2 years or so before attempting YANG 2.0 > Cheers, > Mehmet Andy From lhotka@nic.cz Mon Aug 5 05:51: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 0E34A21F9DCE; Mon, 5 Aug 2013 05:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8pdEkljKgRS; Mon, 5 Aug 2013 05:51:10 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 36EBE21F9EBE; Mon, 5 Aug 2013 05:50:53 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 322FE140146; Mon, 5 Aug 2013 14:50:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375707052; bh=/bOCqjpeD2lRVZkWUUrOmwzzoqDc0q1TFe/0Ig3HR6M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=sRtd9JkH9/2bhhc0CyPGS9QixQrTdNY9d7vV60VRU86K3+g3fwXhRkYynPiRy0GiA 9cbtYJ526hhVz94VodfXi71lbvJtrDQcNJYMs4YCXps5YzaKEXwNsCu5faF2ASrLYE YCmDPUteT75Gza7rdZCcwLr9C6Xlox1DmFTqWNtQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Aug 2013 14:50:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 12:51:11 -0000 On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: > On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: >>>=20 >>> 3) YANG needs to be a multi-protocol DML, but that does not mean = written for >>> unknown protocols. The protocol-independent and = protocol-dependent aspects >>> need to be clearly separated, allowing specific protocol mapping = RFCs to be >>> easily standardized >>=20 >> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>=20 >> Apart form this, there are several other areas that should be = considered. One that comes to my mind are XPath extension functions. >>=20 >=20 > I don't think it is a good time to start a 6020bis RFC and > tell the community YANG 1.0 is unstable and being replaced. I had the impression that my proposal to decouple YANG from NETCONF was = generally supported, and this is impossible to do without changing 6020, = because some important things like XPath context, 'choice' and 'when' = semantics, or even the concept of validity itself, are defined in = NETCONF-specific terms. >=20 >> An interesting question is whether YANG 2.0 could/should also be made = independent of the output encoding so that e.g. JSON is directly = supported. >>=20 >=20 > I don't want YANG 2.0. > New standard YANG extensions are OK for now. I agree with Martin that extensions should be restricted in scope, so = one can do only as much with them. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Aug 5 06:31:22 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 E5D1821F9E2A for ; Mon, 5 Aug 2013 06:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xxeRW+6rmIn for ; Mon, 5 Aug 2013 06:31:17 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id EC26B21F9E05 for ; Mon, 5 Aug 2013 06:31:13 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id bi5so3319499pad.22 for ; Mon, 05 Aug 2013 06:31:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=7akRSAK27tFG6ve+m/kCAOtTxnZF2lptI7IVw2IoRWw=; b=bJj7tET6vXChAt4PVpDiFJt9OmmtKhHwRpuIQV1OuDnRyFCx+BM4fsLGYS9HyX3DtZ G2CWYseSHGaJjm5HBFe7bMGTBmk0yZWmaRBQ84oba6K2k0dupDKxVn+iEiLjIjMhPNJ7 Cno4BXUT8g2ycXQFN8mF0PR62EUiqy2Jk794nl1fJ7EkPdBhnV+Xxmgc8+EQiVKDDymb cRJUPRjYaqm6l2Ziuna67utkWX4P0DD3zglIpBsRnk8luJw+0BqvR+0YzqC1Ni9vf/uI Ssetgha1qdQCDxvV1Yh4IApdqeBM9SVcFFcrJ1/v1qUKG/Y8epiE+7+qR359CzpYP/KM +JhA== MIME-Version: 1.0 X-Received: by 10.68.19.162 with SMTP id g2mr22415301pbe.140.1375709472928; Mon, 05 Aug 2013 06:31:12 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 06:31:12 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 06:31:12 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnqhBeQMMa6GDvM2QDKFiATmC8LSwJ0Fdg+BRPoly2EONqQTns+SIbaA1la0aJOWiCmu7ya Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 13:31:23 -0000 On Mon, Aug 5, 2013 at 5:50 AM, Ladislav Lhotka wrote: > > On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: > >> On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka wrote: >>>> >>>> 3) YANG needs to be a multi-protocol DML, but that does not mean writt= en for >>>> unknown protocols. The protocol-independent and protocol-dependent= aspects >>>> need to be clearly separated, allowing specific protocol mapping RF= Cs to be >>>> easily standardized >>> >>> IMO, YANG 2.0 should be protocol-independent, and a light-weight adapta= tion layer should be defined for each protocol, including NETCONF. >>> >>> Apart form this, there are several other areas that should be considere= d. One that comes to my mind are XPath extension functions. >>> >> >> I don't think it is a good time to start a 6020bis RFC and >> tell the community YANG 1.0 is unstable and being replaced. > > > I had the impression that my proposal to decouple YANG from NETCONF was g= enerally supported, and this is impossible to do without changing 6020, bec= ause some important things like XPath context, 'choice' and 'when' semantic= s, or even the concept of validity itself, are defined in NETCONF-specific = terms. > I agree with Dave Harrington's concerns expressed at the NETMOD WG meeting. Introducing a new language version is a serious and drastic step that shoul= d be done very carefully. IMO we do not have enough operational experience with YANG to do a good job at YANG 2.0. >> >>> An interesting question is whether YANG 2.0 could/should also be made i= ndependent of the output encoding so that e.g. JSON is directly supported. >>> >> >> I don't want YANG 2.0. >> New standard YANG extensions are OK for now. > > I agree with Martin that extensions should be restricted in scope, so one= can do only as much with them. > Yes -- we should specify what best practices are YANG extensions. An update to the the YANG Usage Guidelines would probably be a good idea. Consensus on best practice has changed and the guidelines are no longer 100% current. > Lada Andy From lhotka@nic.cz Mon Aug 5 07:03: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 E8D8B21F9D7E; Mon, 5 Aug 2013 07:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSB8Rc7-Ot0j; Mon, 5 Aug 2013 07:03:57 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id CD5CC21F9D70; Mon, 5 Aug 2013 07:03:56 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A32A0140166; Mon, 5 Aug 2013 16:03:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375711435; bh=of1ZkrDhfJPt8C7A9Al/PMMXA1h/f314WZKMfs71RC8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XRIogjYdwXb2Riz5SKCNtfFyaD8ALfnQlsPsNck8JXlwb4k0etpQXAAWwCwqjI9nh yJicIifi7I/nxIChwSyYxqjQuWTHrsTHPhv+rDSMEo2DxsWRmo+P0oqa7APKKqk85m fgR4hiz6Vg7+LlIEAM/CsNTnLNoWr+P78oqF3DnU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 5 Aug 2013 16:03:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 14:03:58 -0000 On Aug 5, 2013, at 3:31 PM, Andy Bierman wrote: > On Mon, Aug 5, 2013 at 5:50 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 5, 2013, at 2:23 PM, Andy Bierman wrote: >>=20 >>> On Mon, Aug 5, 2013 at 2:56 AM, Ladislav Lhotka = wrote: >>>>>=20 >>>>> 3) YANG needs to be a multi-protocol DML, but that does not mean = written for >>>>> unknown protocols. The protocol-independent and = protocol-dependent aspects >>>>> need to be clearly separated, allowing specific protocol mapping = RFCs to be >>>>> easily standardized >>>>=20 >>>> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>>>=20 >>>> Apart form this, there are several other areas that should be = considered. One that comes to my mind are XPath extension functions. >>>>=20 >>>=20 >>> I don't think it is a good time to start a 6020bis RFC and >>> tell the community YANG 1.0 is unstable and being replaced. >>=20 >>=20 >> I had the impression that my proposal to decouple YANG from NETCONF = was generally supported, and this is impossible to do without changing = 6020, because some important things like XPath context, 'choice' and = 'when' semantics, or even the concept of validity itself, are defined in = NETCONF-specific terms. >>=20 >=20 > I agree with Dave Harrington's concerns expressed at the NETMOD WG = meeting. > Introducing a new language version is a serious and drastic step that = should > be done very carefully. IMO we do not have enough operational = experience > with YANG to do a good job at YANG 2.0. It is a fact of life that YANG is being used outside NETCONF, and there = are more plans for doing do, but with 6020 it is a slippery slope. For = example, such non-NETCONF applications of YANG will most likely want to = use "must" for expressing semantic constraints. However, the accessible = tree for "must" is defined like so: o If the context node represents configuration, the tree is the data in the NETCONF datastore where the context node exists. The XPath root node has all top-level configuration data nodes in all modules as children. o If the context node represents state data, the tree is all state data on the device, and the datastore. The XPath root node has all top-level data nodes in all modules as children. ... This cannot be unambiguously interpreted in a non-NETCONF context, so it = is effectively undefined, which is rather dangerous. So I don't mean to completely redesign YANG, but we cannot, on the other = hand, enable non-NETCONF YANG data modelling without providing new = definitions. Lada =20 >=20 >=20 >=20 >>>=20 >>>> An interesting question is whether YANG 2.0 could/should also be = made independent of the output encoding so that e.g. JSON is directly = supported. >>>>=20 >>>=20 >>> I don't want YANG 2.0. >>> New standard YANG extensions are OK for now. >>=20 >> I agree with Martin that extensions should be restricted in scope, so = one can do only as much with them. >>=20 >=20 > Yes -- we should specify what best practices are YANG extensions. > An update to the the YANG Usage Guidelines would probably be > a good idea. Consensus on best practice has changed and the > guidelines are no longer 100% current. >=20 >=20 >> Lada >=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Aug 5 07:11:22 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 6A47C21F9E5B; Mon, 5 Aug 2013 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.625, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XihT4mX6Kz2x; Mon, 5 Aug 2013 07:11:15 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2321F9AEF; Mon, 5 Aug 2013 07:11:15 -0700 (PDT) Received: from mail181-ch1-R.bigfish.com (10.43.68.230) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 14:11:14 +0000 Received: from mail181-ch1 (localhost [127.0.0.1]) by mail181-ch1-R.bigfish.com (Postfix) with ESMTP id 75C36220127; Mon, 5 Aug 2013 14:11:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.53; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF02-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432Id799h4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail181-ch1: domain of juniper.net designates 66.129.224.53 as permitted sender) client-ip=66.129.224.53; envelope-from=kwatsen@juniper.net; helo=P-EMF02-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail181-ch1 (localhost.localdomain [127.0.0.1]) by mail181-ch1 (MessageSwitch) id 1375711871930929_9870; Mon, 5 Aug 2013 14:11:11 +0000 (UTC) Received: from CH1EHSMHS001.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail181-ch1.bigfish.com (Postfix) with ESMTP id D653C26004C; Mon, 5 Aug 2013 14:11:11 +0000 (UTC) Received: from P-EMF02-SAC.jnpr.net (66.129.224.53) by CH1EHSMHS001.bigfish.com (10.43.70.1) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 14:11:11 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF02-SAC.jnpr.net (172.24.192.18) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 07:11:09 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Mon, 5 Aug 2013 07:11:09 -0700 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.204) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 07:25:02 -0700 Received: from mail60-am1-R.bigfish.com (10.3.201.233) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 14:11:06 +0000 Received: from mail60-am1 (localhost [127.0.0.1]) by mail60-am1-R.bigfish.com (Postfix) with ESMTP id BE78D2403CA; Mon, 5 Aug 2013 14:11:06 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(189002)(377454003)(164054003)(51704005)(199002)(54356001)(79102001)(80976001)(19580405001)(36756003)(83322001)(53806001)(19580395003)(561944002)(74366001)(77096001)(16406001)(56816003)(76176001)(63696002)(76796001)(76786001)(59766001)(56776001)(54316002)(77982001)(76482001)(80022001)(4396001)(49866001)(47736001)(551934002)(69226001)(74706001)(74876001)(74662001)(74502001)(47446002)(50986001)(47976001)(31966008)(65816001)(81342001)(51856001)(83072001)(46102001)(81542001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB125; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:10.255.159.4; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail60-am1 (localhost.localdomain [127.0.0.1]) by mail60-am1 (MessageSwitch) id 1375711829516294_4454; Mon, 5 Aug 2013 14:10:29 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.226]) by mail60-am1.bigfish.com (Postfix) with ESMTP id 741262C0046; Mon, 5 Aug 2013 14:10:29 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 14:10:28 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 14:10:26 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 14:10:24 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.13]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 14:10:24 +0000 From: Kent Watsen To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [Netconf] development plan Thread-Index: AQHOkCeotjTq6+Hl9Eyu6aC6FvZ1HZmGkDsA///XcAA= Date: Mon, 5 Aug 2013 14:10:23 +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.5.130515 x-originating-ip: [10.255.159.4] x-forefront-prvs: 0929F1BAED Content-Type: text/plain; charset="us-ascii" Content-ID: <17BFFED8E52AB9419482F256645DFAC1@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%IETF.ORG$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%NSN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 14:11:22 -0000 My short list: NETCONF WG: =20 (essentially Andy's list with a couple items I'm already into on top) #1) Reverse SSH #2) Zero Conf #3) RESTCONF #4) Config state, operational state, conditional enablement #5) Private Candidates (concurrent transactions) NETMOD WG: #1) Extend as needed to minimize number of proprietary Juniper YANG modules #2) Modules for basic EMS support (hardware, software, licenses, etc.) #3) Data Model Transformation Engine Thanks, Kent On 8/5/13 8:35 AM, "Andy Bierman" wrote: >On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: >> We need to start somewhere to discuss the priorities. So, let's start >>here. >> >> What would be your proposal for the development plan? >> > >Here is my development plan priorities: > >NETCONF WG: > > #1) RESTCONF (was YANG-API) > #2) Config state, operational state, conditional enablement > (IMO, all these are related problems) > #3) Private Candidates (concurrent transactions) > >NETMOD WG: > > #1) Finish current base modules (either publish or abandon) > #2) Transition to IETF support mode -- help other WGs > create YANG modules for NETCONF and RESTCONF. > Start with ACLs and topology. Help other WGs like SACM > and I2RS use YANG. Coordinate all new work > through YANG Doctors. > ** Wait 2 years or so before attempting YANG 2.0 > > >> Cheers, >> Mehmet > >Andy >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From andy@yumaworks.com Mon Aug 5 07:22:59 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 B539F21F9F5E for ; Mon, 5 Aug 2013 07:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pa0CcYJmfL7U for ; Mon, 5 Aug 2013 07:22:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB81C21F9EF2 for ; Mon, 5 Aug 2013 07:22:45 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so3417202pbc.3 for ; Mon, 05 Aug 2013 07:22:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=s+fXEg6H3quLEfen8pMpuvqx275o6wHRfZpqpG98YlI=; b=W6NTnxj5c2NTfTf/fzlqYKiGAymaTww+6pHkza1e2NRd6Gw2gJuSXjjiGHOS/2RR+L IX5Q8wj5g8GS7+13pMk1+CEIvSuV/j3aRZS6i7zwzIqN/Uv+PwWso623mwnUnvvdqJuW ka3FCvdq8YOWD7rTdE5anvtn0Mr6+37HrnbK5QfD2NoYAMKuNv2BXDedhm8g8+Rm+oU1 KANIP5ms5pApvL2GtDdKZIxuxBCV8/O/+rexmLhNcF/hZQTBVW1AT7Jw9FtxK/NKiiF5 +C4dPJ2T73S4Wpzv8cIwtZZMDBfkItX7XULER7JSgbcaupMZ7uUn4rMbWw6hkVferASt 1alA== MIME-Version: 1.0 X-Received: by 10.66.232.101 with SMTP id tn5mr25486244pac.132.1375712560180; Mon, 05 Aug 2013 07:22:40 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 07:22:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 07:22:40 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQljwkaN1L9+g7KcybkSE0PflBBihaoKuD8UauOaSFV5bWXsirIdHCoGkxg4OZ8E9VHTxOWG Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 14:22:59 -0000 Hi, I omitted NETCONF stuff that is currently chartered. I agree Reverse SSH and TLS-bis are #1 for NETCONF. Zeroconf came out of left field. What does that mean in the context of these 2 WGs? Andy On Mon, Aug 5, 2013 at 7:10 AM, Kent Watsen wrote: > > My short list: > > NETCONF WG: > > (essentially Andy's list with a couple items I'm already into on top) > > #1) Reverse SSH > #2) Zero Conf > #3) RESTCONF > #4) Config state, operational state, conditional enablement > #5) Private Candidates (concurrent transactions) > > > NETMOD WG: > > #1) Extend as needed to minimize number of proprietary Juniper YANG > modules > > #2) Modules for basic EMS support (hardware, software, licenses, etc.) > #3) Data Model Transformation Engine > > > > Thanks, > Kent > > > On 8/5/13 8:35 AM, "Andy Bierman" wrote: > >>On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >> wrote: >>> We need to start somewhere to discuss the priorities. So, let's start >>>here. >>> >>> What would be your proposal for the development plan? >>> >> >>Here is my development plan priorities: >> >>NETCONF WG: >> >> #1) RESTCONF (was YANG-API) >> #2) Config state, operational state, conditional enablement >> (IMO, all these are related problems) >> #3) Private Candidates (concurrent transactions) >> >>NETMOD WG: >> >> #1) Finish current base modules (either publish or abandon) >> #2) Transition to IETF support mode -- help other WGs >> create YANG modules for NETCONF and RESTCONF. >> Start with ACLs and topology. Help other WGs like SACM >> and I2RS use YANG. Coordinate all new work >> through YANG Doctors. >> ** Wait 2 years or so before attempting YANG 2.0 >> >> >>> Cheers, >>> Mehmet >> >>Andy >>_______________________________________________ >>Netconf mailing list >>Netconf@ietf.org >>https://www.ietf.org/mailman/listinfo/netconf >> >> > > > From kwatsen@juniper.net Mon Aug 5 08:29: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 8FCE321E804B; Mon, 5 Aug 2013 08:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBkri8pyL-6z; Mon, 5 Aug 2013 08:29:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id AD96D11E8131; Mon, 5 Aug 2013 08:29:08 -0700 (PDT) Received: from mail122-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 15:29:07 +0000 Received: from mail122-ch1 (localhost [127.0.0.1]) by mail122-ch1-R.bigfish.com (Postfix) with ESMTP id 2997D140267; Mon, 5 Aug 2013 15:29:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF03-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432Id799h4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL1de096h8275bh8275dh1de097hz2fh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail122-ch1: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=kwatsen@juniper.net; helo=P-EMF03-SAC.jnpr.net ; SAC.jnpr.net ; X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT Received: from mail122-ch1 (localhost.localdomain [127.0.0.1]) by mail122-ch1 (MessageSwitch) id 1375716544906042_23254; Mon, 5 Aug 2013 15:29:04 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail122-ch1.bigfish.com (Postfix) with ESMTP id D86564E0047; Mon, 5 Aug 2013 15:29:04 +0000 (UTC) Received: from P-EMF03-SAC.jnpr.net (66.129.224.52) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 15:29:04 +0000 Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMF03-SAC.jnpr.net (172.24.192.19) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 08:29:03 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.3.146.0; Mon, 5 Aug 2013 08:29:03 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Aug 2013 08:42:57 -0700 Received: from mail20-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE026.bigfish.com (10.243.66.89) with Microsoft SMTP Server id 14.1.225.22; Mon, 5 Aug 2013 15:29:02 +0000 Received: from mail20-co1 (localhost [127.0.0.1]) by mail20-co1-R.bigfish.com (Postfix) with ESMTP id 65101400A3; Mon, 5 Aug 2013 15:29:02 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(164054003)(377454003)(51704005)(199002)(189002)(77982001)(59766001)(63696002)(76796001)(76786001)(36756003)(76176001)(46102001)(56816003)(77096001)(79102001)(4396001)(69226001)(51856001)(561944002)(54316002)(74876001)(83322001)(19580395003)(19580405001)(76482001)(56776001)(83072001)(54356001)(74366001)(81542001)(74706001)(551934002)(81342001)(53806001)(65816001)(74662001)(16406001)(47976001)(49866001)(31966008)(74502001)(80022001)(47446002)(50986001)(80976001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB126; H:BY2PR05MB125.namprd05.prod.outlook.com; CLIP:10.255.159.4; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail20-co1 (localhost.localdomain [127.0.0.1]) by mail20-co1 (MessageSwitch) id 1375716540502001_23515; Mon, 5 Aug 2013 15:29:00 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.250]) by mail20-co1.bigfish.com (Postfix) with ESMTP id 764728C004A; Mon, 5 Aug 2013 15:29:00 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 5 Aug 2013 15:28:59 +0000 Received: from BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.341.1; Mon, 5 Aug 2013 15:28:58 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com (10.242.38.20) by BY2PR05MB126.namprd05.prod.outlook.com (10.242.38.22) with Microsoft SMTP Server (TLS) id 15.0.731.16; Mon, 5 Aug 2013 15:28:55 +0000 Received: from BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.143]) by BY2PR05MB125.namprd05.prod.outlook.com ([169.254.5.13]) with mapi id 15.00.0731.000; Mon, 5 Aug 2013 15:28:55 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] development plan Thread-Index: AQHOkCeotjTq6+Hl9Eyu6aC6FvZ1HZmGkDsA///XcACAAEaBAP//z2+A Date: Mon, 5 Aug 2013 15:28:54 +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.5.130515 x-originating-ip: [10.255.159.4] x-forefront-prvs: 0929F1BAED 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%IETF.ORG$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%NSN.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 15:29:14 -0000 >From the WG summary Mehmet sent out: "...and Zero-configuration. The latter has been seen as essentially important and should be done in a separate draft. Steve Hanna volunteered to work on this together with Kent. Manual configuration will be done in the Reverse SSH draft." My understanding was that there was interest in doing ZeroConf (for both SSH and TLS), especially now that we have the Security experts attention. I think the chairs were going to check if the current charter covers it or not... K. On 8/5/13 10:22 AM, "Andy Bierman" wrote: >Hi, > >I omitted NETCONF stuff that is currently chartered. >I agree Reverse SSH and TLS-bis are #1 for NETCONF. >Zeroconf came out of left field. What does >that mean in the context of these 2 WGs? > >Andy > > >On Mon, Aug 5, 2013 at 7:10 AM, Kent Watsen wrote: >> >> My short list: >> >> NETCONF WG: >> >> (essentially Andy's list with a couple items I'm already into on top) >> >> #1) Reverse SSH >> #2) Zero Conf >> #3) RESTCONF >> #4) Config state, operational state, conditional enablement >> #5) Private Candidates (concurrent transactions) >> >> >> NETMOD WG: >> >> #1) Extend as needed to minimize number of proprietary Juniper YANG >> modules >> >> #2) Modules for basic EMS support (hardware, software, licenses, etc.) >> #3) Data Model Transformation Engine >> >> >> >> Thanks, >> Kent >> >> >> On 8/5/13 8:35 AM, "Andy Bierman" wrote: >> >>>On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) >>> wrote: >>>> We need to start somewhere to discuss the priorities. So, let's start >>>>here. >>>> >>>> What would be your proposal for the development plan? >>>> >>> >>>Here is my development plan priorities: >>> >>>NETCONF WG: >>> >>> #1) RESTCONF (was YANG-API) >>> #2) Config state, operational state, conditional enablement >>> (IMO, all these are related problems) >>> #3) Private Candidates (concurrent transactions) >>> >>>NETMOD WG: >>> >>> #1) Finish current base modules (either publish or abandon) >>> #2) Transition to IETF support mode -- help other WGs >>> create YANG modules for NETCONF and RESTCONF. >>> Start with ACLs and topology. Help other WGs like SACM >>> and I2RS use YANG. Coordinate all new work >>> through YANG Doctors. >>> ** Wait 2 years or so before attempting YANG 2.0 >>> >>> >>>> Cheers, >>>> Mehmet >>> >>>Andy >>>_______________________________________________ >>>Netconf mailing list >>>Netconf@ietf.org >>>https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> >> > > From balazs.lengyel@ericsson.com Mon Aug 5 08:31:39 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 56D0521F9F34 for ; Mon, 5 Aug 2013 08:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.079 X-Spam-Level: X-Spam-Status: No, score=-5.079 tagged_above=-999 required=5 tests=[AWL=1.170, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLpdI4GT-jbJ for ; Mon, 5 Aug 2013 08:31:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3952221F9ED4 for ; Mon, 5 Aug 2013 08:31:21 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-37-51ffc548ee81 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.F4.19388.845CFF15; Mon, 5 Aug 2013 17:31:20 +0200 (CEST) Received: from [159.107.197.207] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.2.328.9; Mon, 5 Aug 2013 17:31:19 +0200 Message-ID: <51FFC547.5090406@ericsson.com> Date: Mon, 5 Aug 2013 17:31:19 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Martin Bjorklund References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> In-Reply-To: <20130803.224919.208391324.mbj@tail-f.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Vtfj6P9Agz37hS2ubvzJaNHd/Yzd Yuqm26wOzB5Llvxk8thwwNNj46/FLAHMUVw2Kak5mWWpRfp2CVwZq7cYFrwUrnh9ZzNLA+M6 /i5GTg4JAROJCWcaGCFsMYkL99azdTFycQgJHGaUmHdoOzOEs5pRYvKTvewgVbwC2hKNLWvA bBYBFYkHO++wgNhsAkYSU/vPg9miAlESrb1TmSHqBSVOznwCFhcRUJV4snMtmM0sYCfRveAw E4gtLOAg0fLqLDvEsnmMEvvnbWcDSXAKmEts/niJFaLBVuLCnOtQzfIS29/OAVsgJKAh8fDC X9YJjIKzkOybhaRlFpKWBYzMqxjZcxMzc9LLzTcxAsP04JbfBjsYN90XO8QozcGiJM67We9M oJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGvUYv1K7pSF1a9VW3yHTtXfeK37aLfXwlfPeo TLjtJXgk9em7kgmdfaqyHglpU88UlT6tFZ+tmWc927/MYsf29BiZEs6/f3Vci5ne1ag+e869 KvWtzE0F63XL988Urra49s2BQ0RRzbT/60aGpYuE50zPvaieX2i2/8ocpT5R182uu8RmN1kq sRRnJBpqMRcVJwIAqi6ItiECAAA= Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 05 Aug 2013 15:31:39 -0000 Hello Martin, I missed the original discussion, sorry, but what advantages do we get by using submodules instead of separate modules? (With modules you at least do not have to republish the main module.) regards Balazs On 2013-08-03 22:49, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: >> On Thu, Aug 01, 2013 at 09:16:08AM +0000, Ersue, Mehmet (NSN - >> DE/Munich) wrote: >>> Juergen Schoenwaelder on NETCONF Over TLS: Module update can cause >>> consistency issues if the base module gets updated repeatedly >>> partly. To solve the issue replacing the base module for an update has >>> been proposed. Community poll: 9 in favor, 5 against. AI: Check on the >>> maillist. >> I think this is not stated well - there is no consistency issue in >> both options. Let me try to restate it in a neutral way: >> >> The WG discussed the usage of submodules and a single namespace for >> NETCONF configuration YANG models (current I-D) or the usage of >> separate modules with different namespaces. Community poll: 9 in >> favor of separate modules with different namespaces, 5 in favor >> of submodules with a single namespace. AI: Check on the maillist. > Listening to the audio recording of the meeting, this is not what I > heard. The discussion was about the method of updating a previous RFC > whenever the main module is revisioned. 5 was in favor of this, and 9 > opposed. > > But I did not hear any vote (or discussion) about the alternative > using separate modules (and different namespaces). Andy expressed the > opinion that in order to use submodules, we'd have to obsolete the > previous RFC and re-publish the old submodules whenever the main > module is updated. > > I can see at least two alternatives to this approach: > > 1. Keep the design with submodules, but publish the main module in > its own RFC. When a new submodule is added, the main-module-rfc > gets re-published, (obsoletes the old one). > > 2. Keep the design with submodules, but let IANA maintain the main > module. > > > > /martin > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- 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 balazs.lengyel@ericsson.com Mon Aug 5 08:50:03 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 0AC1521F9971; Mon, 5 Aug 2013 08:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=-0.889, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta+XmhBSYT5T; Mon, 5 Aug 2013 08:49:56 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 22BCD21F93C4; Mon, 5 Aug 2013 08:49:55 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-8a-51ffc9a29fd2 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 61.9E.11907.2A9CFF15; Mon, 5 Aug 2013 17:49:55 +0200 (CEST) Received: from [159.107.197.207] (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.2.328.9; Mon, 5 Aug 2013 17:49:54 +0200 Message-ID: <51FFC9A1.7050207@ericsson.com> Date: Mon, 5 Aug 2013 17:49:53 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> In-Reply-To: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre7ik/8DDT6dYLF4cGQWu8WFVXPZ LKZuus1qMf9iI6sDi8eSJT+ZPDZdvsPo0dJ/kSWAOYrLJiU1J7MstUjfLoEr48nyqoIzfBVr f15mbWBcw93FyMkhIWAicW/xcjYIW0ziwr31QDYXh5DAUUaJOQfOMkE4qxkl7u//zQRSxSug LfFm5wlWEJtFQEVi/cmzLCA2m4CRxNT+82C2qECURGvvVGaIekGJkzOfgMVFBJQlLk74CWYz C2RIbNsyC6xGWMBA4s6rA+wQy64yS/xq/AF2EqeAlcTcBYcYIRpsJS7MuQ7VLC+x/e0csGYh AQ2Jhxf+sk5gFJyFZN8sJC2zkLQsYGRexchRnFqclJtuZLCJERi0B7f8ttjBePmvzSFGaQ4W JXHeLXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwOjz8ZnblEVvch+fXJc4kh0SdCOH8 Fu/g8mPPtv1nXlxOOx991y00a95rFalbzL3npyz9OmveIkuG58KnXWSclrUdjo7ck7nBZJ8V +9tNdz4qVb99IJK9TfbZ6+tn7FiO6L5r+lITmZj9RK7iyJEoR5OmimpXvYsv8pXv5hxY8THA yHGSL1fLHSWW4oxEQy3mouJEACHJQI8oAgAA Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 15:50:03 -0000 On 2013-08-05 16:03, Ladislav Lhotka wrote: > It is a fact of life that YANG is being used outside NETCONF, and there are more plans for doing do, but with 6020 it is a slippery slope. For example, such non-NETCONF applications of YANG will most likely want to use "must" for expressing semantic constraints. However, the accessible tree for "must" is defined like so: > > o If the context node represents configuration, the tree is the data > in the NETCONF datastore where the context node exists. The XPath > root node has all top-level configuration data nodes in all > modules as children. > > o If the context node represents state data, the tree is all state > data on the device, and the datastore. The XPath root > node has all top-level data nodes in all modules as children. > > This cannot be unambiguously interpreted in a non-NETCONF context, so it is effectively undefined, which is rather dangerous. > So I don't mean to completely redesign YANG, but we cannot, on the other hand, enable non-NETCONF YANG data modelling without providing new definitions. > > Lada In my view Netconf contains the "pure" protocol (encoding, operations, transactional behavior...) and background plumbing (datastores, separation of state and config data, hierarchical data organisation, filtering, connection requirements, session concept, capability negotiation, many of the capabilites, error messages). The background plumbing is valid for all access methods (CLI, Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. 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 andy@yumaworks.com Mon Aug 5 09:54:02 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 7400C21E80C0 for ; Mon, 5 Aug 2013 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97AiVBOul9rQ for ; Mon, 5 Aug 2013 09:53:58 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFA821E80E0 for ; Mon, 5 Aug 2013 09:53:55 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id 5so3429758pdd.20 for ; Mon, 05 Aug 2013 09:53:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MZLqxqyCIXi0G8KtGxc/EGP3pQdpSiq/uy8DxUiIEYc=; b=JU73kEjeAr7HfE7sFyrpvUioS0JJ3KLkMZ+doaS+ZNe0i8D+hgbfTaVa5m3qi85KyA Q3p7U++AfLJ2OQ2qCnAvvRikvsDMenU/71ywEOf3pA86PT7kLWmO21s8wOVrAKTQ8e0q FYHrE3uYKvJ5izhoWqRAXjDOLSYMTgxQhkUZW62JbzhDkfysRTO2YhvaXrq1KvlOTjtD PyLBT+/dSQ7VG9+J7nDvR4PvYs0wdouShfLRKLQAl1Et0pqUSZMsbtJY9XgDTruWffwN lG3WGk0ETKKp+pXKqpT2+KfMLRb9radn8q0N0xRihgOI/YifJkNBTcIC3AeHnL+eZLxR hCeg== MIME-Version: 1.0 X-Received: by 10.68.60.132 with SMTP id h4mr23337570pbr.177.1375721633771; Mon, 05 Aug 2013 09:53:53 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 5 Aug 2013 09:53:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 Aug 2013 09:53:53 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm+R+V2G5cmuyeZUDLzrSrc08d92IaD86cDwo/C0NUN5WuapG7GgSKmDX3D1n8bxUh6vvnf Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] development plan 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, 05 Aug 2013 16:54:02 -0000 ... > #1) RESTCONF (was YANG-API) This item also includes a complete protocol encoding for JSON (in addition to XML). Lada's JSON draft is required for this item. http://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-json/ > Andy Andy From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:38: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 033C921F9EAD for ; Mon, 5 Aug 2013 10:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzVkmSqOuZdq for ; Mon, 5 Aug 2013 10:38:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B868321F9DCE for ; Mon, 5 Aug 2013 10:38:26 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1CEB20BF5; Mon, 5 Aug 2013 19:38:25 +0200 (CEST) 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 t_zDlS_Mg5Dt; Mon, 5 Aug 2013 19:38:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8439120BF1; Mon, 5 Aug 2013 19:38:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 10BC127B8006; Mon, 5 Aug 2013 19:38:20 +0200 (CEST) Date: Mon, 5 Aug 2013 19:38:20 +0200 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20130805173820.GA897@elstar.local> Mail-Followup-To: Balazs Lengyel , Martin Bjorklund , netconf@ietf.org References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51FFC547.5090406@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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: Mon, 05 Aug 2013 17:38:32 -0000 On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: > Hello Martin, > I missed the original discussion, sorry, but what advantages do we > get by using submodules instead of separate modules? > (With modules you at least do not have to republish the main module.) A consistent namespace, i.e. all NETCONF configuration objects in one namespace. The IETF sometimes partitions work in ways that reflect the timeline of how things are done mixed with a bit of procedural aspects. The question is to what extend we want to expose that to the users of the data models. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Aug 5 10:45:56 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 4C13721F9D0A; Mon, 5 Aug 2013 10:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqbqbdrflRaB; Mon, 5 Aug 2013 10:45:55 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD7B21F9CBF; Mon, 5 Aug 2013 10:45:55 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 28E27140145; Mon, 5 Aug 2013 19:45:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375724754; bh=j7k9gRIi/Diyc6gLuKQdHLu3mkJ8jv+5oGdcaNZmAd8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=DPFEpKvwsgg0cZwVjLkIObk8uiTVI6fFSrTRUAMcxLu/sXEHIM53NFXx0ScupdeiG V6+I//4tsfYjDlY+q4HYW/F4iqrQuYNITH3ONisgMpSBf+qrZFZamEr2upE973a3rm LAYpZdRiBHFg23RUh4VpHwSb5VuZq0OyxtKqaBOI= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <51FFC9A1.7050207@ericsson.com> Date: Mon, 5 Aug 2013 19:45:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 17:45:56 -0000 On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >=20 > On 2013-08-05 16:03, Ladislav Lhotka wrote: >> It is a fact of life that YANG is being used outside NETCONF, and = there are more plans for doing do, but with 6020 it is a slippery slope. = For example, such non-NETCONF applications of YANG will most likely want = to use "must" for expressing semantic constraints. However, the = accessible tree for "must" is defined like so: >>=20 >> o If the context node represents configuration, the tree is the = data >> in the NETCONF datastore where the context node exists. The = XPath >> root node has all top-level configuration data nodes in all >> modules as children. >>=20 >> o If the context node represents state data, the tree is all = state >> data on the device, and the datastore. The XPath = root >> node has all top-level data nodes in all modules as children. >>=20 >> This cannot be unambiguously interpreted in a non-NETCONF context, so = it is effectively undefined, which is rather dangerous. >> So I don't mean to completely redesign YANG, but we cannot, on the = other hand, enable non-NETCONF YANG data modelling without providing new = definitions. >>=20 >> Lada > In my view Netconf contains the "pure" protocol (encoding, operations, = transactional behavior...) and background plumbing (datastores, = separation of state and config data, hierarchical data organisation, = filtering, connection requirements, session concept, capability = negotiation, many of the capabilites, error messages). > The background plumbing is valid for all access methods (CLI, Netconf, = YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be = redefined. I don't think this is true. I2RS will probably have no distinction = between config and state data, though they may have read-write and = read-only. Sessions and capability negotiation are by no means necessary = (RESTCONF doesn't have it). I can actually imagine data modelling = without any specific protocol for data exchange. Lada > regards Balazs >=20 > --=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 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:50:44 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 CD78921F9B52; Mon, 5 Aug 2013 10:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS2hD0qew5ay; Mon, 5 Aug 2013 10:50:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9008521F9AEF; Mon, 5 Aug 2013 10:50:39 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F30C420BF1; Mon, 5 Aug 2013 19:50:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rklmBwEsLAeH; Mon, 5 Aug 2013 19:50:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96A1B20BDE; Mon, 5 Aug 2013 19:50:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16E5F27B8254; Mon, 5 Aug 2013 19:50:33 +0200 (CEST) Date: Mon, 5 Aug 2013 19:50:33 +0200 From: Juergen Schoenwaelder To: "Lisa Huang (yihuan)" Message-ID: <20130805175033.GB897@elstar.local> Mail-Followup-To: "Lisa Huang (yihuan)" , Andy Bierman , "netmod@ietf.org" , Netconf References: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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: Mon, 05 Aug 2013 17:50:45 -0000 On Mon, Aug 05, 2013 at 05:20:39PM +0000, Lisa Huang (yihuan) wrote: > Hi, > > I echo what Andy said below. When I invited people from other WGs, like > BGP etc, to join netmod session, they were disappointed when they found > that the WG has only a limited models and were still discussing basic > models. Encouraging more model submission is very important and should be > part of development plan. > Reviews help to finish up things faster. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:53:04 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 765B821F9CC5; Mon, 5 Aug 2013 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaRH1kNdxlOM; Mon, 5 Aug 2013 10:52:54 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB34121F9C22; Mon, 5 Aug 2013 10:52:50 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A86620BF5; Mon, 5 Aug 2013 19:52:49 +0200 (CEST) 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 jU0Ojt-dhVcg; Mon, 5 Aug 2013 19:52:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E584220BF1; Mon, 5 Aug 2013 19:52:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 39D4F27B82A1; Mon, 5 Aug 2013 19:52:45 +0200 (CEST) Date: Mon, 5 Aug 2013 19:52:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" Message-ID: <20130805175245.GC897@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@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) Subject: Re: [Netconf] development plan 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: Mon, 05 Aug 2013 17:53:05 -0000 On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: > > IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > Someone needs to define 'protocol-independent'. If you want to make YANG fully protocol-independent, then you will likely not finish and create just another example of the 2nd systems effect [1]. /js [1] http://en.wikipedia.org/wiki/Second-system_effect -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:54:04 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 8EFC721F8F3C; Mon, 5 Aug 2013 10:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8h5H8k5vkOZ5; Mon, 5 Aug 2013 10:53:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5D221F9B4B; Mon, 5 Aug 2013 10:53:45 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A265720BF5; Mon, 5 Aug 2013 19:53:44 +0200 (CEST) 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 BkDtQsa_eNpf; Mon, 5 Aug 2013 19:53:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C4BD20BF1; Mon, 5 Aug 2013 19:53:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8BCAE27B830C; Mon, 5 Aug 2013 19:53:40 +0200 (CEST) Date: Mon, 5 Aug 2013 19:53:40 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130805175340.GD897@elstar.local> Mail-Followup-To: Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@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 , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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: Mon, 05 Aug 2013 17:54:04 -0000 On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: > > We need to start somewhere to discuss the priorities. So, let's start here. > > > > What would be your proposal for the development plan? > > > > Here is my development plan priorities: > > NETCONF WG: > > #1) RESTCONF (was YANG-API) > #2) Config state, operational state, conditional enablement > (IMO, all these are related problems) What is to be done about config state and operational state? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Mon Aug 5 10:55:19 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 D1EEB21F9D83; Mon, 5 Aug 2013 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eUKPxLlGKQj; Mon, 5 Aug 2013 10:55:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D21C421F99AB; Mon, 5 Aug 2013 10:55:09 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4539820BF5; Mon, 5 Aug 2013 19:55:09 +0200 (CEST) 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 pL2bNE33SGwm; Mon, 5 Aug 2013 19:55:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A8C7820BF1; Mon, 5 Aug 2013 19:55:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F1DEC27B8355; Mon, 5 Aug 2013 19:55:04 +0200 (CEST) Date: Mon, 5 Aug 2013 19:55:04 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20130805175504.GE897@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@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: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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: Mon, 05 Aug 2013 17:55:19 -0000 On Mon, Aug 05, 2013 at 02:10:23PM +0000, Kent Watsen wrote: > > NETMOD WG: > > #1) Extend as needed to minimize number of proprietary Juniper YANG > modules Any Juniper submissions I can look at to see what this means? > #2) Modules for basic EMS support (hardware, software, licenses, etc.) > #3) Data Model Transformation Engine What is a 'data model transformation engine' doing? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Mon Aug 5 11:16:28 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 7279C21F9F5E; Mon, 5 Aug 2013 11:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o04w0BR4dA7D; Mon, 5 Aug 2013 11:16:27 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27A21F9F3D; Mon, 5 Aug 2013 11:16:27 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id ACBA613FD8D; Mon, 5 Aug 2013 20:16:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375726586; bh=TNczM848qB7APdhIv7xjfaW6wTdDF/iE/Jt8a+JpjB8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZRRZjkEuReLBDLPlRMy4u+Tdow2/z9hX/HX/zYaZHoUNrBRkxSWOCoqstnz5ywe7g J2Rc79vkzItKNTzG7YgltYLxxF4Llw5Iv6nr/jty07ttXs17Dyl1I4xhqwB4wArnIq FPW/kcodzTKvCDS3AfgAQtDsW8gF6F4Cw8BHJQ0E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130805175245.GC897@elstar.local> Date: Mon, 5 Aug 2013 20:16:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> References: <20130805175245.GC897@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 18:16:28 -0000 On Aug 5, 2013, at 7:52 PM, Juergen Schoenwaelder = wrote: > On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: >>=20 >> IMO, YANG 2.0 should be protocol-independent, and a light-weight = adaptation layer should be defined for each protocol, including NETCONF. >>=20 >=20 > Someone needs to define 'protocol-independent'. If you want to make > YANG fully protocol-independent, then you will likely not finish and > create just another example of the 2nd systems effect [1]. XML schema languages are protocol-independent and IMO they are good = examples of what YANG specification should aim at. In fact, DSDL mapping = of YANG (RFC 6110) can help in this respect because the resulting DSDL = schemas can be used, by extension, in any non-NETCONF context already = now. Lada=20 >=20 > /js >=20 > [1] http://en.wikipedia.org/wiki/Second-system_effect >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 5 12:26:05 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 AC26621F9DAA; Mon, 5 Aug 2013 12:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TN6E1oiE+f5; Mon, 5 Aug 2013 12:26:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CE21F8E8E; Mon, 5 Aug 2013 12:25:59 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2232020BE2; Mon, 5 Aug 2013 21:25:58 +0200 (CEST) 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 yGOWU8aDrgNw; Mon, 5 Aug 2013 21:25:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 50B3B20BE1; Mon, 5 Aug 2013 21:25:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0D2B27B8635; Mon, 5 Aug 2013 21:25:52 +0200 (CEST) Date: Mon, 5 Aug 2013 21:25:52 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130805192552.GA1120@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "Ersue, Mehmet (NSN - DE/Munich)" , Netconf , "netmod@ietf.org" References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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: Mon, 05 Aug 2013 19:26:05 -0000 On Mon, Aug 05, 2013 at 08:16:26PM +0200, Ladislav Lhotka wrote: > > On Aug 5, 2013, at 7:52 PM, Juergen Schoenwaelder wrote: > > > On Mon, Aug 05, 2013 at 11:56:14AM +0200, Ladislav Lhotka wrote: > >> > >> IMO, YANG 2.0 should be protocol-independent, and a light-weight adaptation layer should be defined for each protocol, including NETCONF. > >> > > > > Someone needs to define 'protocol-independent'. If you want to make > > YANG fully protocol-independent, then you will likely not finish and > > create just another example of the 2nd systems effect [1]. > > XML schema languages are protocol-independent and IMO they are good examples of what YANG specification should aim at. In fact, DSDL mapping of YANG (RFC 6110) can help in this respect because the resulting DSDL schemas can be used, by extension, in any non-NETCONF context already now. > YANG was designed to support NETCONF and as such it has a number of features that are related to NETCONF - and NETCONF is not just an XML editing tool. Do you propose to remove them? If so, do you propose these 'elements' become YANG 2.0 extensions? If the DSDL mapping of YANG already does the job and others are fine to use YANG as it is today, perhaps there is no problem to be solved. Note: I am just trying to find out what people mean when they use certain terms in this thread since we might easily speak past each other (or worse agree on something just to find out later that we have N different interpretations of 'something'). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Aug 5 13:04:47 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 0BBBF21F8F4A; Mon, 5 Aug 2013 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVg+oTLChGdq; Mon, 5 Aug 2013 13:04:41 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4D421F8C93; Mon, 5 Aug 2013 13:04:41 -0700 (PDT) Received: from localhost (213-65-182-102-no181.tbcn.telia.com [213.65.182.102]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D75B12000A9; Mon, 5 Aug 2013 22:04:39 +0200 (CEST) Date: Mon, 05 Aug 2013 22:04:38 +0200 (CEST) Message-Id: <20130805.220438.348428424.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> 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, netmod@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 20:04:47 -0000 Ladislav Lhotka wrote: > > On Aug 5, 2013, at 5:49 PM, Balazs Lengyel > wrote: > > > > > On 2013-08-05 16:03, Ladislav Lhotka wrote: > >> It is a fact of life that YANG is being used outside NETCONF, and > >> there are more plans for doing do, but with 6020 it is a slippery > >> slope. For example, such non-NETCONF applications of YANG will most > >> likely want to use "must" for expressing semantic > >> constraints. However, the accessible tree for "must" is defined like > >> so: > >> > >> o If the context node represents configuration, the tree is the data > >> in the NETCONF datastore where the context node exists. The XPath > >> root node has all top-level configuration data nodes in all > >> modules as children. > >> > >> o If the context node represents state data, the tree is all state > >> data on the device, and the datastore. The XPath root > >> node has all top-level data nodes in all modules as children. > >> > >> This cannot be unambiguously interpreted in a non-NETCONF context, so > >> it is effectively undefined, which is rather dangerous. > >> So I don't mean to completely redesign YANG, but we cannot, on the > >> other hand, enable non-NETCONF YANG data modelling without providing > >> new definitions. > >> > >> Lada > > In my view Netconf contains the "pure" protocol (encoding, operations, > > transactional behavior...) and background plumbing (datastores, > > separation of state and config data, hierarchical data organisation, > > filtering, connection requirements, session concept, capability > > negotiation, many of the capabilites, error messages). > > The background plumbing is valid for all access methods (CLI, Netconf, > > YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be > > redefined. > > I don't think this is true. I2RS will probably have no distinction > between config and state data FWIW, this is not how I understand I2RS - I think they explicitly mention the configuration data as being one thing, and that they want another "direct" method to modify the operational state. /martin From j.schoenwaelder@jacobs-university.de Mon Aug 5 23:45:20 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 1A2F721F9A33; Mon, 5 Aug 2013 23:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tIJfNKxoUVG; Mon, 5 Aug 2013 23:45:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D00DA21F90CC; Mon, 5 Aug 2013 23:45:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 660B820BE9; Tue, 6 Aug 2013 08:45:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ux8JeFFJhMcz; Tue, 6 Aug 2013 08:45:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C320220BE2; Tue, 6 Aug 2013 08:45:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EBC3F27B911E; Tue, 6 Aug 2013 08:45:07 +0200 (CEST) Date: Tue, 6 Aug 2013 08:45:07 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130806064507.GA2435@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130805.220438.348428424.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 06:45:20 -0000 On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: > > FWIW, this is not how I understand I2RS - I think they explicitly > mention the configuration data as being one thing, and that they want > another "direct" method to modify the operational state. > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, which is likely going to become the I2RS architecture document soon. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From yihuan@cisco.com Mon Aug 5 10:20:48 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 D887321F9FF6; Mon, 5 Aug 2013 10:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va4LKYNQPfKp; Mon, 5 Aug 2013 10:20:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D7C3421F9FED; Mon, 5 Aug 2013 10:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1396; q=dns/txt; s=iport; t=1375723242; x=1376932842; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=pxlYUN0mzWF/JbSXbrqXEEpOFLlZuqprykF5QeJugWM=; b=JCz9a/xmMrngSe9RbicLklqGT9iPjQRPzxLiSjLRYlCN3LPI/K38UYPQ SReWmZR1caoBYFl18UmjXS/Kb2omK8vTQHXBDbT6tFNFSA1fVDaN3wK5M F8wkkCm+g7ZKTvG66lp1F/L9hLjtACh+/2eU5U3Y0s9+spvUambHCQmur E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANfd/1GtJXG//2dsb2JhbABbgwY1UL51gSEWdIImAQQBAQE3NB0BCCIUNwslAgQBEggMh3wMtSkEjluBDTiDGXQDlAmVJoMXgWhC X-IronPort-AV: E=Sophos;i="4.89,819,1367971200"; d="scan'208";a="243468785" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 05 Aug 2013 17:20:41 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r75HKf6m023131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 17:20:41 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 12:20:41 -0500 From: "Lisa Huang (yihuan)" To: Andy Bierman , "netmod@ietf.org" , Netconf Thread-Topic: [netmod] development plan Thread-Index: AQHOkBSpf9/ypW85fkCMYLfhDIaFdZmGvoQA Date: Mon, 5 Aug 2013 17:20:39 +0000 Message-ID: <559E176269AD64429F1582D4EB94F86FE8FD4F@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.167.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Aug 2013 02:14:14 -0700 Subject: Re: [Netconf] [netmod] development plan 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, 05 Aug 2013 17:20:49 -0000 Hi, I echo what Andy said below. When I invited people from other WGs, like BGP etc, to join netmod session, they were disappointed when they found that the WG has only a limited models and were still discussing basic models. Encouraging more model submission is very important and should be part of development plan. Thanks, Lisa On 8/2/13 11:41 PM, "Andy Bierman" wrote: >Hi, > >I wold like the NETMOD and NETCONF WGs to establish a >development plan and roadmap for the work that will be attempted >over the next 1 to 3 years. > >One draft after another gets presented. >Some, like the ACL draft or draft have had almost unanimous >support as a problem that needs to be solved. Then quickly forgotten. > >The complete lack of any development plan discourages people >from participating and probably encourages others who are just >wasting their time submitting drafts to these WGs. > >I don't agree with the assertion that NETCONF/YANG will only >be useful when it "manages everything" (like the proprietary CLI). >It is useful now, but in order to be essential, the community needs >to know that it is stable and understand when and how new functionality >will >be added. > > > >Andy >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod From balazs.lengyel@ericsson.com Tue Aug 6 02:47:17 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 939D521F9BAD; Tue, 6 Aug 2013 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.165 X-Spam-Level: X-Spam-Status: No, score=-5.165 tagged_above=-999 required=5 tests=[AWL=1.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzAfBgLJwcMY; Tue, 6 Aug 2013 02:47:11 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A6B7A21F9B5C; Tue, 6 Aug 2013 02:47:10 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-31-5200c61dc5f8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2F.B9.19388.D16C0025; Tue, 6 Aug 2013 11:47:09 +0200 (CEST) Received: from [159.107.197.78] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.2.328.9; Tue, 6 Aug 2013 11:47:09 +0200 Message-ID: <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 11:47:08 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ladislav Lhotka References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> In-Reply-To: <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvra7sMYYggyXzTCweHJnFbnFh1Vw2 i6mbbrNazL/YyOrA4rFkyU8mj02X7zB6tPRfZAlgjuKySUnNySxLLdK3S+DK2NBgVLBLquLE sVOMDYwLRbsYOTgkBEwk5i8y7mLkBDLFJC7cW8/WxcjFISRwmFGifUo7C4SzmlHi8YSzjCBV vALaElf3HmAHsVkEVCR+tXaDxdkEjCSm9p9nAbFFBaIkWnunMkPUC0qcnPkELC4ioCxxccJP MJtZIENi25ZZYDXCAgYSd16BzARZtphFYmHfJ7AEp4CVxITWiYwQDbYSF+Zch2qWl9j+dg5Y jZCAhsTDC39ZJzAKzkKybxaSlllIWhYwMq9iZM9NzMxJLzffxAgM2INbfhvsYNx0X+wQozQH i5I472a9M4FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGK01hcU6Gy/zd1+ayFg07bX6B8vD UafWXeSU+f5MusLF1D0uu0v7IMv0R9bv/1jcs13OOGM7e6KQb+TcJraJbe/u6DU4njfJTnx7 PH7/7I17N1Wf0Y9h4ZS5JBL0eOqe5P9GwZtf89wU7jbe/UzLZsrbfWJd9zhvXVfu2+xpL1bT pVFQb6b1WYmlOCPRUIu5qDgRAIVXIpImAgAA Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 09:47:17 -0000 On 2013-08-05 19:45, Ladislav Lhotka wrote: > On Aug 5, 2013, at 5:49 PM, Balazs Lengyel wrote: > >> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>> It is a fact of life that YANG is being used outside NETCONF, and there are more plans for doing do, but with 6020 it is a slippery slope. For example, such non-NETCONF applications of YANG will most likely want to use "must" for expressing semantic constraints. However, the accessible tree for "must" is defined like so: >>> >>> o If the context node represents configuration, the tree is the data >>> in the NETCONF datastore where the context node exists. The XPath >>> root node has all top-level configuration data nodes in all >>> modules as children. >>> >>> o If the context node represents state data, the tree is all state >>> data on the device, and the datastore. The XPath root >>> node has all top-level data nodes in all modules as children. >>> >>> This cannot be unambiguously interpreted in a non-NETCONF context, so it is effectively undefined, which is rather dangerous. >>> So I don't mean to completely redesign YANG, but we cannot, on the other hand, enable non-NETCONF YANG data modelling without providing new definitions. >>> >>> Lada >> In my view Netconf contains the "pure" protocol (encoding, operations, transactional behavior...) and background plumbing (datastores, separation of state and config data, hierarchical data organisation, filtering, connection requirements, session concept, capability negotiation, many of the capabilites, error messages). >> The background plumbing is valid for all access methods (CLI, Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. > I don't think this is true. I2RS will probably have no distinction between config and state data, though they may have read-write and read-only. Sessions and capability negotiation are by no means necessary (RESTCONF doesn't have it). I can actually imagine data modelling without any specific protocol for data exchange. > > Lada IMHO we can debate whether some protocols need some of the features, or whether some of the features belong to the plumbing or the pure protocol, but I still believe that many of the concepts like "NETCONF datastore" above are actually easily understandable without considering the protocol on the wire. If you would just remove the word Netconf from your example paragraphs IMHO they are quite understandable in a protocol independent way. Let me just try as an exercise: Running Datastore: A configuration datastore is defined as the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. The configuration datastore does not include state data or executive commands. The running configuration datastore holds the complete configuration currently active on the network device. Only one configuration datastore of this type exists on the device, and it is always present. The above defeinition is extracted from RFC6241 (I just removed 2 sentences). I think it is a very nice protocol independent definition. Does anyone have a list of features that make YANG protocol (Netconf) dependent? Balazs From andy@yumaworks.com Tue Aug 6 03:38:19 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 1687A21F9D82 for ; Tue, 6 Aug 2013 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkdHEYICgJKN for ; Tue, 6 Aug 2013 03:38:14 -0700 (PDT) Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B021F9D89 for ; Tue, 6 Aug 2013 03:38:13 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id bg4so551773pad.4 for ; Tue, 06 Aug 2013 03:38:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VWm+1gQWkec3RZrNdf/OWDTzmKFdcipOCR5sehQjllM=; b=cVdBKejGTOaURvloWUYxUePR5cW23NpeDY16n1jb0mQ36dwqaLmJd7xfxFccZzjm0c Lc0BQD+q0SmhInTH/8cdOacLbt7EouvVlVo+45k2axaitXsM9HsKeIEYsMLG7gjFtbwi UVrPw6uAXCAks3bGJBysON2Rihug9oJNXLPeR+NepYPUsLLW0HK51Z1dlmwMT1SGTFqy OoicBg/n3yMujYAlsQ8rmTcGgyJZkl9x5CcOUWZghH6mX72/OE3euMVt0KN6quA0+hh4 9yDcamW2AJ3M3Cj/7gWqxGqSM9nsswG/fZFpZ0jHHkfj8RoVSoBzBjF24vJocO9ARSto ld2g== X-Gm-Message-State: ALoCoQmYusFMIc3ro4KkOySGXKRWiTsqkh1bNsNnJoPxUxGihWxG6guALMxPDSAUJCgSU+TH3A2s MIME-Version: 1.0 X-Received: by 10.67.4.197 with SMTP id cg5mr2472396pad.10.1375785493551; Tue, 06 Aug 2013 03:38:13 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 03:38:13 -0700 (PDT) In-Reply-To: <5200C61C.4090103@ericsson.com> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 03:38:13 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: text/plain; charset=ISO-8859-1 Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 10:38:19 -0000 Hi, I implemented the entire YANG-API (-01) draft within our server. There was no problem adapting the XPath at all, because the running config + state is exactly the same context in both. The XPath can be easily applied for calls such as /yang-api/oerations/get-config because the exact same message payload structure is expected. When we add notifications to RESTCONF, we will also make sure that the notification context is exactly the same. The only part of YANG we had to ignore was the insert operation parameters, encoded as XML attributes. The 'point' query string parameter is used instead of embedded XML attributes in the config. The yang-api-01 draft only allows the target node to be inserted, not arbitrary subnodes like an payload. IMO, all proposals to all WGs should be backed up by some running code, even experiments. When theorizing about solutions, it is easy to identify huge problems that actually do not exist, and just as easy to miss huge problems hiding in the implementation details. Andy On Tue, Aug 6, 2013 at 2:47 AM, Balazs Lengyel wrote: > > On 2013-08-05 19:45, Ladislav Lhotka wrote: >> >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel >> wrote: >> >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>> >>>> It is a fact of life that YANG is being used outside NETCONF, and there >>>> are more plans for doing do, but with 6020 it is a slippery slope. For >>>> example, such non-NETCONF applications of YANG will most likely want to use >>>> "must" for expressing semantic constraints. However, the accessible tree for >>>> "must" is defined like so: >>>> >>>> o If the context node represents configuration, the tree is the >>>> data >>>> in the NETCONF datastore where the context node exists. The >>>> XPath >>>> root node has all top-level configuration data nodes in all >>>> modules as children. >>>> >>>> o If the context node represents state data, the tree is all state >>>> data on the device, and the datastore. The XPath root >>>> node has all top-level data nodes in all modules as children. >>>> >>>> This cannot be unambiguously interpreted in a non-NETCONF context, so it >>>> is effectively undefined, which is rather dangerous. >>>> So I don't mean to completely redesign YANG, but we cannot, on the other >>>> hand, enable non-NETCONF YANG data modelling without providing new >>>> definitions. >>>> >>>> Lada >>> >>> In my view Netconf contains the "pure" protocol (encoding, operations, >>> transactional behavior...) and background plumbing (datastores, separation >>> of state and config data, hierarchical data organisation, filtering, >>> connection requirements, session concept, capability negotiation, many of >>> the capabilites, error messages). >>> The background plumbing is valid for all access methods (CLI, Netconf, >>> YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to be redefined. >> >> I don't think this is true. I2RS will probably have no distinction between >> config and state data, though they may have read-write and read-only. >> Sessions and capability negotiation are by no means necessary (RESTCONF >> doesn't have it). I can actually imagine data modelling without any specific >> protocol for data exchange. >> >> Lada > > IMHO we can debate whether some protocols need some of the features, or > whether some of the features belong to the plumbing or the pure protocol, > but I still believe that many of the concepts like "NETCONF datastore" above > are actually easily understandable without considering the protocol on the > wire. If you would just remove the word Netconf from your example paragraphs > IMHO they are quite understandable in a protocol independent way. > > Let me just try as an exercise: > Running Datastore: > > A configuration datastore is defined as the complete set of configuration > data that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. > > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. > > The above defeinition is extracted from RFC6241 (I just removed 2 > sentences). I think it is a very nice protocol independent definition. > > > Does anyone have a list of features that make YANG protocol (Netconf) > dependent? > > Balazs > From lhotka@nic.cz Tue Aug 6 03:56:07 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 EEDCE21F9E2B; Tue, 6 Aug 2013 03:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.243 X-Spam-Level: X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oO8J5D5bNu4z; Tue, 6 Aug 2013 03:56:02 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE7721F9E0D; Tue, 6 Aug 2013 03:56:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C534154047B; Tue, 6 Aug 2013 12:55:55 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehmmIyl9YEOU; Tue, 6 Aug 2013 12:55:48 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 082D35401FC; Tue, 6 Aug 2013 12:55:41 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Martin Bjorklund In-Reply-To: <20130806064507.GA2435@elstar.local> References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Date: Tue, 06 Aug 2013 12:55:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 10:56:07 -0000 Juergen Schoenwaelder writes: > On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >> >> FWIW, this is not how I understand I2RS - I think they explicitly >> mention the configuration data as being one thing, and that they want >> another "direct" method to modify the operational state. >> > > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, > which is likely going to become the I2RS architecture document soon. That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. My conclusion from the discussion with the authors of draft-nitinb-i2rs-rib-info-model-01 is that I2RS data store is a subset of "config false" data from the NETCONF viewpoint, except that they are all read-only for NETCONF whereas the I2RS agent can write some of them. Maybe I2RS folks reading this thread can shed more light on this issue. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 04:15:43 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 0450B21F9B5C for ; Tue, 6 Aug 2013 04:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRnNiI6q99pV for ; Tue, 6 Aug 2013 04:15:38 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) by ietfa.amsl.com (Postfix) with ESMTP id 054D621F9CAD for ; Tue, 6 Aug 2013 04:15:37 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id bv13so215816pdb.30 for ; Tue, 06 Aug 2013 04:15:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=DMlRI5aZma9X7II5JKDQFH26sKNR6j+1HhJnRusW+kc=; b=Ty7XtaevVFqy5BGpOlE+8VBpIw061rN4FV8j9KUYNtz2eHuckImfJ+sjIfsquatlFk JRjk4MkADdRIh+YVpKKecaLspdVkcUliGtsFXlUH4sBoTHl79wCEkehTzPz1I2oDERck P0t6nfPicVqfZNCoOdagddldZYpnxFVBGgoHSpFHwrsMUd4rxW7v0IEKojQAKjrKMeu+ MIr3/RaikHnu5LZh7gfH8syYLH8Rcl8lGyrNTmIuayKr0eyT6bx0R4jWNFdHGdRqceWZ aMZmbK6Xr2T9rSIvlWTGAk0ZfNvtPhp0/oY7DMpkU3xqOptSxsjJUk7c6C8ekfjl1+nM 5hmw== X-Gm-Message-State: ALoCoQm6ZqZNsImX9YamJkHHIzLAbJAmV7Im5oEjIXmwmeD5/ED+ExXwYevyM5k86Fg3mjNenWy6 MIME-Version: 1.0 X-Received: by 10.68.135.162 with SMTP id pt2mr969240pbb.42.1375787737451; Tue, 06 Aug 2013 04:15:37 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:15:37 -0700 (PDT) In-Reply-To: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> Date: Tue, 6 Aug 2013 04:15:37 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 11:15:43 -0000 On Tue, Aug 6, 2013 at 3:55 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >>> >>> FWIW, this is not how I understand I2RS - I think they explicitly >>> mention the configuration data as being one thing, and that they want >>> another "direct" method to modify the operational state. >>> >> >> Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, >> which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration = is considered to be separate from the I2RS data store." So if Fig. 1 indica= tes that I2RS agents interact with Local Config, I assume it has to do so a= s a compliant NETCONF client. So "config true" data stay fully in the NETCO= NF realm. > > My conclusion from the discussion with the authors of draft-nitinb-i2rs-r= ib-info-model-01 is that I2RS data store is a subset of "config false" data= from the NETCONF viewpoint, except that they are all read-only for NETCONF= whereas the I2RS agent can write some of them. > I have not finished the code yet, so I will not comment on details, but it should be quite possible to allow writable operational state to be supported so it is compatible with NETCONF. This meeting it was decided the injected state will not be tied to local config (i.e., made to persist). It only lasts until explicitly removed or the next server reboot. If you remember from the BoF, they want a fast path. So implementing I2RS with RESTCONF or NETCONF is just a matter of eliminating the slow parts ;-) > Maybe I2RS folks reading this thread can shed more light on this issue. > > Lada > >> >> /js >> Andy From j.schoenwaelder@jacobs-university.de Tue Aug 6 04:25: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 0BD8921F9BD8; Tue, 6 Aug 2013 04:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqePkUGhU09K; Tue, 6 Aug 2013 04:25:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85321F9AA3; Tue, 6 Aug 2013 04:25:51 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66F2420BE0; Tue, 6 Aug 2013 13:25:50 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LucUJCObH2_J; Tue, 6 Aug 2013 13:25:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC9820BDF; Tue, 6 Aug 2013 13:25:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5F30127BC3BA; Tue, 6 Aug 2013 13:25:43 +0200 (CEST) Date: Tue, 6 Aug 2013 13:25:43 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org Message-ID: <20130806112543.GA3573@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 11:25:58 -0000 On Tue, Aug 06, 2013 at 12:55:37PM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: > >> > >> FWIW, this is not how I understand I2RS - I think they explicitly > >> mention the configuration data as being one thing, and that they want > >> another "direct" method to modify the operational state. > >> > > > > Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, > > which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. > My reading of the I-D is that the want to read config, not write it. Nothing seems to persists in I2RS. The I2RS Agent will not attempt to retain or reapply state across routing element reboot. Anyway, we may have to check this document to make sure it really clearly says this when it gets final using a terminology we do understand. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Aug 6 04:36: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 45D8D21F96CA; Tue, 6 Aug 2013 04:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtIJBQYUENKz; Tue, 6 Aug 2013 04:36:34 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6C121F9D30; Tue, 6 Aug 2013 04:36:34 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 0F88813F889; Tue, 6 Aug 2013 13:36:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375788993; bh=WtzLsy+IS3S9diJuGMrPuEgmlx/GuWGcrk4RW+nIJqo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=meAds/J1yhbaFdmONt/chopCAMd9L/13IqCXNbiBoGR6u+IILahWmkiyye29cGRVx wO3Z4Hirwdc5RJXa1ens6Y4uk02Pl/uQhmDcirsU5D5iRvPbAIYkwanZo5r8ZLD+8m hM3e8VzWDAoy4TuZAwEZPyiVVT8wOagIMd4QLcto= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 13:36:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 11:36:35 -0000 On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: >=20 > On 2013-08-05 19:45, Ladislav Lhotka wrote: >> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >>=20 >>> On 2013-08-05 16:03, Ladislav Lhotka wrote: >>>> It is a fact of life that YANG is being used outside NETCONF, and = there are more plans for doing do, but with 6020 it is a slippery slope. = For example, such non-NETCONF applications of YANG will most likely want = to use "must" for expressing semantic constraints. However, the = accessible tree for "must" is defined like so: >>>>=20 >>>> o If the context node represents configuration, the tree is the = data >>>> in the NETCONF datastore where the context node exists. The = XPath >>>> root node has all top-level configuration data nodes in all >>>> modules as children. >>>>=20 >>>> o If the context node represents state data, the tree is all = state >>>> data on the device, and the datastore. The XPath = root >>>> node has all top-level data nodes in all modules as children. >>>>=20 >>>> This cannot be unambiguously interpreted in a non-NETCONF context, = so it is effectively undefined, which is rather dangerous. >>>> So I don't mean to completely redesign YANG, but we cannot, on the = other hand, enable non-NETCONF YANG data modelling without providing new = definitions. >>>>=20 >>>> Lada >>> In my view Netconf contains the "pure" protocol (encoding, = operations, transactional behavior...) and background plumbing = (datastores, separation of state and config data, hierarchical data = organisation, filtering, connection requirements, session concept, = capability negotiation, many of the capabilites, error messages). >>> The background plumbing is valid for all access methods (CLI, = Netconf, YANG-Api, I2RS, GUI, etc.) while the "pure" protocol needs to = be redefined. >> I don't think this is true. I2RS will probably have no distinction = between config and state data, though they may have read-write and = read-only. Sessions and capability negotiation are by no means necessary = (RESTCONF doesn't have it). I can actually imagine data modelling = without any specific protocol for data exchange. >>=20 >> Lada > IMHO we can debate whether some protocols need some of the features, = or whether some of the features belong to the plumbing or the pure = protocol, but I still believe that many of the concepts like "NETCONF = datastore" above are actually easily understandable without considering = the protocol on the wire. If you would just remove the word Netconf from = your example paragraphs IMHO they are quite understandable in a protocol = independent way. >=20 > Let me just try as an exercise: > Running Datastore: >=20 > A configuration datastore is defined as the complete set of = configuration data that > is required to get a device from its initial default state into a > desired operational state. The configuration datastore does not > include state data or executive commands. >=20 > The running configuration datastore holds the complete configuration > currently active on the network device. Only one configuration > datastore of this type exists on the device, and it is always > present. >=20 > The above defeinition is extracted from RFC6241 (I just removed 2 = sentences). I think it is a very nice protocol independent definition. This is certainly NOT a NETCONF-independent definition! Consider a data = model for an entire network: there is no single device to apply the data = to, and the "protocol" for updating the data store could be Emacs. But = then one may be able to transform such a document into real = configurations for real devices. =20 >=20 >=20 > Does anyone have a list of features that make YANG protocol (Netconf) = dependent? Apart from many definitions, there are (CL) rules that follow from how = NETCONF was designed. For example: in general it is not necessary that = lists have keys. Databases such as mongodb work fine without keys, = although they allow for defining optional keys for indexing (performance = reasons). YANG has mandatory list keys for config data because edit-config cannot = work without them. Maybe it is easier to start with features that should be common to all = YANG data models: They should be able to describe a schema for a data hierarchy following = the (restricted) XML model, including grammar, data types, semantic = rules and defaults, and similar schemas for RPCs and notifications. I believe it is possible to write a new YANG spec without referring to = any NETCONF data stores, state data or operations. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 05:00:01 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 8632421F963F for ; Tue, 6 Aug 2013 05:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLIXqA6vSSlo for ; Tue, 6 Aug 2013 04:59:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1421F95DC for ; Tue, 6 Aug 2013 04:59:55 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id xa7so320483pbc.17 for ; Tue, 06 Aug 2013 04:59:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=35fOb8LAzuKKVUzgCBzsJQVkl4rHQsK/TzTS5wFKqZw=; b=nZyEsF+a+d0Pdhl4/wQK6cYRR8Bg/FzQ7mW6vqOrwBhm4OAJ/6GblQ0D6SKyaUhheP VfqvpBSWRNVXBtsaSfuDwBOwo3Bm1YrDdH+BIblzROkTLHZF2NU+UqAOZqoo2wMvHyUX pb7hGt9O3FANS6aadYQo9P+fVhUonK+eKmNpr5Jg/nzrUOk8MhBVNx5pEErtloD9qCFN G4hELBSbjR53oY8LGjvt268M5pkSWM9WjUWZQ7VScP8bDHNXv3w+Ii3de/H/rfXi1ZpP PpZ5l9D0t1gIZHuI7suZ9WsNq+JJUeZCwWiBinsVqgtuQCqz5/l68A3UZn3z6ZnmrxIC iGBQ== X-Gm-Message-State: ALoCoQlmOLudxAYS8MLoNgNRbLSHaXK3HOgiHkcCeRYxUGk4CKATP/xt2f3hilMFZUmKGSFZKqo9 MIME-Version: 1.0 X-Received: by 10.66.159.72 with SMTP id xa8mr2899720pab.38.1375790395165; Tue, 06 Aug 2013 04:59:55 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 04:59:54 -0700 (PDT) In-Reply-To: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> Date: Tue, 6 Aug 2013 04:59:54 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 12:00:01 -0000 On Tue, Aug 6, 2013 at 4:36 AM, Ladislav Lhotka wrote: > > On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: > >> >> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel wrote: >>> >>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: ... > Apart from many definitions, there are (CL) rules that follow from how NE= TCONF was designed. For example: in general it is not necessary that lists = have keys. Databases such as mongodb work fine without keys, although they = allow for defining optional keys for indexing (performance reasons). > > YANG has mandatory list keys for config data because edit-config cannot w= ork without them. > I started implementing the optional-key feature in yang-api-01 but bailed on it because it was not going to be compatible with NETCONF, and the corner-cases for network device data structures that don't need keys are very limited. Fortunately we had the foresight to model the operation layer in YANG, so it is trivial to add a custom operation to let the server pick the key value (that is what mongodb is doing as well) like . > Maybe it is easier to start with features that should be common to all YA= NG data models: > They should be able to describe a schema for a data hierarchy following t= he (restricted) XML model, including grammar, data types, semantic rules an= d defaults, and similar schemas for RPCs and notifications. > > I believe it is possible to write a new YANG spec without referring to an= y NETCONF data stores, state data or operations. So far I have not heard anything that indicates RFC 6020 is broken. A new type of choice-stmt or XPath extensions, etc. are new features, not bug fixes. They can go in new RFCs that may update RFC 6020. > > Lada > Andy From lhotka@nic.cz Tue Aug 6 05:18:09 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 DF67321F9B0E; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WbtM2FYMtci; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3941C21F9B0D; Tue, 6 Aug 2013 05:18:09 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 91B4A14011E; Tue, 6 Aug 2013 14:18:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375791487; bh=O+tQI0RYvwUOPPyiGbkecgd83njclmkXKc+4ea9oFP4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=is6yPoGNLkDhoaYg2Frc03hnnqtcqtOIE0LnPbto+TBunQ0yDXnyoiBq/P6gaOAAi pUPE3fIKoh2WZN1Fp3tI9aAwOcK6jbHtx7T/kkKTrsw1ynn2qDNjn80bFXxpR9TbJO 97F5w0nJ09FYWibHQ271lLnc4ITaR8eG71KUbT9I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 6 Aug 2013 14:18:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> To: Netconf , netmod@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 12:18:10 -0000 On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: > ... >>>>> Someone needs to define 'protocol-independent'. If you want to = make >>>>> YANG fully protocol-independent, then you will likely not finish = and >>>>> create just another example of the 2nd systems effect [1]. >>>>=20 > .... >> It depends. YANG 2.0 could work with the general notion of a = "document" and an adaptation specification for a particular protocol = would have to say what the document is supposed to be. For NETCONF, it = could be (depending on the context) one of the datastores, running + = state data, etc. >>=20 >=20 > We got chartered to create YANG because it is not > a general instance document definition language. >=20 > I misspoke when I said "separate" protocol-independent parts. > I meant just identify any differences in the protocol mapping > document. No update to RFC 6020 is needed for this purpose. RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the same = datastores, but still, you have to use RFC 6020 in a very casual way. = For example: 6020 defines a precise encoding for "rpc" nodes, but there = is no element inside in the data part of the HTTP POST method.=20 >=20 > Your YANG-to-JSON draft is not quite what is needed. > The real translation is YANG to RESTCONF (to NETCONF > is already embedded in RFC 6020). Then there are JSON > or XML encoding rules for the RESTCONF protocol. Show me an XML snippet that can be modelled with YANG and cannot be = converted to JSON using my draft (and please don't use anyxml:-). Lada >=20 >=20 > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 6 05:27: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 30F1E21F9DF1 for ; Tue, 6 Aug 2013 05:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nde3qQD9N-ss for ; Tue, 6 Aug 2013 05:27:19 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5486121F9DF0 for ; Tue, 6 Aug 2013 05:27:15 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp2so351690pbb.14 for ; Tue, 06 Aug 2013 05:27:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1XQUgmNuZdpIOhfizgo+FAeY2BhtUCeFXtdBKXe0Sdo=; b=RElMdQUMndkXTGqR+J60Bqd9NR6FRMSQn2MNrVXq2OMQCZXsJF50+qT1zBWHgdgDsi 9VuO0d9ftGu0B+Q6fPJgwVKKEfhxiiR0MFOWBGBY998dHslyxFjCQ0lis5WUyi+PVXjD F2eijYuCPeR0xinRCIb0EbQ+C1TqAMeie+OpVogpAcVNIILphEBbGBvA2yrG4LkDLNG5 w/n6rrT0XvSFhm1tudJNNqRnYMnHn5lb2CqWog1Xa/PEaq++fGDJ82F4hsy+eOaruzVQ g14sWl7W3gfEJ0jEFDpYEvDFAdbk05PFKFG+vA4FOPW1YmgnVklJ4bl9cnWcQBEkLiAB Gg+g== X-Gm-Message-State: ALoCoQn9gonSuUH3tK2hUbdXApWWPSxp+RnHshI+pLZCf2IJmwyBA4Zecxts9m9MAPy0mCQkTFFi MIME-Version: 1.0 X-Received: by 10.68.189.162 with SMTP id gj2mr1232100pbc.96.1375792029403; Tue, 06 Aug 2013 05:27:09 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 6 Aug 2013 05:27:09 -0700 (PDT) In-Reply-To: References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> Date: Tue, 6 Aug 2013 05:27:09 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 12:27:24 -0000 On Tue, Aug 6, 2013 at 5:18 AM, Ladislav Lhotka wrote: > > On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: > >> On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka wrote: >>> Juergen Schoenwaelder writes: >> ... >>>>>> Someone needs to define 'protocol-independent'. If you want to make >>>>>> YANG fully protocol-independent, then you will likely not finish and >>>>>> create just another example of the 2nd systems effect [1]. >>>>> >> .... >>> It depends. YANG 2.0 could work with the general notion of a "document"= and an adaptation specification for a particular protocol would have to sa= y what the document is supposed to be. For NETCONF, it could be (depending = on the context) one of the datastores, running + state data, etc. >>> >> >> We got chartered to create YANG because it is not >> a general instance document definition language. >> >> I misspoke when I said "separate" protocol-independent parts. >> I meant just identify any differences in the protocol mapping >> document. No update to RFC 6020 is needed for this purpose. > > RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the same d= atastores, but still, you have to use RFC 6020 in a very casual way. For ex= ample: 6020 defines a precise encoding for "rpc" nodes, but there is no element inside in the data part of the HTTP POST method. > That will have to get fixed before RFC publication. >> >> Your YANG-to-JSON draft is not quite what is needed. >> The real translation is YANG to RESTCONF (to NETCONF >> is already embedded in RFC 6020). Then there are JSON >> or XML encoding rules for the RESTCONF protocol. > > Show me an XML snippet that can be modelled with YANG and cannot be conve= rted to JSON using my draft (and please don't use anyxml:-). > You missed the point. NETCONF or RESTCONF peers do not send YANG messages. They send NETCONF or RESTCONF protocol messages. Various protocol operations return protocol-related meta-data associated with particular YANG data nodes. Your draft does not support protocol-related meta-data. Maybe this should be specified in the protocol document as an extension to your base encoding document. > Lada > >> Andy From lhotka@nic.cz Tue Aug 6 05:52:08 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 60DBC21F9E46; Tue, 6 Aug 2013 05:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxpZHc8WHGPK; Tue, 6 Aug 2013 05:52:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7277521F9E36; Tue, 6 Aug 2013 05:51:52 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 5F21F14011E; Tue, 6 Aug 2013 14:51:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375793509; bh=ZYv0AVK+R8Y00qQIEhHgM0hnOCAHpnmxsrH+pDxUDs0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oRZtNesdEeo4XU4yNydxaknFJqF7d/DOGHoB8oHdplmVJbBzF6YPWMf5hPddsx1pP OQIHDeaGJAxFrmoa7j68g6VqxpiAneLC59/zwJa7GTCb8UQk6KDNWTQ1ejvAQXmn9W G852pdSCzMBT0cwPJdtwHiVp5QMcXE1Vb9jJmdg8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 6 Aug 2013 14:51:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <5200C61C.4090103@ericsson.com> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 12:52:08 -0000 On Aug 6, 2013, at 1:59 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 4:36 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 6, 2013, at 11:47 AM, Balazs Lengyel = wrote: >>=20 >>>=20 >>> On 2013-08-05 19:45, Ladislav Lhotka wrote: >>>> On Aug 5, 2013, at 5:49 PM, Balazs Lengyel = wrote: >>>>=20 >>>>> On 2013-08-05 16:03, Ladislav Lhotka wrote: > ... >> Apart from many definitions, there are (CL) rules that follow from = how NETCONF was designed. For example: in general it is not necessary = that lists have keys. Databases such as mongodb work fine without keys, = although they allow for defining optional keys for indexing (performance = reasons). >>=20 >> YANG has mandatory list keys for config data because edit-config = cannot work without them. >>=20 >=20 > I started implementing the optional-key feature in yang-api-01 but = bailed > on it because it was not going to be compatible with NETCONF, and the > corner-cases for network device data structures that don't need keys > are very limited. I do see the opposite: there is no sensible key to be assigned to routes = in routing tables (or a list of static routes). It would be nice to be = able to locate a route using *any* subset of route attributes. Of = course, preformance-wise it might be desirable to create indices for = some attributes, but using other attributes should still be allowed. =20 >=20 > Fortunately we had the foresight to model the operation layer in YANG, > so it is trivial to add a custom operation to let the server pick the > key value (that is what mongodb is doing as well) like > . >=20 >=20 >> Maybe it is easier to start with features that should be common to = all YANG data models: >> They should be able to describe a schema for a data hierarchy = following the (restricted) XML model, including grammar, data types, = semantic rules and defaults, and similar schemas for RPCs and = notifications. >>=20 >> I believe it is possible to write a new YANG spec without referring = to any NETCONF data stores, state data or operations. >=20 > So far I have not heard anything that indicates RFC 6020 is broken. Well, I am sure you've heard at least about the "when" statement: Its = context node is ill-defined, and 6020 states no constraints for its = XPath expression, which could lead to various race conditions. This has = been discussed several times in the NETMOD mailing list. > A new type of choice-stmt or XPath extensions, etc. are new features, > not bug fixes. They can go in new RFCs that may update RFC 6020. Introducing a new (alternative) choice statement via an extension should = be a taboo. Instead, it is necessary to change the semantics of the = existing choice statement.=20 Lada >=20 >>=20 >> Lada >>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Aug 6 06:11: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 B143421F99A8; Tue, 6 Aug 2013 06:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vjGXHPMpOOE; Tue, 6 Aug 2013 06:11:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DCA5B21F8B4E; Tue, 6 Aug 2013 06:11:10 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 1E4FC14011E; Tue, 6 Aug 2013 15:11:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375794670; bh=98SRLeTKR1gDOaWgEhDmaa2Q+V5Rozj9Tip8WPwlAnQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=R4znIxN+1YQ/GgcrymBXJIgJzWFuMIqZgUmN5bfmJBnFdSyx4A1YkN7zdrVAkneN2 vaNLRFXjIoSGeQo4B+OtMCZTczrQAVvMoqUwjEiEl40qsRlyAZJo6+KbBAiwqqRwcb H2r5Jn8Eo+DBJxtXyyLxNWMsolNsSd+Z6GTokAwc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 6 Aug 2013 15:11:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F060156-9DD7-4538-880D-704C9C5AE62B@nic.cz> References: <20130805175245.GC897@elstar.local> <46EC47D7-A350-47BF-868D-26D0B61A6A88@nic.cz> <20130805192552.GA1120@elstar.local> To: netmod@ietf.org, Netconf X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 13:11:11 -0000 On Aug 6, 2013, at 2:27 PM, Andy Bierman wrote: > On Tue, Aug 6, 2013 at 5:18 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 6, 2013, at 1:46 PM, Andy Bierman wrote: >>=20 >>> On Tue, Aug 6, 2013 at 3:20 AM, Ladislav Lhotka = wrote: >>>> Juergen Schoenwaelder = writes: >>> ... >>>>>>> Someone needs to define 'protocol-independent'. If you want to = make >>>>>>> YANG fully protocol-independent, then you will likely not finish = and >>>>>>> create just another example of the 2nd systems effect [1]. >>>>>>=20 >>> .... >>>> It depends. YANG 2.0 could work with the general notion of a = "document" and an adaptation specification for a particular protocol = would have to say what the document is supposed to be. For NETCONF, it = could be (depending on the context) one of the datastores, running + = state data, etc. >>>>=20 >>>=20 >>> We got chartered to create YANG because it is not >>> a general instance document definition language. >>>=20 >>> I misspoke when I said "separate" protocol-independent parts. >>> I meant just identify any differences in the protocol mapping >>> document. No update to RFC 6020 is needed for this purpose. >>=20 >> RESTCONF (YANG-API) is pretty close to NETCONF in that it uses the = same datastores, but still, you have to use RFC 6020 in a very casual = way. For example: 6020 defines a precise encoding for "rpc" nodes, but = there is no element inside in the data part of the HTTP POST = method. >>=20 >=20 > That will have to get fixed before RFC publication. >=20 >>>=20 >>> Your YANG-to-JSON draft is not quite what is needed. >>> The real translation is YANG to RESTCONF (to NETCONF >>> is already embedded in RFC 6020). Then there are JSON >>> or XML encoding rules for the RESTCONF protocol. >>=20 >> Show me an XML snippet that can be modelled with YANG and cannot be = converted to JSON using my draft (and please don't use anyxml:-). >>=20 >=20 > You missed the point. > NETCONF or RESTCONF peers do not send YANG messages. > They send NETCONF or RESTCONF protocol messages. > Various protocol operations return protocol-related meta-data > associated with particular YANG data nodes. The document deals just with the data part and it is not intended only = for RESTCONF. >=20 > Your draft does not support protocol-related meta-data. > Maybe this should be specified in the protocol document as an > extension to your base encoding document. Yes, this is possible and IMO better. Lada >=20 >=20 >> Lada >>=20 >>>=20 >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Tue Aug 6 06:13:55 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 19FA121F9EAA; Tue, 6 Aug 2013 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.313 X-Spam-Level: X-Spam-Status: No, score=-3.313 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBMzSMXTwxxN; Tue, 6 Aug 2013 06:13:49 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1621F8B4E; Tue, 6 Aug 2013 06:13:48 -0700 (PDT) Received: from mail164-db9-R.bigfish.com (10.174.16.253) by DB9EHSOBE026.bigfish.com (10.174.14.89) with Microsoft SMTP Server id 14.1.225.22; Tue, 6 Aug 2013 13:13:47 +0000 Received: from mail164-db9 (localhost [127.0.0.1]) by mail164-db9-R.bigfish.com (Postfix) with ESMTP id 6EF161C0154; Tue, 6 Aug 2013 13:13:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -15 X-BigFish: PS-15(zz98dI9371I542I1432Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de096h8275bh8275dh1de097hz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail164-db9 (localhost.localdomain [127.0.0.1]) by mail164-db9 (MessageSwitch) id 1375794826196143_16496; Tue, 6 Aug 2013 13:13:46 +0000 (UTC) Received: from DB9EHSMHS020.bigfish.com (unknown [10.174.16.251]) by mail164-db9.bigfish.com (Postfix) with ESMTP id 2C7D9A0051; Tue, 6 Aug 2013 13:13:46 +0000 (UTC) Received: from DB3PRD0711HT001.eurprd07.prod.outlook.com (157.56.254.197) by DB9EHSMHS020.bigfish.com (10.174.14.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 6 Aug 2013 13:13:42 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.183.34) with Microsoft SMTP Server (TLS) id 14.16.341.1; Tue, 6 Aug 2013 13:13:41 +0000 Message-ID: <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <20130805175340.GD897@elstar.local> Date: Tue, 6 Aug 2013 11:34:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 13:13:55 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Andy Bierman" Cc: "Netconf" ; Sent: Monday, August 05, 2013 6:53 PM > On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > > wrote: > > > We need to start somewhere to discuss the priorities. So, let's start here. > > > > > > What would be your proposal for the development plan? > > > > Here is my development plan priorities: > > > > NETCONF WG: > > > > #1) RESTCONF (was YANG-API) > > #2) Config state, operational state, conditional enablement > > (IMO, all these are related problems) > > What is to be done about config state and operational state? Define them in a standards track RFC. I did look to review some of the modules in Last Call, decided I lacked sufficient understanding of the current thinking on how many 'states' there were and what the differences between them are, went looking for definitions, was unable to find any in any RFC or current I-Ds - and gave up:-( I suspect that if you are full time Netxxx, then this is not a problem; I am not and it is. Tom Petch > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Tue Aug 6 06:29:52 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 1F23F21F8B4E; Tue, 6 Aug 2013 06:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=-0.293, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkHdJIp9AQpe; Tue, 6 Aug 2013 06:29:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id E3B7B21F84DB; Tue, 6 Aug 2013 06:29:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 56B4720BE2; Tue, 6 Aug 2013 15:29:46 +0200 (CEST) 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 nFASzq3gvCEV; Tue, 6 Aug 2013 15:29:46 +0200 (CEST) Received: from elstar.jacobs.jacobs-university.de (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F16AD20BDC; Tue, 6 Aug 2013 15:29:45 +0200 (CEST) Received: by elstar.jacobs.jacobs-university.de (Postfix, from userid 501) id E8B3927BCE38; Tue, 6 Aug 2013 15:29:40 +0200 (CEST) Date: Tue, 6 Aug 2013 15:29:40 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20130806132940.GA3995@elstar.jacobs.jacobs-university.de> Mail-Followup-To: "t.petch" , Netconf , netmod@ietf.org References: <20130805175340.GD897@elstar.local> <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032801ce92a6$b971ea40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 13:29:52 -0000 On Tue, Aug 06, 2013 at 11:34:34AM +0100, t.petch wrote: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Andy Bierman" > Cc: "Netconf" ; > Sent: Monday, August 05, 2013 6:53 PM > > > On Mon, Aug 05, 2013 at 05:35:30AM -0700, Andy Bierman wrote: > > > On Sat, Aug 3, 2013 at 1:58 AM, Ersue, Mehmet (NSN - DE/Munich) > > > wrote: > > > > We need to start somewhere to discuss the priorities. So, let's > start here. > > > > > > > > What would be your proposal for the development plan? > > > > > > Here is my development plan priorities: > > > > > > NETCONF WG: > > > > > > #1) RESTCONF (was YANG-API) > > > #2) Config state, operational state, conditional enablement > > > (IMO, all these are related problems) > > > > What is to be done about config state and operational state? > > Define them in a standards track RFC. > > I did look to review some of the modules in Last Call, decided I lacked > sufficient understanding of the current thinking on how many 'states' > there were and what the differences between them are, went looking for > definitions, was unable to find any in any RFC or current I-Ds - and > gave up:-( > What about RFC 6244 Section 4.3 as a start? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jmh@joelhalpern.com Tue Aug 6 08:42:50 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 1E03521E8088; Tue, 6 Aug 2013 08:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwG3R1NuYeZh; Tue, 6 Aug 2013 08:42:45 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0542421E804D; Tue, 6 Aug 2013 08:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E6D27102318; Tue, 6 Aug 2013 08:42:44 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-254.clppva.east.verizon.net [70.106.134.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id ED6041021D7; Tue, 6 Aug 2013 08:42:43 -0700 (PDT) Message-ID: <52011972.5050406@joelhalpern.com> Date: Tue, 06 Aug 2013 11:42:42 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Juergen Schoenwaelder , Martin Bjorklund , netconf@ietf.org, netmod@ietf.org References: <3C3ECBEE-0E32-49BC-9CB2-7A12E755002F@nic.cz> <51FFC9A1.7050207@ericsson.com> <98D71D8B-2B64-4B39-BEE3-8916F48B09E4@nic.cz> <20130805.220438.348428424.mbj@tail-f.com> <20130806064507.GA2435@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] [netmod] development plan 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, 06 Aug 2013 15:42:50 -0000 If there is an arrow in figure 1 of the I2RS architecture implying that an I2RS agent manipulates the config data, then we need to fix that. The intention of the authors (and the intention agreed in earlier documents) is that I2RS does not mes with config data. The amplification in the architecture document is that I2RS simply does not mess with any persistent data storage at all. I2RS state is lost at reboot. The working group sounded happy with this proposal in Berlin. We will see what happens on the list. Yours, Joel M. Halpern, I2RS Architecture coauthor and netconf/netmod spectator. On 8/6/13 6:55 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > >> On Mon, Aug 05, 2013 at 10:04:38PM +0200, Martin Bjorklund wrote: >>> >>> FWIW, this is not how I understand I2RS - I think they explicitly >>> mention the configuration data as being one thing, and that they want >>> another "direct" method to modify the operational state. >>> >> >> Yes, this is also my reading of draft-atlas-i2rs-architecture-01.txt, >> which is likely going to become the I2RS architecture document soon. > > That document clearly states (Sec. 5.3): "... local device configuration is considered to be separate from the I2RS data store." So if Fig. 1 indicates that I2RS agents interact with Local Config, I assume it has to do so as a compliant NETCONF client. So "config true" data stay fully in the NETCONF realm. > > My conclusion from the discussion with the authors of draft-nitinb-i2rs-rib-info-model-01 is that I2RS data store is a subset of "config false" data from the NETCONF viewpoint, except that they are all read-only for NETCONF whereas the I2RS agent can write some of them. > > Maybe I2RS folks reading this thread can shed more light on this issue. > > Lada > >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 > From andy@yumaworks.com Wed Aug 7 06:59:12 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 5658C21E812D for ; Wed, 7 Aug 2013 06:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drGWl2WS4u9a for ; Wed, 7 Aug 2013 06:59:07 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6961521E8130 for ; Wed, 7 Aug 2013 06:59:05 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u10so1420684pdi.22 for ; Wed, 07 Aug 2013 06:59:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=w9yg98pUCjmfbMJUkD/6rpa+zJVF5EEP3DNzHoIEnd4=; b=ZCBhInIHS7ucSaAwFl7eYnJ2LJ2rvpwyG/dgawBcFrX/xT6OreW4qmQahSexXTbsvl V6uP80VnwZ7vRfD9uhbI8J5AvMOGICtnQN0VGdyyv/gNjbngXSjWW+HoJtzAyZNbpBuk P0QpE6G84MfzVcwS5O+e9kQv13RWx8grK7k2epYUUBf8oqRIvhwcPw2vKGc86X6ra0du pRAccU9aB4an+g+U2bvyWoVGFhxxF23fNwaLbKQ9KYRjsEo9/Ksjoyi+UrlLHNW2u4BJ 15s+CYK6D1buyyvd89PdesukEkD11DMHw0n8180zssQVbKKwKVMZHWq+q74CL2WPAJF2 DNiA== X-Gm-Message-State: ALoCoQmLYMyEsVUBGaQw0DpiHie5Fdv15vwD9g8nhjy0lmW2l85yVnKmR/MQBumiW4JWlFmxzrFV MIME-Version: 1.0 X-Received: by 10.68.135.162 with SMTP id pt2mr860948pbb.42.1375883944843; Wed, 07 Aug 2013 06:59:04 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 7 Aug 2013 06:59:04 -0700 (PDT) In-Reply-To: <20130805173820.GA897@elstar.local> References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> Date: Wed, 7 Aug 2013 06:59:04 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Balazs Lengyel , Martin Bjorklund , netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 07 Aug 2013 13:59:12 -0000 On Mon, Aug 5, 2013 at 10:38 AM, Juergen Schoenwaelder wrote: > On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: >> Hello Martin, >> I missed the original discussion, sorry, but what advantages do we >> get by using submodules instead of separate modules? >> (With modules you at least do not have to republish the main module.) > > A consistent namespace, i.e. all NETCONF configuration objects in one > namespace. > > The IETF sometimes partitions work in ways that reflect the timeline > of how things are done mixed with a bit of procedural aspects. The > question is to what extend we want to expose that to the users of the > data models. > So what is the resolution to this issue? It seems to me 9 people did not like the new changes and 5 people did like them. The module construction should go back to the way it was before (without submodules). It turns out that the normative reference to the RFC with the /netconf root is unavoidable (either via include-stmt or augment-stmt). So we should just publish 1 YANG module and if there is ever another NETCONF configuration feature added, it will be in a new RFC that augments the RFC with the /netconf root. The WG did not actually discuss what 9 - 5 meant, or the followup action items for the next draft. I guess that is supposed to happen on the mailing list. > /js > Andy From lhotka@nic.cz Wed Aug 7 07:18:01 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 4DF5B21E8133 for ; Wed, 7 Aug 2013 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEfDd8HeIIJj for ; Wed, 7 Aug 2013 07:18:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8B18B21E8117 for ; Wed, 7 Aug 2013 07:18:00 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 080F113F865; Wed, 7 Aug 2013 16:17:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375885079; bh=fSwi7cyGErWj7mFBzAyHIZyb9yABdAV7aQzd5vkIPUM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=U1ERLnpfdGzIBfmi40EgBDiXe1JJy8fqJU5G78xjcQYBU5jkvECUXPXUlumhcDL0l cAghlveXUTRpXL/yBLbaAl+jWG3/Uf1spi8YC4gpujRhK5D7rYhkideu7CyWsTUGrM XNdpbJwHdEI0LUfwV33WpPfsY6j4iVYymdDGXYb0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 7 Aug 2013 16:17:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 07 Aug 2013 14:18:01 -0000 On Aug 7, 2013, at 3:59 PM, Andy Bierman wrote: > On Mon, Aug 5, 2013 at 10:38 AM, Juergen Schoenwaelder > wrote: >> On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: >>> Hello Martin, >>> I missed the original discussion, sorry, but what advantages do we >>> get by using submodules instead of separate modules? >>> (With modules you at least do not have to republish the main = module.) >>=20 >> A consistent namespace, i.e. all NETCONF configuration objects in one >> namespace. >>=20 >> The IETF sometimes partitions work in ways that reflect the timeline >> of how things are done mixed with a bit of procedural aspects. The >> question is to what extend we want to expose that to the users of the >> data models. >>=20 >=20 > So what is the resolution to this issue? > It seems to me 9 people did not like the new changes > and 5 people did like them. >=20 > The module construction should go back to the way it was > before (without submodules). It turns out that the > normative reference to the RFC with the /netconf root > is unavoidable (either via include-stmt or augment-stmt). >=20 > So we should just publish 1 YANG module and if there > is ever another NETCONF configuration feature added, > it will be in a new RFC that augments the RFC with the > /netconf root. >=20 > The WG did not actually discuss what 9 - 5 meant, > or the followup action items for the next draft. > I guess that is supposed to happen on the mailing list. I was among the nine, and my understanding was that I was expressing = support to the statement that whenever a submodule changes, the revision = of the main module has to be advanced, too. A practical guideline could be that the main module and all its = submodules should be always published as a single RFC. Lada=20 >=20 >=20 >> /js >>=20 >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Wed Aug 7 07:53: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 D616321E8147 for ; Wed, 7 Aug 2013 07:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsbISsyFN2hl for ; Wed, 7 Aug 2013 07:53:12 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id C2D7321E804E for ; Wed, 7 Aug 2013 07:53:08 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V756o-0000wg-Om; Wed, 07 Aug 2013 16:53:07 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V756o-0005wc-Kf; Wed, 07 Aug 2013 16:53:06 +0200 Message-ID: <52025F52.4060908@bwijnen.net> Date: Wed, 07 Aug 2013 16:53:06 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> In-Reply-To: <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> 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: 20130807 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: 86ab03e524994f79ca2c75a176445dd46aa77818ffc6562a5cb69de54e3d5593 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 07 Aug 2013 14:53:17 -0000 If I see: 4.1. Module 'ietf-netconf-config' file "ietf-netconf-config@2013-05-07.yang" module ietf-netconf-config { namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-config"; prefix "ncconf"; include ietf-netconf-common { revision-date 2013-05-07; } include ietf-netconf-tls { revision-date 2013-05-07; } Then to me that means that: - if a submodule gets updated, then it seems to me that the above needs to be updated too in order to include the proper revision date of the updated submodule. And so that would mean the whole RFC gets updated (or in principle) I guess the new one would obsolete the old one. So what is the problem with that? I asked the question that got 9-5 result, and what I believe I asked (I would have to go back to the audio recording to be 100% sure) is - who can live with (or agrees with) that updating/obsoleteing the whole RFC if a submodule changes (9 hands) - who objects (5 hands). If I get statements of disagreement on the above, then I will go back and listen to the audio, Bert On 8/7/13 4:17 PM, Ladislav Lhotka wrote: > > On Aug 7, 2013, at 3:59 PM, Andy Bierman wrote: > >> On Mon, Aug 5, 2013 at 10:38 AM, Juergen Schoenwaelder >> wrote: >>> On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: >>>> Hello Martin, >>>> I missed the original discussion, sorry, but what advantages do we >>>> get by using submodules instead of separate modules? >>>> (With modules you at least do not have to republish the main module.) >>> >>> A consistent namespace, i.e. all NETCONF configuration objects in one >>> namespace. >>> >>> The IETF sometimes partitions work in ways that reflect the timeline >>> of how things are done mixed with a bit of procedural aspects. The >>> question is to what extend we want to expose that to the users of the >>> data models. >>> >> >> So what is the resolution to this issue? >> It seems to me 9 people did not like the new changes >> and 5 people did like them. >> >> The module construction should go back to the way it was >> before (without submodules). It turns out that the >> normative reference to the RFC with the /netconf root >> is unavoidable (either via include-stmt or augment-stmt). >> >> So we should just publish 1 YANG module and if there >> is ever another NETCONF configuration feature added, >> it will be in a new RFC that augments the RFC with the >> /netconf root. >> >> The WG did not actually discuss what 9 - 5 meant, >> or the followup action items for the next draft. >> I guess that is supposed to happen on the mailing list. > > I was among the nine, and my understanding was that I was expressing support to the statement that whenever a submodule changes, the revision of the main module has to be advanced, too. > > A practical guideline could be that the main module and all its submodules should be always published as a single RFC. > > Lada > >> >> >>> /js >>> >> >> Andy >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Aug 7 07:55:19 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 B896221F995A for ; Wed, 7 Aug 2013 07:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUzI2vxxS8oo for ; Wed, 7 Aug 2013 07:55:08 -0700 (PDT) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id BC17721F9633 for ; Wed, 7 Aug 2013 07:55:05 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl13so2242508pab.6 for ; Wed, 07 Aug 2013 07:55:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Zvz4Ttx/J4dEb4wlJF7T2eAx9tCpyNG2LN95kw0Rq8=; b=CZUXO+sFX4vpFRN616sOSahc9+SiZxcqzBIHcaX+rDF0FV13JVuXzY2GsStuCwKbBd 2Aj9fIfRNlDtQu46M1DRitq7iOFs+vxyj7RMslAu3OgQpSfJ56/GktMayfv+hO8lJOkk /u4ljRCnWZgopkTIV0vLAfTEYYDkmFucwRxDJDiSQ8nEVmN8dbTDKsETjuvhvcWuusWg ioyMEHKmPGes/kvbrS2YCCQYK5nBZPWJBDuFvtJVLU6CoobZyxWnUNDKh1anadh8Y9oW R99famVxpVbFlMcl99Ezxls9872sqWMsWyx4CpO9uJTuNCfrEoFRWzgO7rZ1Slq3HEIi Ktlw== X-Gm-Message-State: ALoCoQnjZ5NaHCu7tW8gZr0hH3Hapv/QreGPiRw6ujcurtaRwOSst+tOS6Hv87GO7DI1pjnanus4 MIME-Version: 1.0 X-Received: by 10.68.131.133 with SMTP id om5mr994278pbb.148.1375887305293; Wed, 07 Aug 2013 07:55:05 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Wed, 7 Aug 2013 07:55:05 -0700 (PDT) In-Reply-To: <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> Date: Wed, 7 Aug 2013 07:55:05 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 07 Aug 2013 14:55:20 -0000 On Wed, Aug 7, 2013 at 7:17 AM, Ladislav Lhotka wrote: > > On Aug 7, 2013, at 3:59 PM, Andy Bierman wrote: > >> On Mon, Aug 5, 2013 at 10:38 AM, Juergen Schoenwaelder >> wrote: >>> On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: >>>> Hello Martin, >>>> I missed the original discussion, sorry, but what advantages do we >>>> get by using submodules instead of separate modules? >>>> (With modules you at least do not have to republish the main module.) >>> >>> A consistent namespace, i.e. all NETCONF configuration objects in one >>> namespace. >>> >>> The IETF sometimes partitions work in ways that reflect the timeline >>> of how things are done mixed with a bit of procedural aspects. The >>> question is to what extend we want to expose that to the users of the >>> data models. >>> >> >> So what is the resolution to this issue? >> It seems to me 9 people did not like the new changes >> and 5 people did like them. >> >> The module construction should go back to the way it was >> before (without submodules). It turns out that the >> normative reference to the RFC with the /netconf root >> is unavoidable (either via include-stmt or augment-stmt). >> >> So we should just publish 1 YANG module and if there >> is ever another NETCONF configuration feature added, >> it will be in a new RFC that augments the RFC with the >> /netconf root. >> >> The WG did not actually discuss what 9 - 5 meant, >> or the followup action items for the next draft. >> I guess that is supposed to happen on the mailing list. > > I was among the nine, and my understanding was that I was expressing support to the statement that whenever a submodule changes, the revision of the main module has to be advanced, too. > > A practical guideline could be that the main module and all its submodules should be always published as a single RFC. > OK. I remember Bert saying we don't have to really decide until the RFC is updated in the future. > Lada > >> Andy From bertietf@bwijnen.net Wed Aug 7 08:37:45 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 5F8F721E8153 for ; Wed, 7 Aug 2013 08:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss3atAV5Ew6Q for ; Wed, 7 Aug 2013 08:37:40 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 81F3521E814A for ; Wed, 7 Aug 2013 08:37:40 -0700 (PDT) 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 1V75nr-0002jU-M8; Wed, 07 Aug 2013 17:37:36 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V75nr-0004k9-Ho; Wed, 07 Aug 2013 17:37:35 +0200 Message-ID: <520269BF.5020807@bwijnen.net> Date: Wed, 07 Aug 2013 17:37:35 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> In-Reply-To: <52025F52.4060908@bwijnen.net> 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: 20130807 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: 86ab03e524994f79ca2c75a176445dd4a8fbe678ad7b43315bfa7601d8ac876f Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 07 Aug 2013 15:37:45 -0000 In another email On 8/7/13 4:55 PM, Andy Bierman wrote: > OK. I remember Bert saying we don't have to really decide > until the RFC is updated in the future. That I did indeed also say. Bert On 8/7/13 4:53 PM, Bert Wijnen (IETF) wrote: > If I see: > 4.1. Module 'ietf-netconf-config' > > > file "ietf-netconf-config@2013-05-07.yang" > > module ietf-netconf-config { > > namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-config"; > prefix "ncconf"; > > include ietf-netconf-common { > revision-date 2013-05-07; > } > > include ietf-netconf-tls { > revision-date 2013-05-07; > } > Then to me that means that: > - if a submodule gets updated, then it seems to me that the above needs to > be updated too in order to include the proper revision date of > the updated submodule. > And so that would mean the whole RFC gets updated (or in > principle) I guess the new one would obsolete the old one. > > So what is the problem with that? > > I asked the question that got 9-5 result, and what I believe I asked > (I would have to go back to the audio recording to be 100% sure) is > > - who can live with (or agrees with) that updating/obsoleteing the whole > RFC if a submodule changes (9 hands) > - who objects (5 hands). > > If I get statements of disagreement on the above, then I will go > back and listen to the audio, > > Bert > > > On 8/7/13 4:17 PM, Ladislav Lhotka wrote: >> >> On Aug 7, 2013, at 3:59 PM, Andy Bierman wrote: >> >>> On Mon, Aug 5, 2013 at 10:38 AM, Juergen Schoenwaelder >>> wrote: >>>> On Mon, Aug 05, 2013 at 05:31:19PM +0200, Balazs Lengyel wrote: >>>>> Hello Martin, >>>>> I missed the original discussion, sorry, but what advantages do we >>>>> get by using submodules instead of separate modules? >>>>> (With modules you at least do not have to republish the main module.) >>>> >>>> A consistent namespace, i.e. all NETCONF configuration objects in one >>>> namespace. >>>> >>>> The IETF sometimes partitions work in ways that reflect the timeline >>>> of how things are done mixed with a bit of procedural aspects. The >>>> question is to what extend we want to expose that to the users of the >>>> data models. >>>> >>> >>> So what is the resolution to this issue? >>> It seems to me 9 people did not like the new changes >>> and 5 people did like them. >>> >>> The module construction should go back to the way it was >>> before (without submodules). It turns out that the >>> normative reference to the RFC with the /netconf root >>> is unavoidable (either via include-stmt or augment-stmt). >>> >>> So we should just publish 1 YANG module and if there >>> is ever another NETCONF configuration feature added, >>> it will be in a new RFC that augments the RFC with the >>> /netconf root. >>> >>> The WG did not actually discuss what 9 - 5 meant, >>> or the followup action items for the next draft. >>> I guess that is supposed to happen on the mailing list. >> >> I was among the nine, and my understanding was that I was expressing support to the statement that whenever a submodule changes, >> the revision of the main module has to be advanced, too. >> >> A practical guideline could be that the main module and all its submodules should be always published as a single RFC. >> >> Lada >> >>> >>> >>>> /js >>>> >>> >>> Andy >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From j.schoenwaelder@jacobs-university.de Thu Aug 8 00:54:02 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 4A99411E81CF for ; Thu, 8 Aug 2013 00:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.236 X-Spam-Level: X-Spam-Status: No, score=-103.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9Z2vTRrGqvS for ; Thu, 8 Aug 2013 00:53:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DB8A911E81CA for ; Thu, 8 Aug 2013 00:53:56 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E974D20BF1; Thu, 8 Aug 2013 09:53:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Kkdw8d5BJ2Ne; Thu, 8 Aug 2013 09:53:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A63D020BEF; Thu, 8 Aug 2013 09:53:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5EF5D27C03DA; Thu, 8 Aug 2013 09:53:48 +0200 (CEST) Date: Thu, 8 Aug 2013 09:53:48 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20130808075348.GA9139@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Ladislav Lhotka , netconf@ietf.org References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52025F52.4060908@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 07:54:02 -0000 On Wed, Aug 07, 2013 at 04:53:06PM +0200, Bert Wijnen (IETF) wrote: > If I see: > 4.1. Module 'ietf-netconf-config' > > > file "ietf-netconf-config@2013-05-07.yang" > > module ietf-netconf-config { > > namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-config"; > prefix "ncconf"; > > include ietf-netconf-common { > revision-date 2013-05-07; > } > > include ietf-netconf-tls { > revision-date 2013-05-07; > } > Then to me that means that: > - if a submodule gets updated, then it seems to me that the above needs to > be updated too in order to include the proper revision date of > the updated submodule. > And so that would mean the whole RFC gets updated (or in > principle) I guess the new one would obsolete the old one. > > So what is the problem with that? This is what the I-D says: This organizations allows to add configuration support for additional NETCONF features while keeping the number of namespaces that have to be dealt with down to a minimum. If new definitions need to be added to the NETCONF configuration data model, either an existing YANG submodule can be updated or a new YANG submodule can be written. In both cases, the new document will carry an updated version of the "ietf-netconf-config" module importing the submodules. It is fine to add an explicit statement that import by revision is to be used. > - who can live with (or agrees with) that updating/obsoleteing the whole > RFC if a submodule changes (9 hands) The basic question in my view is whether we want one namespace for NETCONF configuration objects or multiple namespaces, one for the TLS config objects, one for the SSH config objects, one for general NETCONF config objects (e.g. idle timeouts etc. that do not exist in RFCs yet but it seems they will do them at some point in time since implementations commonly have such configuration parameters). There is flexibility how submodules map to RFCs and I would simply trust the WG to take the most suitable decision when documents are written or revised - I do not see a need to put up rules in an attempt to protect or guide future WG decisions. I personally prefer to have a single /netconf root in a single namespace with all NETCONF related config objects below it instead of /netconf-tls, /netconf-ssh, /netconf-misc, ... with different namespaces (or a single /netconf but then below it /netconf/tls and /netconf/ssh, /netconf/misc, etc, each in a separate namespace). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Thu Aug 8 01:10:25 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 78B7D21E8056 for ; Thu, 8 Aug 2013 01:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfU9q2YRlqhS for ; Thu, 8 Aug 2013 01:10:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 44C9B21E804C for ; Thu, 8 Aug 2013 01:10:23 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:a9a9:a555:bcf3:ba68] (unknown [IPv6:2001:1488:ac14:1400:a9a9:a555:bcf3:ba68]) by mail.nic.cz (Postfix) with ESMTPSA id 9BF8513F865; Thu, 8 Aug 2013 10:10:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375949415; bh=+IAjbAwWPbpdjp7f4go4QZZswQp2aMcu0Blr6DgYW38=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=dWZtAbb7+QqK8PpMqdeSjfW8VVpnIp/79xIX4aiad+v8II0DsOSkvOOBEVFGhO8l5 TwYvI/reLXuv6yx+YajsJnATeJ9IK0o5O6+pkWC3jGyqlCjoUdbTJYpAaIa6w4m+rj onoBCn8GCrLzii1vqfSSUgBWxXoVxFRUgoQoK0v4= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130808075348.GA9139@elstar.local> Date: Thu, 8 Aug 2013 10:10:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> <20130808075348.GA9139@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 08:10:25 -0000 On Aug 8, 2013, at 9:53 AM, Juergen Schoenwaelder = wrote: > On Wed, Aug 07, 2013 at 04:53:06PM +0200, Bert Wijnen (IETF) wrote: >> If I see: >> 4.1. Module 'ietf-netconf-config' >>=20 >>=20 >> file "ietf-netconf-config@2013-05-07.yang" >>=20 >> module ietf-netconf-config { >>=20 >> namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-config"; >> prefix "ncconf"; >>=20 >> include ietf-netconf-common { >> revision-date 2013-05-07; >> } >>=20 >> include ietf-netconf-tls { >> revision-date 2013-05-07; >> } >> Then to me that means that: >> - if a submodule gets updated, then it seems to me that the above = needs to >> be updated too in order to include the proper revision date of >> the updated submodule. >> And so that would mean the whole RFC gets updated (or in >> principle) I guess the new one would obsolete the old one. >>=20 >> So what is the problem with that? >=20 > This is what the I-D says: >=20 > This organizations allows to add configuration support for = additional > NETCONF features while keeping the number of namespaces that have to > be dealt with down to a minimum. If new definitions need to be = added > to the NETCONF configuration data model, either an existing YANG > submodule can be updated or a new YANG submodule can be written. In > both cases, the new document will carry an updated version of the > "ietf-netconf-config" module importing the submodules. >=20 > It is fine to add an explicit statement that import by revision is to > be used. >=20 >> - who can live with (or agrees with) that updating/obsoleteing the = whole >> RFC if a submodule changes (9 hands) >=20 > The basic question in my view is whether we want one namespace for > NETCONF configuration objects or multiple namespaces, one for the TLS > config objects, one for the SSH config objects, one for general > NETCONF config objects (e.g. idle timeouts etc. that do not exist in > RFCs yet but it seems they will do them at some point in time since > implementations commonly have such configuration parameters). IMO, submodules should be reserved for the party that is in control of = the main module (that can be an IETF WG). Other parties (including other = WGs) should always use another namespace. Lada >=20 > There is flexibility how submodules map to RFCs and I would simply > trust the WG to take the most suitable decision when documents are > written or revised - I do not see a need to put up rules in an attempt > to protect or guide future WG decisions. >=20 > I personally prefer to have a single /netconf root in a single > namespace with all NETCONF related config objects below it instead of > /netconf-tls, /netconf-ssh, /netconf-misc, ... with different > namespaces (or a single /netconf but then below it /netconf/tls and > /netconf/ssh, /netconf/misc, etc, each in a separate namespace). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Thu Aug 8 01:13:55 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 E1CDA21F9951 for ; Thu, 8 Aug 2013 01:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVIxAN0NdN11 for ; Thu, 8 Aug 2013 01:13:49 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEAC11E8110 for ; Thu, 8 Aug 2013 01:13:17 -0700 (PDT) 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 1V7LLN-0003X0-A2; Thu, 08 Aug 2013 10:13:15 +0200 Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1V7LLN-0007G0-4x; Thu, 08 Aug 2013 10:13:13 +0200 Message-ID: <52035319.7010901@bwijnen.net> Date: Thu, 08 Aug 2013 10:13:13 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ladislav Lhotka References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> <20130808075348.GA9139@elstar.local> <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> In-Reply-To: <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> 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: 20130808 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: 86ab03e524994f79ca2c75a176445dd45ad637e9e2a8de5db2c00ecb4d0ff1f3 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 08:13:56 -0000 Lada, can I conclude from the below that you agree with the approach that Juergen has currently taken? Bert On 8/8/13 10:10 AM, Ladislav Lhotka wrote: >>> - who can live with (or agrees with) that updating/obsoleteing the whole >>> >> RFC if a submodule changes (9 hands) >> > >> >The basic question in my view is whether we want one namespace for >> >NETCONF configuration objects or multiple namespaces, one for the TLS >> >config objects, one for the SSH config objects, one for general >> >NETCONF config objects (e.g. idle timeouts etc. that do not exist in >> >RFCs yet but it seems they will do them at some point in time since >> >implementations commonly have such configuration parameters). > IMO, submodules should be reserved for the party that is in control of the main module (that can be an IETF WG). Other parties (including other WGs) should always use another namespace. > > Lada > From jonathan@hansfords.net Thu Aug 8 07:28: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 48EDB11E81D0 for ; Thu, 8 Aug 2013 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xDdfxehtMv2 for ; Thu, 8 Aug 2013 07:28:52 -0700 (PDT) Received: from avasout07.plus.net (avasout07.plus.net [84.93.230.235]) by ietfa.amsl.com (Postfix) with ESMTP id 94AF411E812A for ; Thu, 8 Aug 2013 07:28:50 -0700 (PDT) Received: from webmail.plus.net ([84.93.228.66]) by avasout07 with smtp id AEUn1m00C1SbfYc01EUnEL; Thu, 08 Aug 2013 15:28:49 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=bbFSDo/B c=1 sm=1 tr=0 a=C5+YawzV8SR07mwocaP9vA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=seuxZKWH-PcA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=OMyYYGjg7OcA:10 a=Qi8pfYrODZNg8j6IkaMA:9 a=QEXdDO2ut3YA:10 a=p2qcniGnSJWr9HzKfTwA:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 08 Aug 2013 15:28:47 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_6f2d0116287717b1ff52914d246e9bf3" Date: Thu, 08 Aug 2013 15:28:47 +0100 From: Jonathan Hansford To: Message-ID: X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Subject: [Netconf] The configuration datastore and :writable-running 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, 08 Aug 2013 14:28:58 -0000 --=_6f2d0116287717b1ff52914d246e9bf3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi, Please can someone clarify for me the situation with regards the base model, the configuration datastore and the :writable-running capability? RFC 6241 states: "Only the configuration datastore is present in the base model". Does that imply the configuration datastore is always present, or that it will persist once it has been created (since "the configuration datastore cannot be deleted")? With respect to :writable-running: Section 7.2 identifies as a suitable target for the edit-config base protocol operation. Section 7.3 states: "Even if it advertises the :writable-running capability, a device MAY choose not to support the configuration datastore as the parameter of a operation". Section 8.2.1 states: "The :writable-running capability indicates that the device supports direct writes to the configuration datastore. In other words, the device supports and operations where the configuration is the target". Section 8.2.5.1 states: "The :writable-running capability modifies the operation to accept the element as a ". Section 8.2.5.2 states: "The :writable-running capability modifies the operation to accept the element as a ". How does :writable-running change in any way the edit-config and copy-config operations for the base model? Can a device only supporting the base model and not supporting :writable-running choose not to support edit-config on the configuration datastore and return an error? If so, does :writable-running mandate the support of edit-config on the configuration datastore? If not, what does :writable-running add? What does :writable-running add to the copy-config operation, if a device can choose not to support the configuration datastore as the when supporting the :writable-running capability? Presumably if a device only supports the base model and does not support :writable-running, the configuration datastore is read-only as far as NETCONF is concerned. Correct? Thanks, jh --=_6f2d0116287717b1ff52914d246e9bf3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hi,

Please can someone clarify for me the situation with regards the base mo= del, the <running> configuration datastore and the :writable-running = capability?

RFC 6241 states: "Only the <running> configuration datastore is pr= esent in the base model". Does that imply the <running> configuration= datastore is always present, or that it will persist once it has been crea= ted (since "the <running> configuration datastore cannot be deleted")= ?

With respect to :writable-running:

Section 7.2 identifies <running> as = a suitable target for the edit-config base protocol operation.

Section 7.3 states: "Even if it advertises= the :writable-running capability, a device MAY choose not to support the &= lt;running> configuration datastore as the <target> parameter of a= <copy-config> operation".

Section 8.2.1 states: "The :writable-runni= ng capability indicates that the device supports direct writes to the <r= unning> configuration datastore. In other words, the device supports <= ;edit-config> and <copy-config> operations where the <running&g= t; configuration is the target".

Section 8.2.5.1 states: "The :writable-run= ning capability modifies the <edit-config> operation to accept the &l= t;running> element as a <target>".

Section 8.2.5.2 states: "The :writable-run= ning capability modifies the <copy-config> operation to accept the &l= t;running> element as a <target>".

How does :writable-running change in any way the edit-config and copy-co= nfig operations for the base model?

Can a device only supporting the base model and not supporting :writable= -running choose not to support edit-config on the <running> configura= tion datastore and return an error?

If so, does :writable-running mandate the support of edit-config on the = <running> configuration datastore?

If not, what does :writable-running add?

What does :writable-running add to the copy-config operation, if a devic= e can choose not to support the <running> configuration datastore as = the <target> when supporting the :writable-running capability?

Presumably if a device only supports the base model and does not support= :writable-running, the <running> configuration datastore is read-onl= y as far as NETCONF is concerned. Correct?

Thanks,

jh

--=_6f2d0116287717b1ff52914d246e9bf3-- From andy@yumaworks.com Thu Aug 8 07:48:25 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 625BD21F9D52 for ; Thu, 8 Aug 2013 07:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Tl8DLPlQS8E for ; Thu, 8 Aug 2013 07:48:21 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46E2711E81E1 for ; Thu, 8 Aug 2013 07:48:21 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id fz6so788119pac.3 for ; Thu, 08 Aug 2013 07:48:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sX9IWs17o0WOvIlLuH6iCm7mktSvvEGRixddtu02lVY=; b=Hn5NW3iCXY8n6zUeJkXtDLD+xxnMGT15ucvkIsr1DcLsnV5v5CnQoQo3sf6b3/9p3/ HVFHQpIaXRQvnByjSvMLk+omZh6ZwYcT0ggLWi/bcanTrQSYDJ/838+ul220b5SZfWev vskTEdhSvhWaQX8o1K0WfKbhnRkX6Cbl9MszOutnAwJglCkM6d3y6cSgbvbLUs8b+X0X E0YJvWOH/HPHm8PkMusWklFASzhCv6k+xHmCb430F0LbWBEt9RPghkQlkf8y7TuUd7qK Inz0SsQ++iI6CpMtoOhMOsV5Rg1vpqw9fdJf59yCuFtYhdu2OjA8kRepZBe7kscbEnNJ m5BA== X-Gm-Message-State: ALoCoQnuJwY7FnB7gPbyQZ4uM0KP0g8nkxUbPfpfXyTuyqH3Bxq9DaoMGLp5pA63XqWK0QWq8fWG MIME-Version: 1.0 X-Received: by 10.68.135.162 with SMTP id pt2mr6637255pbb.42.1375973300812; Thu, 08 Aug 2013 07:48:20 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 8 Aug 2013 07:48:20 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Aug 2013 07:48:20 -0700 Message-ID: From: Andy Bierman To: Jonathan Hansford Content-Type: text/plain; charset=ISO-8859-1 Cc: netconf@ietf.org Subject: Re: [Netconf] The configuration datastore and :writable-running 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, 08 Aug 2013 14:48:25 -0000 On Thu, Aug 8, 2013 at 7:28 AM, Jonathan Hansford wrote: > Hi, > > Please can someone clarify for me the situation with regards the base model, > the configuration datastore and the :writable-running capability? > All NETCONF devices have a running datastore. By default, it is read-only. Writable-running capability means the server allows the running datastore to be edited directly with or . Candidate capability means the server allows the candidate datastore to be edited directly with or . The candidate is applied to the running datastore (all-or-nothing) with the operation. Capabilities (other than base:1.1) are optional-to-implement. That is why they are included in the . If they were mandatory to implement they would be covered by the "base:1.1" capability. Andy > RFC 6241 states: "Only the configuration datastore is present in > the base model". Does that imply the configuration datastore is > always present, or that it will persist once it has been created (since "the > configuration datastore cannot be deleted")? > > With respect to :writable-running: > > Section 7.2 identifies as a suitable target for the edit-config > base protocol operation. > > Section 7.3 states: "Even if it advertises the :writable-running capability, > a device MAY choose not to support the configuration datastore as > the parameter of a operation". > > Section 8.2.1 states: "The :writable-running capability indicates that the > device supports direct writes to the configuration datastore. In > other words, the device supports and operations > where the configuration is the target". > > Section 8.2.5.1 states: "The :writable-running capability modifies the > operation to accept the element as a ". > > Section 8.2.5.2 states: "The :writable-running capability modifies the > operation to accept the element as a ". > > How does :writable-running change in any way the edit-config and copy-config > operations for the base model? > > Can a device only supporting the base model and not supporting > :writable-running choose not to support edit-config on the > configuration datastore and return an error? > > If so, does :writable-running mandate the support of edit-config on the > configuration datastore? > > If not, what does :writable-running add? > > What does :writable-running add to the copy-config operation, if a device > can choose not to support the configuration datastore as the > when supporting the :writable-running capability? > > Presumably if a device only supports the base model and does not support > :writable-running, the configuration datastore is read-only as far > as NETCONF is concerned. Correct? > > Thanks, > > jh > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From jonathan@hansfords.net Thu Aug 8 08:07: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 523A621E80A3 for ; Thu, 8 Aug 2013 08:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1GYSsHuBr8q for ; Thu, 8 Aug 2013 08:07:02 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4F21F99B0 for ; Thu, 8 Aug 2013 08:06:58 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id AF6v1m002283uBY01F6wHe; Thu, 08 Aug 2013 16:06:56 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=bL0vfpOZ c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=gBh6aikjKukA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=LcRfbuCf9oUA:10 a=wFxLM-vudxhXxE72Gy4A:9 a=QEXdDO2ut3YA:10 a=1rgnPY4EEFsA:10 a=pkHuQKNqyVTPtflpZY4A:9 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Thu, 08 Aug 2013 16:06:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2990cdde99925bed742d7f96354307e6" Date: Thu, 08 Aug 2013 16:06:55 +0100 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: Message-ID: <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netconf@ietf.org Subject: Re: [Netconf] The configuration datastore and :writable-running 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, 08 Aug 2013 15:07:11 -0000 --=_2990cdde99925bed742d7f96354307e6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 I don't recall seeing it stated anywhere in RFC 6241 that the running datastore defaults to read-only. Would it be worth raising an erratum to clarify that point? On 2013-08-08 15:48, Andy Bierman wrote: > On Thu, Aug 8, 2013 at 7:28 AM, Jonathan Hansford > wrote: > >> Hi, Please can someone clarify for me the situation with regards the base model, the configuration datastore and the :writable-running capability? > > All NETCONF devices have a running datastore. > By default, it is read-only. > > Writable-running capability means the server allows the running datastore > to be edited directly with or . > > Candidate capability means the server allows the candidate datastore > to be edited directly with or . > The candidate is applied to the running datastore (all-or-nothing) > with the operation. > > Capabilities (other than base:1.1) are optional-to-implement. > That is why they are included in the . If they were mandatory > to implement they would be covered by the "base:1.1" capability. > > Andy --=_2990cdde99925bed742d7f96354307e6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I don't recall seeing it stated anywhere in RFC 6241 that the running da= tastore defaults to read-only. Would it be worth raising an erratum to clar= ify that point?

On 2013-08-08 15:48, Andy Bierman wrote:

On Thu, Aug 8, 2013 at 7:28 AM, Jonathan Hansford
<Jonathan@hansfords.net>=
; wrote:
Hi, Please can someone clarify for me= the situation with regards the base model, the <running> configurati= on datastore and the :writable-running capability?
All NETCONF devices have a running datastore.
By default, it is read-only.

Writable-running capability means the server allows the running datastore
to be edited directly with <edit-config> or <copy-config>.

Candidate capability means the server allows the candidate datastore
to be edited directly with <edit-config> or <copy-config>.
The candidate is applied to the running datastore (all-or-nothing)
with the <commit> operation.

Capabilities (other than base:1.1) are optional-to-implement.
That is why they are included in the <hello>.  If they were mandatory
to implement they would be covered by the "base:1.1" capability.


Andy
--=_2990cdde99925bed742d7f96354307e6-- From j.schoenwaelder@jacobs-university.de Thu Aug 8 08:17: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 E9D8D11E8168 for ; Thu, 8 Aug 2013 08:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.236 X-Spam-Level: X-Spam-Status: No, score=-103.236 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9x9nUX+uAQGH for ; Thu, 8 Aug 2013 08:17:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id B35B011E8156 for ; Thu, 8 Aug 2013 08:17:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA51620C09; Thu, 8 Aug 2013 17:17:45 +0200 (CEST) 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 JLEO6IuIW1BS; Thu, 8 Aug 2013 17:17:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F06620AFE; Thu, 8 Aug 2013 17:17:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 7CF3427C29DF; Thu, 8 Aug 2013 17:17:40 +0200 (CEST) Date: Thu, 8 Aug 2013 17:17:40 +0200 From: Juergen Schoenwaelder To: Jonathan Hansford Message-ID: <20130808151740.GA10747@elstar.local> Mail-Followup-To: Jonathan Hansford , Andy Bierman , netconf@ietf.org References: <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] The configuration datastore and :writable-running 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, 08 Aug 2013 15:17:52 -0000 On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote: > > I don't recall seeing it stated anywhere in RFC 6241 that the > running datastore defaults to read-only. Would it be worth raising an > erratum to clarify that point? > Implementing NETCONF read-only has obviously little value for real configuration management. The reason why we have :writable-running and :candidate is that some major vendors use very different models when it comes to making configuration changes and as such you will see implementations that either announce :writable-running or :candidate or :writable-running and :candidate together. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Thu Aug 8 08:37:43 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 25FE121F9E24 for ; Thu, 8 Aug 2013 08:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcQ+kQPTox+6 for ; Thu, 8 Aug 2013 08:37:38 -0700 (PDT) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by ietfa.amsl.com (Postfix) with ESMTP id 19F4E11E8132 for ; Thu, 8 Aug 2013 08:37:38 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id kp13so3636541pab.35 for ; Thu, 08 Aug 2013 08:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=UaYMmKxoqSdwgSytECccbd5e/B6aANMGrrWULzqkp4A=; b=Kag44YoTYcXJYDcuzCFete866B00z9Gus+bQvPA3jb0MGEeLTRzeDuFgp4XBPaHUdm opIo8kqA+hlYeX9EZw6q/69aXo1731KaCakmNr25Vkiv85umB6Hxd5iN9t/uWw6+ppMd jZz6IuF0WgTHcY4kRq3zR5WxPjv3Dq+iEmv1It7V9s62WpPubBwcYwvcI10PxbZhlgun c5ORYGpaLi6J3qLKc5anBtcmX+e9qC72R+gJote7ADFSokRevs9CnMsugdOmu92hgTMT X5rfuZqvglHG0IDM2vS9zuKp4YIsiF5PDj8KghspUuOAkiniK0vkePCDeI3HNma3sD+/ vXvQ== X-Gm-Message-State: ALoCoQmWTGTnlLRqQW5peB/3sjhE+bqijA+UOazMFnXo5TuTwSYx0eikeWAJDEy2oj5238VJsg5J MIME-Version: 1.0 X-Received: by 10.66.219.38 with SMTP id pl6mr6871949pac.59.1375976257772; Thu, 08 Aug 2013 08:37:37 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 8 Aug 2013 08:37:37 -0700 (PDT) In-Reply-To: <20130808151740.GA10747@elstar.local> References: <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local> Date: Thu, 8 Aug 2013 08:37:37 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Jonathan Hansford , Andy Bierman , netconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Netconf] The configuration datastore and :writable-running 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, 08 Aug 2013 15:37:43 -0000 On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote: >> >> I don't recall seeing it stated anywhere in RFC 6241 that the >> running datastore defaults to read-only. Would it be worth raising an >> erratum to clarify that point? >> > > Implementing NETCONF read-only has obviously little value for real > configuration management. > Yes, but base:1.1 does not actually require any editing capabilities. What if a company wanted to use NETCONF for monitoring and/or notifications? Then the base:1.1 operation set is simple to implement, and they do not advertise any optional capabilities, so the client should figure out what operations are allowed. > The reason why we have :writable-running and :candidate is that some > major vendors use very different models when it comes to making > configuration changes and as such you will see implementations that > either announce :writable-running or :candidate or :writable-running > and :candidate together. > :candidate and :writable-running together should be considered deprecated. This is a degenerate use-case for concurrent transactions. The WG should standardize this properly at some point in the future, so clients can use a predictable standard transaction model. > /js > Andy From lhotka@nic.cz Thu Aug 8 08:58:02 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 AB85211E8156 for ; Thu, 8 Aug 2013 08:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRxkrclstjno for ; Thu, 8 Aug 2013 08:58:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 4548511E81A7 for ; Thu, 8 Aug 2013 08:57:43 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 119EF13F865; Thu, 8 Aug 2013 17:57:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375977456; bh=wD2Dv2TetlSlusMGwCkqgsVSsmbXgfcRmHc6s9bfbxc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pUuIQOfZbR/jnsfMAgCqq46P6mfFtcJFq6DJiwTLcpo+h2aaT2Dxe5epgEjT/2xlR kzKcHjx0hXkI9UlgcNjp5K13nvonb2QM2tU91wrA8hnFHn/TXt0qdsk5/kqG7799dz 068D4g9y/QgBSDGUNJt00aAPB42M31uXImEJUVd8= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <52035319.7010901@bwijnen.net> Date: Thu, 8 Aug 2013 17:57:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> <20130808075348.GA9139@elstar.local> <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> <52035319.7010901@bwijnen.net> To: Bert Wijnen (IETF) X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 15:58:02 -0000 On Aug 8, 2013, at 10:13 AM, Bert Wijnen (IETF) = wrote: > Lada, can I conclude from the below that you agree with the > approach that Juergen has currently taken? In this case, I think it is not realistic to assume that additional = submodules will be defined in other documents, because every revision of = such a submodule would require an update to the NETCONF-over-TLS = document, which would be counterproductive. Therefore, 5539bis should IMO simply define the "ietf-netconf-tls" = module, essentially with the contents of the current "ietf-netconf-tls" = submodule. Lada >=20 > Bert >=20 > On 8/8/13 10:10 AM, Ladislav Lhotka wrote: >>>> - who can live with (or agrees with) that updating/obsoleteing the = whole >>>> >> RFC if a submodule changes (9 hands) >>> > >>> >The basic question in my view is whether we want one namespace for >>> >NETCONF configuration objects or multiple namespaces, one for the = TLS >>> >config objects, one for the SSH config objects, one for general >>> >NETCONF config objects (e.g. idle timeouts etc. that do not exist = in >>> >RFCs yet but it seems they will do them at some point in time since >>> >implementations commonly have such configuration parameters). >> IMO, submodules should be reserved for the party that is in control = of the main module (that can be an IETF WG). Other parties (including = other WGs) should always use another namespace. >>=20 >> Lada >>=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Thu Aug 8 09:23: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 3F3BA21F9CF8 for ; Thu, 8 Aug 2013 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9j18kvSMNab for ; Thu, 8 Aug 2013 09:23:12 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 09E4011E80EC for ; Thu, 8 Aug 2013 09:23:12 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so3472624pbc.29 for ; Thu, 08 Aug 2013 09:23:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NGtgEfuPOYtYhgs9eyOgETeZfwmEBUgVmx7aibWO02k=; b=R2STTm9CbgJ3g4+pKE+IALJP1x0/29Svu/j0BMApslU1D2D5LBHkR//hbREJ5ASxy2 q1pDNg2nfQfkuXRKumgPmFEDzbGoYCQspJjG5Z7M4iopD0wdCO/Ay1oe1eun4mIOprNK E850KsCJpoMbh6eyWYgY6P5ya0I88gmCtEoy62UtoOsWpckGnx2tk5Aya1cgjrCh/2Aa KXSDvZyAlE+ufEHUspQgx2MbjFUE6jCbGOF5qKOY3JHHYSmgGzIplxctzKNYBMOvcx2s nSfLypmQ2fOhZthMKvReG9bltxYcam/jE02uSYTjV56bjCkHz+5CoC0lYXecNGsPVzJ8 Zafg== X-Gm-Message-State: ALoCoQkVu8YaqNr040OHGIKQyoyFRx3pEVyPhGnTJGixdtcuZyV1zMNyiv3rAegey0QgB2pclLMy MIME-Version: 1.0 X-Received: by 10.68.170.133 with SMTP id am5mr6911453pbc.104.1375978991633; Thu, 08 Aug 2013 09:23:11 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Thu, 8 Aug 2013 09:23:11 -0700 (PDT) In-Reply-To: References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> <20130808075348.GA9139@elstar.local> <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> <52035319.7010901@bwijnen.net> Date: Thu, 8 Aug 2013 09:23:11 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=ISO-8859-1 Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 16:23:16 -0000 Hi, I don't think Martin's suggestion (which I made early in the email debate) solves the problem 100%. Publish 1 RFC with the main module and the 'netconf' container. The main container will include the TLS module and have a normative reference to the NETCONF over TLS RFC Publish NETCONF-over-TLS RFC which has a "belongs-to" main module and a normative reference to the main module RFC. >>> Circular normative references; OK or not? Assuming the normative references are not a problem: In the future: Publish NETCONF-over-FOO RFC which has a "belongs-to" main module and a normative reference to the main module RFC. Publish a new RFC with the main module and the 'netconf' container. The main container will include the TLS and FOO submodules and have a normative reference to the NETCONF over TLS RFC, and NETCONF over FOO RFC. Advantages: * The new RFC(main-module) always obsoletes the previous version * Always clear which RFC has the main module (RFC series tracks it) * The existing submodule RFCs do not get touched or republished when the main module is updated Disadvantages: * Requires extra RFC * Main module reference in NETCONF over TLS RFC may be perceived as out of date; (It is valid for the conformance required when published, so should be OK) IMO, it is no big deal to publish NETCONF-over-tls in 1 module, and then NETCONF-over-FOO will just augment the /netconf container using its own namespace. Then there is no main module + /netconf submodule RFC needed. All this submodule stuff seems like a lot of extra work to save an XML namespace. That is not a very expensive resource. It costs 1 attribute in XML or 1 module prefix in JSON. Andy On Thu, Aug 8, 2013 at 8:57 AM, Ladislav Lhotka wrote: > > On Aug 8, 2013, at 10:13 AM, Bert Wijnen (IETF) wrote: > >> Lada, can I conclude from the below that you agree with the >> approach that Juergen has currently taken? > > In this case, I think it is not realistic to assume that additional submodules will be defined in other documents, because every revision of such a submodule would require an update to the NETCONF-over-TLS document, which would be counterproductive. > > Therefore, 5539bis should IMO simply define the "ietf-netconf-tls" module, essentially with the contents of the current "ietf-netconf-tls" submodule. > > Lada > >> >> Bert >> >> On 8/8/13 10:10 AM, Ladislav Lhotka wrote: >>>>> - who can live with (or agrees with) that updating/obsoleteing the whole >>>>> >> RFC if a submodule changes (9 hands) >>>> > >>>> >The basic question in my view is whether we want one namespace for >>>> >NETCONF configuration objects or multiple namespaces, one for the TLS >>>> >config objects, one for the SSH config objects, one for general >>>> >NETCONF config objects (e.g. idle timeouts etc. that do not exist in >>>> >RFCs yet but it seems they will do them at some point in time since >>>> >implementations commonly have such configuration parameters). >>> IMO, submodules should be reserved for the party that is in control of the main module (that can be an IETF WG). Other parties (including other WGs) should always use another namespace. >>> >>> Lada >>> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Thu Aug 8 09:55: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 3C8DD11E81EC for ; Thu, 8 Aug 2013 09:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSzZYSsbrdFl for ; Thu, 8 Aug 2013 09:55:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6271021F9D2E for ; Thu, 8 Aug 2013 09:55:04 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 825BE13F865; Thu, 8 Aug 2013 18:55:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1375980903; bh=c0+GIGfZhM3v6xBmiiJw3NsH6emFwMvyT62OOhc91KM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=LklQZ52hxeQjH05/6Jp2wQRJwxJIiJgUuiUDgmsZbBUee8hYB9kOI3kv1y+h6nSTG nUGAAeII4G4/bddUATVsXsDy4gXikyIyydKliNv4bPDCBmJ/2fG1fAAOzW3DAGA6CM VxcF/NT9mVqHKux1CDX7kFhFZRbpDQs0q4yVaaPA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 8 Aug 2013 18:55:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91D332A3-E209-4E77-AAC6-2CE9A3C0BED1@nic.cz> References: <20130801112350.GA25489@elstar.local> <20130803.224919.208391324.mbj@tail-f.com> <51FFC547.5090406@ericsson.com> <20130805173820.GA897@elstar.local> <61754E6A-E932-4DC0-B0A7-5EE93DE9EFDD@nic.cz> <52025F52.4060908@bwijnen.net> <20130808075348.GA9139@elstar.local> <45B5D9A0-21FB-4EBF-8E67-7C7C3F815664@nic.cz> <52035319.7010901@bwijnen.net> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 16:55:16 -0000 On Aug 8, 2013, at 6:23 PM, Andy Bierman wrote: > Hi, >=20 > I don't think Martin's suggestion (which I made early in the email = debate) > solves the problem 100%. >=20 > Publish 1 RFC with the main module and the 'netconf' container. > The main container will include the TLS module and have a normative > reference to the NETCONF over TLS RFC A submodule like "ietf-netconf-common" in 5539bis would still be needed, = because submodules cannot augment nodes in the main module. >=20 > Publish NETCONF-over-TLS RFC which has a "belongs-to" main module > and a normative reference to the main module RFC. >=20 >>>> Circular normative references; OK or not? >=20 > Assuming the normative references are not a problem: >=20 > In the future: >=20 > Publish NETCONF-over-FOO RFC which has a "belongs-to" main module > and a normative reference to the main module RFC. But it would also have to include "ietf-netconf-common", which is a = another complication (I think this CLR is unnecessary, and should be = removed in YANG 2.0). Lada >=20 > Publish a new RFC with the main module and the 'netconf' container. > The main container will include the TLS and FOO submodules and > have a normative reference to the NETCONF over TLS RFC, > and NETCONF over FOO RFC. >=20 > Advantages: > * The new RFC(main-module) always obsoletes the previous version > * Always clear which RFC has the main module (RFC series tracks it) > * The existing submodule RFCs do not get touched or republished > when the main module is updated >=20 > Disadvantages: > * Requires extra RFC > * Main module reference in NETCONF over TLS RFC may be perceived > as out of date; (It is valid for the conformance required when = published, > so should be OK) >=20 > IMO, it is no big deal to publish NETCONF-over-tls in 1 module, > and then NETCONF-over-FOO will just augment the /netconf > container using its own namespace. Then there is no main module > + /netconf submodule RFC needed. >=20 > All this submodule stuff seems like a lot of extra work to save an > XML namespace. That is not a very expensive resource. > It costs 1 attribute in XML or 1 module prefix in JSON. >=20 >=20 > Andy >=20 > On Thu, Aug 8, 2013 at 8:57 AM, Ladislav Lhotka wrote: >>=20 >> On Aug 8, 2013, at 10:13 AM, Bert Wijnen (IETF) = wrote: >>=20 >>> Lada, can I conclude from the below that you agree with the >>> approach that Juergen has currently taken? >>=20 >> In this case, I think it is not realistic to assume that additional = submodules will be defined in other documents, because every revision of = such a submodule would require an update to the NETCONF-over-TLS = document, which would be counterproductive. >>=20 >> Therefore, 5539bis should IMO simply define the "ietf-netconf-tls" = module, essentially with the contents of the current "ietf-netconf-tls" = submodule. >>=20 >> Lada >>=20 >>>=20 >>> Bert >>>=20 >>> On 8/8/13 10:10 AM, Ladislav Lhotka wrote: >>>>>> - who can live with (or agrees with) that updating/obsoleteing = the whole >>>>>>>> RFC if a submodule changes (9 hands) >>>>>>=20 >>>>>> The basic question in my view is whether we want one namespace = for >>>>>> NETCONF configuration objects or multiple namespaces, one for the = TLS >>>>>> config objects, one for the SSH config objects, one for general >>>>>> NETCONF config objects (e.g. idle timeouts etc. that do not exist = in >>>>>> RFCs yet but it seems they will do them at some point in time = since >>>>>> implementations commonly have such configuration parameters). >>>> IMO, submodules should be reserved for the party that is in control = of the main module (that can be an IETF WG). Other parties (including = other WGs) should always use another namespace. >>>>=20 >>>> Lada >>>>=20 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 8 10:29:04 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 5514F1F042B for ; Thu, 8 Aug 2013 10:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL9ioyXVLYxk for ; Thu, 8 Aug 2013 10:28:58 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 35BDE11E81F5 for ; Thu, 8 Aug 2013 10:28:48 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 57F851200438; Thu, 8 Aug 2013 19:28:45 +0200 (CEST) Date: Thu, 08 Aug 2013 19:28:44 +0200 (CEST) Message-Id: <20130808.192844.306956556.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <52035319.7010901@bwijnen.net> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Summary of the NETCONF Session at IETF 87 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, 08 Aug 2013 17:29:04 -0000 Andy Bierman wrote: > Hi, > > I don't think Martin's suggestion (which I made early in the email debate) > solves the problem 100%. > > Publish 1 RFC with the main module and the 'netconf' container. > The main container will include the TLS module and have a normative > reference to the NETCONF over TLS RFC > > Publish NETCONF-over-TLS RFC which has a "belongs-to" main module > and a normative reference to the main module RFC. > > >>> Circular normative references; OK or not? Seems to be ok; e.g., 6241 & 6242; 3412 & 3413 (and others). > Assuming the normative references are not a problem: > > In the future: > > Publish NETCONF-over-FOO RFC which has a "belongs-to" main module > and a normative reference to the main module RFC. > > Publish a new RFC with the main module and the 'netconf' container. > The main container will include the TLS and FOO submodules and > have a normative reference to the NETCONF over TLS RFC, > and NETCONF over FOO RFC. > > Advantages: > * The new RFC(main-module) always obsoletes the previous version > * Always clear which RFC has the main module (RFC series tracks it) > * The existing submodule RFCs do not get touched or republished > when the main module is updated > > Disadvantages: > * Requires extra RFC > * Main module reference in NETCONF over TLS RFC may be perceived > as out of date; (It is valid for the conformance required when published, > so should be OK) Another solution that I suggested, that does not have these disadvantages, is to let IANA maintain the main module. An advantage of the submodule approach is that it is easier to find all data models related to a technology - if you find ietf-netconf you'll see all submodules included. > IMO, it is no big deal to publish NETCONF-over-tls in 1 module, > and then NETCONF-over-FOO will just augment the /netconf > container using its own namespace. Then there is no main module > + /netconf submodule RFC needed. > > All this submodule stuff seems like a lot of extra work to save an > XML namespace. That is not a very expensive resource. > It costs 1 attribute in XML or 1 module prefix in JSON. I don't think there's any extra work. It is not just one extra attribute or module prefix; it is going to be one extra per module (subtree). It is certainly doable, but probably easier and less error prone if we can avoid it. /martin From ietf-ipr@ietf.org Fri Aug 9 15:15:25 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 B016211E8135; Fri, 9 Aug 2013 15:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qg5cx-RGfqJz; Fri, 9 Aug 2013 15:15:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2651621F9C4C; Fri, 9 Aug 2013 15:09:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: kwatsen@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130809220926.2759.62641.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2013 15:09:26 -0700 Cc: joelja@bogus.com, netconf@ietf.org, ipr-announce@ietf.org Subject: [Netconf] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-netconf-reverse-ssh-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, 09 Aug 2013 22:15:25 -0000 Dear Kent Watsen: An IPR disclosure that pertains to your Internet-Draft entitled "Reverse S= ecure Shell (Reverse SSH)" (draft-ietf-netconf-reverse-ssh) was submitted to the = IETF Secretariat on 2013-08-09 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2170/). The = title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf- netconf-reverse-ssh-01.""); The IETF Secretariat From mehmet.ersue@nsn.com Mon Aug 12 04:26: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 2CC9E11E81C8 for ; Mon, 12 Aug 2013 04:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8GQwixz8TtD for ; Mon, 12 Aug 2013 04:25:54 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 042DF21E8181 for ; Mon, 12 Aug 2013 03:30:19 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r7CAUE9O000785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Aug 2013 12:30:14 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r7CAUEwQ028964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 12 Aug 2013 12:30:14 +0200 Received: from DEMUHTC017.nsn-intra.net (10.159.42.48) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 12 Aug 2013 12:30:13 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.59]) by DEMUHTC017.nsn-intra.net ([10.159.42.48]) with mapi id 14.03.0123.003; Mon, 12 Aug 2013 12:30:13 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Netconf Thread-Topic: Draft Minutes for the IETF 87 NETCONF Session Thread-Index: Ac6XRu0n33Jun/0kRi6ntnAa2awFZA== Date: Mon, 12 Aug 2013 10:30:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F816E0F5DEMUMBX005nsnintr_" 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: 1983 X-purgate-ID: 151667::1376303414-0000471E-F2ABAC94/0-0/0-0 Subject: [Netconf] Draft Minutes for the IETF 87 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: Mon, 12 Aug 2013 11:26:16 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F816E0F5DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below are the draft minutes of the NETCONF session in IETF 87. Pls send your comments to the co-chairs by August 20, 2013. http://www.ietf.org/proceedings/87/minutes/minutes-87-netconf Many thanks to the minute takers Lada Lhotka, Robert Varga and the Jabber scribe Peter Saint-Andre. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F816E0F5DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
below are the draft minutes of the NETCONF session in IETF 87.
Pls send your comments to the co-chairs by August 20, 2013.
 
 
Many thanks to the minute takers Lada Lhotka, Robert Varga and
the Jabber scribe Peter Saint-Andre.
 
Cheers,
Mehmet
 
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F816E0F5DEMUMBX005nsnintr_-- From jonathan@hansfords.net Mon Aug 12 04:34:52 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 45DD521E80D5 for ; Mon, 12 Aug 2013 04:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDwgMhhSHmFA for ; Mon, 12 Aug 2013 04:34:35 -0700 (PDT) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id E51FF21F9B80 for ; Mon, 12 Aug 2013 03:48:31 -0700 (PDT) Received: from webmail.plus.net ([84.93.237.98]) by avasout04 with smtp id BmoU1m004283uBY01moVK4; Mon, 12 Aug 2013 11:48:29 +0100 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=bL0vfpOZ c=1 sm=1 tr=0 a=BJaFPv9AyABFDM2hXLRoEA==:117 a=MEK23cO9Z3nTrtfM1ievvA==:17 a=0Bzu9jTXAAAA:8 a=lxldWUwtbAkA:10 a=dYCPD3cKDi0A:10 a=gBh6aikjKukA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=f0uUZFObAAAA:8 a=LcRfbuCf9oUA:10 a=bsKsz6ItMThXSxxYdq0A:9 a=W6QAX6X4fAvP6MQ_:21 a=KAqKj1B8V6xnlYXa:21 a=QEXdDO2ut3YA:10 a=zeshHG33Dl4A:10 a=e95npEc2_1at9vpRyFoA:9 a=uKMBXKvPJ5Rw-Udm:21 a=pGQUefWJJHJ8cYCR:21 a=AddRqUBrY4tG_efK:21 a=_W_S_7VecoQA:10 X-AUTH: hansfords+us:2500 Received: from host-212-159-134-100.static.as13285.net ([212.159.134.100]) by webmail.plus.net with HTTP (HTTP/1.1 POST); Mon, 12 Aug 2013 11:48:28 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_2dab753c4a66e414c6b69ade99206dd6" Date: Mon, 12 Aug 2013 11:48:28 +0100 From: Jonathan Hansford To: Andy Bierman In-Reply-To: References: <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local> Message-ID: <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net> X-Sender: Jonathan@hansfords.net User-Agent: Roundcube Webmail/0.7.4 X-Originating-IP: [212.159.134.100] Cc: netconf@ietf.org Subject: Re: [Netconf] The configuration datastore and :writable-running 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, 12 Aug 2013 11:34:57 -0000 --=_2dab753c4a66e414c6b69ade99206dd6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Andy, You propose that ":candidate and :writable-running together should be considered deprecated", yet RFC 6241 (pp.70-71) states: ... it is important to recognize that some operations are clearly more sensitive by nature than others. For instance, to the startup or running configurations is clearly not a normal provisioning operation, whereas is. Such global operations MUST disallow the changing of information that an individual does not have authorization to perform. For example, if user A is not allowed to configure an IP address on an interface but user B has configured an IP address on an interface in the configuration, user A MUST NOT be allowed to commit the configuration. Presumably, if :candidate is supported, the approach would be to: * and * to * within the limits of the user's privileges * (or use set to in the previous set, if the change is trivial) * to * and But if the change were a simple change, wouldn't it be better to with the set to , even if :candidate is supported? Or are you just proposing that concurrent use of the :candidate and :writable-running capabilities on should be deprecated? And if that is the case, wouldn't the use of be sufficient? Jonathan On 2013-08-08 16:37, Andy Bierman wrote: > On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder > wrote: > >> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote: >> >>> I don't recall seeing it stated anywhere in RFC 6241 that the running datastore defaults to read-only. Would it be worth raising an erratum to clarify that point? >> Implementing NETCONF read-only has obviously little value for real configuration management. > > Yes, but base:1.1 does not actually require any editing capabilities. > What if a company wanted to use NETCONF for monitoring and/or > notifications? Then the base:1.1 operation set is simple to implement, > and they do not advertise any optional capabilities, so the client > should figure out what operations are allowed. > >> The reason why we have :writable-running and :candidate is that some major vendors use very different models when it comes to making configuration changes and as such you will see implementations that either announce :writable-running or :candidate or :writable-running and :candidate together. > > :candidate and :writable-running together should be considered deprecated. > This is a degenerate use-case for concurrent transactions. The WG should > standardize this properly at some point in the future, so clients can use > a predictable standard transaction model. > /js > > Andy > >> --=_2dab753c4a66e414c6b69ade99206dd6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Andy,

You propose that ":candidate and :writable-running together should be co= nsidered deprecated", yet RFC 6241 (pp.70-71) states:

... it is important to recognize that so=
me operations are clearly more sensitive by nature than others.  For instan=
ce, <copy-config> to the startup or running configurations is clearly=
 not a normal provisioning operation, whereas <edit-config> is.  Such=
 global operations MUST disallow the changing of information that an indivi=
dual does not have authorization to perform.  For example, if user A is not=
 allowed to configure an IP address on an interface but user B has configur=
ed an IP address on an interface in the <candidate> configuration, us=
er A MUST NOT be allowed to commit the <candidate> configuration.

Presumably, if :candidate is supported, the approach would be to:


    

  • <lock> <candidate> and <running>
    • 

  • <copy-config> <running> to <candidate>
    • 

  • <edit-config> <candidate> within the limits of the user's p=
rivileges
    • 

  • <validate> <candidate> (or use <test-option> set to &=
lt;test-then-set> in the previous set, if the change is trivial)
    • 

  • <copy-config> <candidate> to <running>
    • 

  • <unlock> <candidate> and <running>
    • 



But if the change were a simple change, wouldn't it be better to <edi=
t-config> <running> with the <test-option> set to <test-t=
hen-set>, even if :candidate is supported? Or are you just proposing tha=
t concurrent use of the :candidate and :writable-running capabilities on &l=
t;running> should be deprecated? And if that is the case, wouldn't the u=
se of <lock> be sufficient?


Jonathan


On 2013-08-08 16:37, Andy Bierman wrote:




On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
<j.schoenwaelder=
@jacobs-university.de> wrote:


On Thu, Aug 08, 2013 at 04:06:55PM +0=
100, Jonathan Hansford wrote:

I don't recall seeing it stated anywh=
ere in RFC 6241 that the running datastore defaults to read-only. Would it =
be worth raising an erratum to clarify that point?

Implementing NETCONF read-only has obviously little value for real configur=
ation management.


Yes, but base:1.1 does not actually require any editing capabilities=
=2E
What if a company wanted to use NETCONF for monitoring and/or
notifications?  Then the base:1.1 operation set is simple to implement,
and they do not advertise any optional capabilities, so the client
should figure out what operations are allowed.


The reason why we have :writable-runn=
ing and :candidate is that some major vendors use very different models whe=
n it comes to making configuration changes and as such you will see impleme=
ntations that either announce :writable-running or :candidate or :writable-=
running and :candidate together.


:candidate and :writable-running together should be considered depreca=
ted.
This is a degenerate use-case for concurrent transactions.  The WG should
standardize this properly at some point in the future, so clients can use
a predictable standard transaction model.


/js


Andy






--=_2dab753c4a66e414c6b69ade99206dd6--


From andy@yumaworks.com  Mon Aug 12 08:51:52 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 201F521E8125 for ; Mon, 12 Aug 2013 08:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.057
X-Spam-Level: 
X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtKC-9rw5jB3 for ; Mon, 12 Aug 2013 08:51:46 -0700 (PDT)
Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3121E8169 for ; Mon, 12 Aug 2013 07:54:17 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id q10so3519810pdj.34 for ; Mon, 12 Aug 2013 07:54:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mYMJVtIMXoJl3R4UubLqC5bCODp1B4+ph8udI4Wb5wQ=; b=XEPvww1NDkYq/3BCt98+ZINb81aYVckspYJoJkR6nV+e9vy7/bWcWyTebcSqlgykVr Rwk15to1rAD3CsBvTPxhAIcw5UDpwtz/5NZTmLLkmUXyc77gZCnIcPVVhRw2+PFtPn7p rzVniRhTholKlKcyprjU4nz4u1V0rNly5KYQG0AwWW5MN2c0092i1DwJYdkzuj3IcW/M yVaIJ2x7Zs/ggBIOsrrMtIlKOo/vv7u70fLEUvPgtZslHyOZfFQ+mJI0hYFw/0wVAMRV zN8de8Gw/JPr1y+1DsS2LRAnDDS1ocwoMItz1YHcc7BJ9kA1opkvegmRBr3SM/thRkCO 98Gw==
X-Gm-Message-State: ALoCoQmOD31fD0Q3uOoFFUkrcptNm/9K1C6xOsoP9EaF/b68J30q9ia69QcTSt69dX+uKxzAmTTN
MIME-Version: 1.0
X-Received: by 10.68.131.133 with SMTP id om5mr24914426pbb.148.1376319257571;  Mon, 12 Aug 2013 07:54:17 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 07:54:17 -0700 (PDT)
In-Reply-To: <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>
Date: Mon, 12 Aug 2013 07:54:17 -0700
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: text/plain; charset=ISO-8859-1
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 15:51:52 -0000

Hi,

The operations below are wrong.
 (candidate, running) is  instead
 (running, candidate) is  instead

The problems occur when running is edited separately from candidate.
I'm not going to spell it out.  Those who have implemented concurrent
transactions understand the issues.

Andy


On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
 wrote:
> Andy,
>
> You propose that ":candidate and :writable-running together should be
> considered deprecated", yet RFC 6241 (pp.70-71) states:
>
> ... it is important to recognize that some operations are clearly more
> sensitive by nature than others.  For instance,  to the startup
> or running configurations is clearly not a normal provisioning operation,
> whereas  is.  Such global operations MUST disallow the changing
> of information that an individual does not have authorization to perform.
> For example, if user A is not allowed to configure an IP address on an
> interface but user B has configured an IP address on an interface in the
>  configuration, user A MUST NOT be allowed to commit the
>  configuration.
>
> Presumably, if :candidate is supported, the approach would be to:
>
>   and 
>   to 
>   within the limits of the user's privileges
>   (or use  set to  in the
> previous set, if the change is trivial)
>   to 
>   and 
>
> But if the change were a simple change, wouldn't it be better to
>   with the  set to , even
> if :candidate is supported? Or are you just proposing that concurrent use of
> the :candidate and :writable-running capabilities on  should be
> deprecated? And if that is the case, wouldn't the use of  be
> sufficient?
>
> Jonathan
>
> On 2013-08-08 16:37, Andy Bierman wrote:
>
> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>  wrote:
>
> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>
> I don't recall seeing it stated anywhere in RFC 6241 that the running
> datastore defaults to read-only. Would it be worth raising an erratum to
> clarify that point?
>
> Implementing NETCONF read-only has obviously little value for real
> configuration management.
>
> Yes, but base:1.1 does not actually require any editing capabilities.
> What if a company wanted to use NETCONF for monitoring and/or
> notifications?  Then the base:1.1 operation set is simple to implement,
> and they do not advertise any optional capabilities, so the client
> should figure out what operations are allowed.
>
> The reason why we have :writable-running and :candidate is that some major
> vendors use very different models when it comes to making configuration
> changes and as such you will see implementations that either announce
> :writable-running or :candidate or :writable-running and :candidate
> together.
>
> :candidate and :writable-running together should be considered deprecated.
> This is a degenerate use-case for concurrent transactions.  The WG should
> standardize this properly at some point in the future, so clients can use
> a predictable standard transaction model.
>
> /js
>
> Andy

From jonathan@hansfords.net  Mon Aug 12 08:56:04 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 7676521E8151 for ; Mon, 12 Aug 2013 08:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKz1pvfvcJfh for ; Mon, 12 Aug 2013 08:55:58 -0700 (PDT)
Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5220221E8195 for ; Mon, 12 Aug 2013 07:59:26 -0700 (PDT)
Received: from [127.0.0.1] ([84.92.149.4]) by avasout01 with smtp id BqzM1m00605w0Nk01qzNe9; Mon, 12 Aug 2013 15:59:23 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=ZMDuxxLb c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=yCgouOt5RcIA:10 a=fsXQbgwv7fIA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=LcRfbuCf9oUA:10 a=yrKqXqSrJzi9xhPY5RwA:9 a=t-gUHU9sciA68i9N:21 a=vBtvLujjnJuMj2fg:21 a=wPNLvfGTeEIA:10 a=1rgnPY4EEFsA:10 a=zeshHG33Dl4A:10
Message-ID: <5208F848.6000608@hansfords.net>
Date: Mon, 12 Aug 2013 15:59:20 +0100
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andy Bierman 
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130812-0, 12/08/2013), Outbound message
X-Antivirus-Status: Clean
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 15:56:04 -0000

Hi,

Thanks for the corrections. So you're saying that if you use :candidate 
on a device you should not also use :writable-running.

Jonathan

On 12/08/2013 15:54, Andy Bierman wrote:
> Hi,
>
> The operations below are wrong.
>  (candidate, running) is  instead
>  (running, candidate) is  instead
>
> The problems occur when running is edited separately from candidate.
> I'm not going to spell it out.  Those who have implemented concurrent
> transactions understand the issues.
>
> Andy
>
>
> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>  wrote:
>> Andy,
>>
>> You propose that ":candidate and :writable-running together should be
>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>
>> ... it is important to recognize that some operations are clearly more
>> sensitive by nature than others.  For instance,  to the startup
>> or running configurations is clearly not a normal provisioning operation,
>> whereas  is.  Such global operations MUST disallow the changing
>> of information that an individual does not have authorization to perform.
>> For example, if user A is not allowed to configure an IP address on an
>> interface but user B has configured an IP address on an interface in the
>>  configuration, user A MUST NOT be allowed to commit the
>>  configuration.
>>
>> Presumably, if :candidate is supported, the approach would be to:
>>
>>   and 
>>   to 
>>   within the limits of the user's privileges
>>   (or use  set to  in the
>> previous set, if the change is trivial)
>>   to 
>>   and 
>>
>> But if the change were a simple change, wouldn't it be better to
>>   with the  set to , even
>> if :candidate is supported? Or are you just proposing that concurrent use of
>> the :candidate and :writable-running capabilities on  should be
>> deprecated? And if that is the case, wouldn't the use of  be
>> sufficient?
>>
>> Jonathan
>>
>> On 2013-08-08 16:37, Andy Bierman wrote:
>>
>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>  wrote:
>>
>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>
>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>> datastore defaults to read-only. Would it be worth raising an erratum to
>> clarify that point?
>>
>> Implementing NETCONF read-only has obviously little value for real
>> configuration management.
>>
>> Yes, but base:1.1 does not actually require any editing capabilities.
>> What if a company wanted to use NETCONF for monitoring and/or
>> notifications?  Then the base:1.1 operation set is simple to implement,
>> and they do not advertise any optional capabilities, so the client
>> should figure out what operations are allowed.
>>
>> The reason why we have :writable-running and :candidate is that some major
>> vendors use very different models when it comes to making configuration
>> changes and as such you will see implementations that either announce
>> :writable-running or :candidate or :writable-running and :candidate
>> together.
>>
>> :candidate and :writable-running together should be considered deprecated.
>> This is a degenerate use-case for concurrent transactions.  The WG should
>> standardize this properly at some point in the future, so clients can use
>> a predictable standard transaction model.
>>
>> /js
>>
>> Andy


From andy@yumaworks.com  Mon Aug 12 09:00:01 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 49E0D21E81BD for ; Mon, 12 Aug 2013 09:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.056
X-Spam-Level: 
X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zo4hGUwVuuF0 for ; Mon, 12 Aug 2013 08:59:56 -0700 (PDT)
Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F321F9CF3 for ; Mon, 12 Aug 2013 08:13:11 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id q10so3533253pdj.35 for ; Mon, 12 Aug 2013 08:13:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HE7QYfvaUBvS8ICoX6Ym3TiTr0GuQtlrV0zham1m/QQ=; b=cUtaDLjmBzntE7ligTeERHYezxGHt25QJyWAW5+YOu4rNzfASFG+/ENw6eft2B/e5e Y8ozuYMAZl8ZqwAWznfQ6Dkymqil9JOpBEHTLj0oRQwkB/DfPAxCNtsYJA8W+y4Y1xZw RFqlKbpTAzyhIRs/+Q4WsMnsEEJ2jIPRtHg+Q/OyuWYfnmv4txklIbw2I7pShCDU7PFw OrphGu8yOXagqXLeKb2HZBrXIedGYCLK1MYN4RBq4SFeCHFOYv7ApkrA0wJQykoHdsev nYvutwA+bD6lEnz6a2fTQ7DDqRIn3cgDHlBgCbF95IQT2K1h4jhDWyYNPAfTM3yqsmmy yXeA==
X-Gm-Message-State: ALoCoQkzIKTU7TU/b+0P/2oCsxHYz4p6I7t5iTC1XjCiuJsODqY0IAaCuVsWFG9c4p0nKKfl7nqy
MIME-Version: 1.0
X-Received: by 10.68.197.36 with SMTP id ir4mr12292109pbc.96.1376320389565; Mon, 12 Aug 2013 08:13:09 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 08:13:09 -0700 (PDT)
In-Reply-To: <5208F848.6000608@hansfords.net>
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net>
Date: Mon, 12 Aug 2013 08:13:09 -0700
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: text/plain; charset=ISO-8859-1
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 16:00:01 -0000

Hi,

You can lock everything and still NETCONF does not handle it correctly:

start with /a = 5 in both candidate and running
lock(candidate)
lock(running)
edit-config(candidate, /a = 10)
edit-config(running, /b = 3)
commit
unlock(running)
unlock(candidate)

The commit deletes /b and sets /a back to its original value (5).
Editing running and also candidate does not work well in NETCONF.
NETCONF only works well if one target datastore is used.


Andy



On Mon, Aug 12, 2013 at 7:59 AM, Jonathan Hansford
 wrote:
> Hi,
>
> Thanks for the corrections. So you're saying that if you use :candidate on a
> device you should not also use :writable-running.
>
> Jonathan
>
> On 12/08/2013 15:54, Andy Bierman wrote:
>>
>> Hi,
>>
>> The operations below are wrong.
>>  (candidate, running) is  instead
>>  (running, candidate) is  instead
>>
>> The problems occur when running is edited separately from candidate.
>> I'm not going to spell it out.  Those who have implemented concurrent
>> transactions understand the issues.
>>
>> Andy
>>
>>
>> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>>  wrote:
>>>
>>> Andy,
>>>
>>> You propose that ":candidate and :writable-running together should be
>>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>>
>>> ... it is important to recognize that some operations are clearly more
>>> sensitive by nature than others.  For instance,  to the
>>> startup
>>> or running configurations is clearly not a normal provisioning operation,
>>> whereas  is.  Such global operations MUST disallow the
>>> changing
>>> of information that an individual does not have authorization to perform.
>>> For example, if user A is not allowed to configure an IP address on an
>>> interface but user B has configured an IP address on an interface in the
>>>  configuration, user A MUST NOT be allowed to commit the
>>>  configuration.
>>>
>>> Presumably, if :candidate is supported, the approach would be to:
>>>
>>>   and 
>>>   to 
>>>   within the limits of the user's privileges
>>>   (or use  set to  in
>>> the
>>> previous set, if the change is trivial)
>>>   to 
>>>   and 
>>>
>>> But if the change were a simple change, wouldn't it be better to
>>>   with the  set to ,
>>> even
>>> if :candidate is supported? Or are you just proposing that concurrent use
>>> of
>>> the :candidate and :writable-running capabilities on  should be
>>> deprecated? And if that is the case, wouldn't the use of  be
>>> sufficient?
>>>
>>> Jonathan
>>>
>>> On 2013-08-08 16:37, Andy Bierman wrote:
>>>
>>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>>  wrote:
>>>
>>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>>
>>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>>> datastore defaults to read-only. Would it be worth raising an erratum to
>>> clarify that point?
>>>
>>> Implementing NETCONF read-only has obviously little value for real
>>> configuration management.
>>>
>>> Yes, but base:1.1 does not actually require any editing capabilities.
>>> What if a company wanted to use NETCONF for monitoring and/or
>>> notifications?  Then the base:1.1 operation set is simple to implement,
>>> and they do not advertise any optional capabilities, so the client
>>> should figure out what operations are allowed.
>>>
>>> The reason why we have :writable-running and :candidate is that some
>>> major
>>> vendors use very different models when it comes to making configuration
>>> changes and as such you will see implementations that either announce
>>> :writable-running or :candidate or :writable-running and :candidate
>>> together.
>>>
>>> :candidate and :writable-running together should be considered
>>> deprecated.
>>> This is a degenerate use-case for concurrent transactions.  The WG should
>>> standardize this properly at some point in the future, so clients can use
>>> a predictable standard transaction model.
>>>
>>> /js
>>>
>>> Andy
>
>

From andy@yumaworks.com  Mon Aug 12 09:00: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 A735621E81D1 for ; Mon, 12 Aug 2013 09:00:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.054
X-Spam-Level: 
X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SQfLrrOgSRx for ; Mon, 12 Aug 2013 09:00:08 -0700 (PDT)
Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 687BB21E81FF for ; Mon, 12 Aug 2013 08:14:43 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id y13so3570908pdi.33 for ; Mon, 12 Aug 2013 08:14:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=a1AqVn54pczte/vFcXjQ5/oDXLn8b/lXZFmwhPxTFfY=; b=iDfqpRZozWucpY1PsYSf7JmDBOtLVGPzrw0b+UbdLpJo54P0B0QA52sflkKGQ5jNvA 6QDtGeH79zfsg3jKLP+gwB9ltBa1RXFlerps6bqPtBYdHi1ggVtXLYpEg8F/A/zfDSUH DG1KHZ0A093q/WIQx21JQ08Chq04r8L3zoHZ6L89mw7qxvE03N35ajTB6tUqHkCgyaoT EhGQ2RipwozA3znSkZmjV8kWJgAUpS3VGMOccown/8qy71QjFONO++VV9FQEjc5El8Sg RzVWOgN6m5yNrYZq/4nb7g3jOYTic2V4YnM+FX7xYdutwJ8VHyymyFzGq+ctW86FFu7u PLdw==
X-Gm-Message-State: ALoCoQmw/tbzHAwNlDuKZ/Nkc+e63plcgLlGOcbd0TLrbhVUN0X5ZO5GDrcWx3FBiMoE37YBgyXv
MIME-Version: 1.0
X-Received: by 10.68.19.162 with SMTP id g2mr24928062pbe.140.1376320483152; Mon, 12 Aug 2013 08:14:43 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 08:14:43 -0700 (PDT)
In-Reply-To: 
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net> 
Date: Mon, 12 Aug 2013 08:14:43 -0700
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: text/plain; charset=ISO-8859-1
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 16:00:14 -0000

On Mon, Aug 12, 2013 at 8:13 AM, Andy Bierman  wrote:
> Hi,
>
> You can lock everything and still NETCONF does not handle it correctly:
>
> start with /a = 5 in both candidate and running
> lock(candidate)
> lock(running)
> edit-config(candidate, /a = 10)
                   ^^^^^^^^^ should be running
> edit-config(running, /b = 3)
> commit
> unlock(running)
> unlock(candidate)
>
> The commit deletes /b and sets /a back to its original value (5).
> Editing running and also candidate does not work well in NETCONF.
> NETCONF only works well if one target datastore is used.
>
>
> Andy
>
>
>
> On Mon, Aug 12, 2013 at 7:59 AM, Jonathan Hansford
>  wrote:
>> Hi,
>>
>> Thanks for the corrections. So you're saying that if you use :candidate on a
>> device you should not also use :writable-running.
>>
>> Jonathan
>>
>> On 12/08/2013 15:54, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> The operations below are wrong.
>>>  (candidate, running) is  instead
>>>  (running, candidate) is  instead
>>>
>>> The problems occur when running is edited separately from candidate.
>>> I'm not going to spell it out.  Those who have implemented concurrent
>>> transactions understand the issues.
>>>
>>> Andy
>>>
>>>
>>> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>>>  wrote:
>>>>
>>>> Andy,
>>>>
>>>> You propose that ":candidate and :writable-running together should be
>>>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>>>
>>>> ... it is important to recognize that some operations are clearly more
>>>> sensitive by nature than others.  For instance,  to the
>>>> startup
>>>> or running configurations is clearly not a normal provisioning operation,
>>>> whereas  is.  Such global operations MUST disallow the
>>>> changing
>>>> of information that an individual does not have authorization to perform.
>>>> For example, if user A is not allowed to configure an IP address on an
>>>> interface but user B has configured an IP address on an interface in the
>>>>  configuration, user A MUST NOT be allowed to commit the
>>>>  configuration.
>>>>
>>>> Presumably, if :candidate is supported, the approach would be to:
>>>>
>>>>   and 
>>>>   to 
>>>>   within the limits of the user's privileges
>>>>   (or use  set to  in
>>>> the
>>>> previous set, if the change is trivial)
>>>>   to 
>>>>   and 
>>>>
>>>> But if the change were a simple change, wouldn't it be better to
>>>>   with the  set to ,
>>>> even
>>>> if :candidate is supported? Or are you just proposing that concurrent use
>>>> of
>>>> the :candidate and :writable-running capabilities on  should be
>>>> deprecated? And if that is the case, wouldn't the use of  be
>>>> sufficient?
>>>>
>>>> Jonathan
>>>>
>>>> On 2013-08-08 16:37, Andy Bierman wrote:
>>>>
>>>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>>>  wrote:
>>>>
>>>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>>>
>>>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>>>> datastore defaults to read-only. Would it be worth raising an erratum to
>>>> clarify that point?
>>>>
>>>> Implementing NETCONF read-only has obviously little value for real
>>>> configuration management.
>>>>
>>>> Yes, but base:1.1 does not actually require any editing capabilities.
>>>> What if a company wanted to use NETCONF for monitoring and/or
>>>> notifications?  Then the base:1.1 operation set is simple to implement,
>>>> and they do not advertise any optional capabilities, so the client
>>>> should figure out what operations are allowed.
>>>>
>>>> The reason why we have :writable-running and :candidate is that some
>>>> major
>>>> vendors use very different models when it comes to making configuration
>>>> changes and as such you will see implementations that either announce
>>>> :writable-running or :candidate or :writable-running and :candidate
>>>> together.
>>>>
>>>> :candidate and :writable-running together should be considered
>>>> deprecated.
>>>> This is a degenerate use-case for concurrent transactions.  The WG should
>>>> standardize this properly at some point in the future, so clients can use
>>>> a predictable standard transaction model.
>>>>
>>>> /js
>>>>
>>>> Andy
>>
>>

From jonathan@hansfords.net  Mon Aug 12 09:04: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 40EA621F87B7 for ; Mon, 12 Aug 2013 09:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ANYsZEjJkKL for ; Mon, 12 Aug 2013 09:03:55 -0700 (PDT)
Received: from avasout01.plus.net (avasout01.plus.net [84.93.230.227]) by ietfa.amsl.com (Postfix) with ESMTP id 91E6C11E8187 for ; Mon, 12 Aug 2013 08:19:02 -0700 (PDT)
Received: from [127.0.0.1] ([84.92.149.4]) by avasout01 with smtp id BrK01m00505w0Nk01rK10k; Mon, 12 Aug 2013 16:19:01 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=ZMDuxxLb c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=yCgouOt5RcIA:10 a=fsXQbgwv7fIA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=LcRfbuCf9oUA:10 a=9IFTwVx7Ov4fA98qV-EA:9 a=s5PFaAplSGPMsLlK:21 a=-Z4TsT4Cvc2csvP2:21 a=wPNLvfGTeEIA:10 a=1rgnPY4EEFsA:10 a=zeshHG33Dl4A:10
Message-ID: <5208FCE3.5090101@hansfords.net>
Date: Mon, 12 Aug 2013 16:18:59 +0100
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andy Bierman 
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130812-0, 12/08/2013), Outbound message
X-Antivirus-Status: Clean
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 16:04:14 -0000

Thanks for that clarification. One other question: RFC 6241 implies the 
startup configuration is generated from running using copy-config. Is 
there any reason why the source couldn't be candidate?

On 12/08/2013 16:13, Andy Bierman wrote:
> Hi,
>
> You can lock everything and still NETCONF does not handle it correctly:
>
> start with /a = 5 in both candidate and running
> lock(candidate)
> lock(running)
> edit-config(candidate, /a = 10)
> edit-config(running, /b = 3)
> commit
> unlock(running)
> unlock(candidate)
>
> The commit deletes /b and sets /a back to its original value (5).
> Editing running and also candidate does not work well in NETCONF.
> NETCONF only works well if one target datastore is used.
>
>
> Andy
>
>
>
> On Mon, Aug 12, 2013 at 7:59 AM, Jonathan Hansford
>  wrote:
>> Hi,
>>
>> Thanks for the corrections. So you're saying that if you use :candidate on a
>> device you should not also use :writable-running.
>>
>> Jonathan
>>
>> On 12/08/2013 15:54, Andy Bierman wrote:
>>> Hi,
>>>
>>> The operations below are wrong.
>>>  (candidate, running) is  instead
>>>  (running, candidate) is  instead
>>>
>>> The problems occur when running is edited separately from candidate.
>>> I'm not going to spell it out.  Those who have implemented concurrent
>>> transactions understand the issues.
>>>
>>> Andy
>>>
>>>
>>> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>>>  wrote:
>>>> Andy,
>>>>
>>>> You propose that ":candidate and :writable-running together should be
>>>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>>>
>>>> ... it is important to recognize that some operations are clearly more
>>>> sensitive by nature than others.  For instance,  to the
>>>> startup
>>>> or running configurations is clearly not a normal provisioning operation,
>>>> whereas  is.  Such global operations MUST disallow the
>>>> changing
>>>> of information that an individual does not have authorization to perform.
>>>> For example, if user A is not allowed to configure an IP address on an
>>>> interface but user B has configured an IP address on an interface in the
>>>>  configuration, user A MUST NOT be allowed to commit the
>>>>  configuration.
>>>>
>>>> Presumably, if :candidate is supported, the approach would be to:
>>>>
>>>>   and 
>>>>   to 
>>>>   within the limits of the user's privileges
>>>>   (or use  set to  in
>>>> the
>>>> previous set, if the change is trivial)
>>>>   to 
>>>>   and 
>>>>
>>>> But if the change were a simple change, wouldn't it be better to
>>>>   with the  set to ,
>>>> even
>>>> if :candidate is supported? Or are you just proposing that concurrent use
>>>> of
>>>> the :candidate and :writable-running capabilities on  should be
>>>> deprecated? And if that is the case, wouldn't the use of  be
>>>> sufficient?
>>>>
>>>> Jonathan
>>>>
>>>> On 2013-08-08 16:37, Andy Bierman wrote:
>>>>
>>>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>>>  wrote:
>>>>
>>>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>>>
>>>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>>>> datastore defaults to read-only. Would it be worth raising an erratum to
>>>> clarify that point?
>>>>
>>>> Implementing NETCONF read-only has obviously little value for real
>>>> configuration management.
>>>>
>>>> Yes, but base:1.1 does not actually require any editing capabilities.
>>>> What if a company wanted to use NETCONF for monitoring and/or
>>>> notifications?  Then the base:1.1 operation set is simple to implement,
>>>> and they do not advertise any optional capabilities, so the client
>>>> should figure out what operations are allowed.
>>>>
>>>> The reason why we have :writable-running and :candidate is that some
>>>> major
>>>> vendors use very different models when it comes to making configuration
>>>> changes and as such you will see implementations that either announce
>>>> :writable-running or :candidate or :writable-running and :candidate
>>>> together.
>>>>
>>>> :candidate and :writable-running together should be considered
>>>> deprecated.
>>>> This is a degenerate use-case for concurrent transactions.  The WG should
>>>> standardize this properly at some point in the future, so clients can use
>>>> a predictable standard transaction model.
>>>>
>>>> /js
>>>>
>>>> Andy
>>


From andy@yumaworks.com  Mon Aug 12 09:24:03 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 CED6521F9ADF for ; Mon, 12 Aug 2013 09:24:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.053
X-Spam-Level: 
X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veHCW2oB4xRF for ; Mon, 12 Aug 2013 09:23:46 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id BD91921F9A1C for ; Mon, 12 Aug 2013 08:41:08 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id p10so3568176pdj.18 for ; Mon, 12 Aug 2013 08:41:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jRUCnw1Sf0ncpHzcY56gCywYQ7pPyyBFjujyxA3h0XY=; b=TWDvdGloknzGc4FTJPU+hfMh6Pbcga7+gXFAQQSttphL31hON7D66xpU3Eafz4ihvW WI7CM/t+kPYD+rgQZrtX799BLJqNU3tCee96YWUggirYtAKWVlBfk+d4XUKOri5U3pbl Bb/0Sf8i+xCQGGQdjm4VLA07kXrYGELTU5keXXYCDGnVwLteF4ps5h5n9SsfBhwU/yRr 6Kp71/4iLbj6ICWbJ0gpSc3z+do55yNtw3j59/0h4v/yktp8tophEokA7Vz9HildKsQX 30mqETQ0usiIxZ+ZsV/2hM+9iMTqtyuvmdJG6j8/0vU9uJ6d1gh2pdkys1PUJyeSr8BC 8D0Q==
X-Gm-Message-State: ALoCoQlPCHOyaBV5cX2hgPyupCe5qoDw56HhhPLAX55oaObdlsdJiyBHpaU7RJHZyu/2Wa22ClwC
MIME-Version: 1.0
X-Received: by 10.68.197.36 with SMTP id ir4mr12426738pbc.96.1376322067408; Mon, 12 Aug 2013 08:41:07 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 08:41:07 -0700 (PDT)
In-Reply-To: <5208FCE3.5090101@hansfords.net>
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net>  <5208FCE3.5090101@hansfords.net>
Date: Mon, 12 Aug 2013 08:41:07 -0700
Message-ID: 
From: Andy Bierman 
To: Jonathan Hansford 
Content-Type: text/plain; charset=ISO-8859-1
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 16:24:03 -0000

On Mon, Aug 12, 2013 at 8:18 AM, Jonathan Hansford
 wrote:
> Thanks for that clarification. One other question: RFC 6241 implies the
> startup configuration is generated from running using copy-config. Is there
> any reason why the source couldn't be candidate?
>

We actually support most of the optional variants of copy-config,
so candidate <--> startup is allowed.

  copy-config(startup, candidate)
  commit

This is the only way to rollback to the startup config if :candidate
and :startup are both used.


Andy



> On 12/08/2013 16:13, Andy Bierman wrote:
>>
>> Hi,
>>
>> You can lock everything and still NETCONF does not handle it correctly:
>>
>> start with /a = 5 in both candidate and running
>> lock(candidate)
>> lock(running)
>> edit-config(candidate, /a = 10)
>> edit-config(running, /b = 3)
>> commit
>> unlock(running)
>> unlock(candidate)
>>
>> The commit deletes /b and sets /a back to its original value (5).
>> Editing running and also candidate does not work well in NETCONF.
>> NETCONF only works well if one target datastore is used.
>>
>>
>> Andy
>>
>>
>>
>> On Mon, Aug 12, 2013 at 7:59 AM, Jonathan Hansford
>>  wrote:
>>>
>>> Hi,
>>>
>>> Thanks for the corrections. So you're saying that if you use :candidate
>>> on a
>>> device you should not also use :writable-running.
>>>
>>> Jonathan
>>>
>>> On 12/08/2013 15:54, Andy Bierman wrote:
>>>>
>>>> Hi,
>>>>
>>>> The operations below are wrong.
>>>>  (candidate, running) is  instead
>>>>  (running, candidate) is  instead
>>>>
>>>> The problems occur when running is edited separately from candidate.
>>>> I'm not going to spell it out.  Those who have implemented concurrent
>>>> transactions understand the issues.
>>>>
>>>> Andy
>>>>
>>>>
>>>> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>>>>  wrote:
>>>>>
>>>>> Andy,
>>>>>
>>>>> You propose that ":candidate and :writable-running together should be
>>>>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>>>>
>>>>> ... it is important to recognize that some operations are clearly more
>>>>> sensitive by nature than others.  For instance,  to the
>>>>> startup
>>>>> or running configurations is clearly not a normal provisioning
>>>>> operation,
>>>>> whereas  is.  Such global operations MUST disallow the
>>>>> changing
>>>>> of information that an individual does not have authorization to
>>>>> perform.
>>>>> For example, if user A is not allowed to configure an IP address on an
>>>>> interface but user B has configured an IP address on an interface in
>>>>> the
>>>>>  configuration, user A MUST NOT be allowed to commit the
>>>>>  configuration.
>>>>>
>>>>> Presumably, if :candidate is supported, the approach would be to:
>>>>>
>>>>>   and 
>>>>>   to 
>>>>>   within the limits of the user's privileges
>>>>>   (or use  set to  in
>>>>> the
>>>>> previous set, if the change is trivial)
>>>>>   to 
>>>>>   and 
>>>>>
>>>>> But if the change were a simple change, wouldn't it be better to
>>>>>   with the  set to ,
>>>>> even
>>>>> if :candidate is supported? Or are you just proposing that concurrent
>>>>> use
>>>>> of
>>>>> the :candidate and :writable-running capabilities on  should
>>>>> be
>>>>> deprecated? And if that is the case, wouldn't the use of  be
>>>>> sufficient?
>>>>>
>>>>> Jonathan
>>>>>
>>>>> On 2013-08-08 16:37, Andy Bierman wrote:
>>>>>
>>>>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>>>>  wrote:
>>>>>
>>>>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>>>>
>>>>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>>>>> datastore defaults to read-only. Would it be worth raising an erratum
>>>>> to
>>>>> clarify that point?
>>>>>
>>>>> Implementing NETCONF read-only has obviously little value for real
>>>>> configuration management.
>>>>>
>>>>> Yes, but base:1.1 does not actually require any editing capabilities.
>>>>> What if a company wanted to use NETCONF for monitoring and/or
>>>>> notifications?  Then the base:1.1 operation set is simple to implement,
>>>>> and they do not advertise any optional capabilities, so the client
>>>>> should figure out what operations are allowed.
>>>>>
>>>>> The reason why we have :writable-running and :candidate is that some
>>>>> major
>>>>> vendors use very different models when it comes to making configuration
>>>>> changes and as such you will see implementations that either announce
>>>>> :writable-running or :candidate or :writable-running and :candidate
>>>>> together.
>>>>>
>>>>> :candidate and :writable-running together should be considered
>>>>> deprecated.
>>>>> This is a degenerate use-case for concurrent transactions.  The WG
>>>>> should
>>>>> standardize this properly at some point in the future, so clients can
>>>>> use
>>>>> a predictable standard transaction model.
>>>>>
>>>>> /js
>>>>>
>>>>> Andy
>>>
>>>
>

From j.schoenwaelder@jacobs-university.de  Mon Aug 12 09:36: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 C08DE21F889C for ; Mon, 12 Aug 2013 09:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.207
X-Spam-Level: 
X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du--lFXMPgfN for ; Mon, 12 Aug 2013 09:36:06 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A348E21F9CCA for ; Mon, 12 Aug 2013 08:53:25 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D3D912096B; Mon, 12 Aug 2013 17:53:15 +0200 (CEST)
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 W7n15hXPjR1Z; Mon, 12 Aug 2013 17:53:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 196E2208C6; Mon, 12 Aug 2013 17:53:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 9F29A27C824E; Mon, 12 Aug 2013 17:53:09 +0200 (CEST)
Date: Mon, 12 Aug 2013 17:53:09 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20130812155309.GA22819@elstar.local>
Mail-Followup-To: Andy Bierman , Jonathan Hansford , netconf@ietf.org
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net> 
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] The  configuration datastore and :writable-running
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: Mon, 12 Aug 2013 16:36:11 -0000

On Mon, Aug 12, 2013 at 08:13:09AM -0700, Andy Bierman wrote:
> Hi,
> 
> You can lock everything and still NETCONF does not handle it correctly:
> 
> start with /a = 5 in both candidate and running
> lock(candidate)
> lock(running)
> edit-config(running, /a = 10)
> edit-config(running, /b = 3)
> commit
> unlock(running)
> unlock(candidate)
> 
> The commit deletes /b and sets /a back to its original value (5).
> Editing running and also candidate does not work well in NETCONF.
> NETCONF only works well if one target datastore is used.

[fixed the example]

I think it is well defined what happens. What is your definition of
'correct' in this case?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Mon Aug 12 09:43:13 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 810FB21E80BF for ; Mon, 12 Aug 2013 09:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.052
X-Spam-Level: 
X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdGHuSF7X5R2 for ; Mon, 12 Aug 2013 09:43:09 -0700 (PDT)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id E390421F937E for ; Mon, 12 Aug 2013 09:05:46 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id y10so3572328pdj.39 for ; Mon, 12 Aug 2013 09:05:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=1Zv062KEX09oLKfUYotD5muiEGoU6fsIpWLcBcOsh/M=; b=gu89k4DIitkcJGA+D7trzWY6hcSe6mfZMjg9m99gYYxwqdcoklNR3CpzOlLPOS9pdF cRuktl+6Rs3P9cYdwVLwqbT4BfF+HG64FJYBugnDYpHpf1QH3aok/9SchUn6J3FVy4SP SdZy7jjOFnDjwWdHiptyhwppCiMZ44z4KMR1qMLHWg8aIESe+KI9krpYIcr7vrGf9rtQ ii2fHSLYOql/kJW7kExvoAphq/s+5vXv15QhANwKUigRgWElR9MmEVAtTrdQUU8cDnY9 n2Mez7kVF9d0Bzw0PHfhALsxxw2hvXV+Dk0Qp00gxT8HaZWoRymFGgoMut6Bw1rRitwk oyug==
X-Gm-Message-State: ALoCoQnpbmMnf1xtuMVx9fApW2FhkfuvsJ3LeK5e8dgPOmHZOE6DY0iSBrh2z8nYkuoI1R9Bketk
MIME-Version: 1.0
X-Received: by 10.66.100.134 with SMTP id ey6mr4743355pab.38.1376323540356; Mon, 12 Aug 2013 09:05:40 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 09:05:40 -0700 (PDT)
In-Reply-To: <20130812155309.GA22819@elstar.local>
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net>  <20130812155309.GA22819@elstar.local>
Date: Mon, 12 Aug 2013 09:05:40 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Andy Bierman ,  Jonathan Hansford , netconf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 16:43:13 -0000

On Mon, Aug 12, 2013 at 8:53 AM, Juergen Schoenwaelder
 wrote:
> On Mon, Aug 12, 2013 at 08:13:09AM -0700, Andy Bierman wrote:
>> Hi,
>>
>> You can lock everything and still NETCONF does not handle it correctly:
>>
>> start with /a = 5 in both candidate and running
>> lock(candidate)
>> lock(running)
>> edit-config(running, /a = 10)
>> edit-config(running, /b = 3)
>> commit
>> unlock(running)
>> unlock(candidate)
>>
>> The commit deletes /b and sets /a back to its original value (5).
>> Editing running and also candidate does not work well in NETCONF.
>> NETCONF only works well if one target datastore is used.
>
> [fixed the example]
>
> I think it is well defined what happens. What is your definition of
> 'correct' in this case?
>

Concurrent transactions need to work like source code control systems.
The server must perform a conceptual "update" on the candidate
to discover edit collisions.  In this example, the server knows
the candidate is not changing anything during the commit.

    [discard-changes; running == candidate at start]
    edit-config(running, /a = 10)
    edit-config(running, /b = 3)
    edit-config(candidate, /a = 42)
    commit

In this example, the conceptual update fails because /a
was changed in both running and the candidate.
The commit fails because /a cannot be set to 42.
The candidate started with /a = 5 but /a = 10
at the time of the commit.

To get out of this state, the operator or application
needs to fix the collision, just like with source code control.

> /js

Andy

>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
> Fax:   +49 421 200 3103         

From j.schoenwaelder@jacobs-university.de  Mon Aug 12 09:45:59 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 9B04021F944C for ; Mon, 12 Aug 2013 09:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.208
X-Spam-Level: 
X-Spam-Status: No, score=-103.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-EGkUiIpZub for ; Mon, 12 Aug 2013 09:45:54 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BB73A21F9D05 for ; Mon, 12 Aug 2013 09:17:09 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id F106C20979; Mon, 12 Aug 2013 18:17:06 +0200 (CEST)
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 3MdwD-RkoJpF; Mon, 12 Aug 2013 18:17:06 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8162320590; Mon, 12 Aug 2013 18:17:06 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D8B5D27C83E7; Mon, 12 Aug 2013 18:17:00 +0200 (CEST)
Date: Mon, 12 Aug 2013 18:17:00 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20130812161700.GA22976@elstar.local>
Mail-Followup-To: Andy Bierman , Jonathan Hansford , netconf@ietf.org
References:  <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net>  <20130812155309.GA22819@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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: Mon, 12 Aug 2013 16:45:59 -0000

On Mon, Aug 12, 2013 at 09:05:40AM -0700, Andy Bierman wrote:
> 
> Concurrent transactions need to work like source code control systems.
> The server must perform a conceptual "update" on the candidate
> to discover edit collisions.  In this example, the server knows
> the candidate is not changing anything during the commit.
> 

Well, this is clearly not what NETCONF does today.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Mon Aug 12 10:32:03 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 3CD5321F8EEA for ; Mon, 12 Aug 2013 10:31:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.427,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zffk4vDGuVwP for ; Mon, 12 Aug 2013 10:31:53 -0700 (PDT)
Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8913021F89A5 for ; Mon, 12 Aug 2013 10:29:18 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id lb1so7798757pab.26 for ; Mon, 12 Aug 2013 10:29:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=lSk4bWxLLQMWTlQZaMIkoqnHThIBN+4kE8b5L2+9drY=; b=ltF+PS7aIiw7VMJ8aThm+uilkII6J2wNknRoEk5UXzdvofq1pL50h3F5ezMaoNGVle 2hQ4W7ci/UnX7T5IXUsBvf64ktucJP6qQPAk0EdlETNl7WTggLH0/yMtkqDznlmMN4O2 HXOsxQiNRMlnDJe5Rlg5gJAAYi0bPOu4WMPzwuB//DvJwvUEfyRXR0wEVcyY+kdLxZws dwIpdtZ5pWVmB95MEKcfYuMf4An/mnQsac4vaXTSBV9go3VJeyoWCdmbXZZwz3qmsuww xrZmOl3sE6rqxkJgbm7t+zEmu4b/jtFZbQE+R6GFAjAcyx79kw03q201POFl8iT6C0sM e74Q==
X-Gm-Message-State: ALoCoQmXyPwDwvUOWko4PDOY9bY8eOV9qjCqU59GBHPv870XU+WRO1nPUZITi760e2sYbuog0rJi
MIME-Version: 1.0
X-Received: by 10.68.197.36 with SMTP id ir4mr159025pbc.96.1376328558310; Mon, 12 Aug 2013 10:29:18 -0700 (PDT)
Received: by 10.70.12.161 with HTTP; Mon, 12 Aug 2013 10:29:18 -0700 (PDT)
In-Reply-To: <20130812161700.GA22976@elstar.local>
References:  <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <5208F848.6000608@hansfords.net>  <20130812155309.GA22819@elstar.local>  <20130812161700.GA22976@elstar.local>
Date: Mon, 12 Aug 2013 10:29:18 -0700
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  Jonathan Hansford , netconf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 12 Aug 2013 17:32:03 -0000

On Mon, Aug 12, 2013 at 9:17 AM, Juergen Schoenwaelder
 wrote:
> On Mon, Aug 12, 2013 at 09:05:40AM -0700, Andy Bierman wrote:
>>
>> Concurrent transactions need to work like source code control systems.
>> The server must perform a conceptual "update" on the candidate
>> to discover edit collisions.  In this example, the server knows
>> the candidate is not changing anything during the commit.
>>
>
> Well, this is clearly not what NETCONF does today.
>

Clearly not.  I didn't say this is how NETCONF works.
One would need to start throwing out operations
to make concurrent transactions work properly.
Global locks and explicit partial locks on data nodes
in the running datastore are not needed if concurrent
transactions are implemented correctly.


> /js
>

Andy

From jonathan@hansfords.net  Tue Aug 20 09:17:41 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 25F0011E80EC for ; Tue, 20 Aug 2013 09:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrSwwRjqYrcX for ; Tue, 20 Aug 2013 09:17:35 -0700 (PDT)
Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1763811E80E1 for ; Tue, 20 Aug 2013 09:17:29 -0700 (PDT)
Received: from [127.0.0.1] ([84.92.149.4]) by avasout04 with smtp id F4HR1m00D05w0Nk014HTnK; Tue, 20 Aug 2013 17:17:27 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=bL0vfpOZ c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=yCgouOt5RcIA:10 a=fsXQbgwv7fIA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=LcRfbuCf9oUA:10 a=yrKqXqSrJzi9xhPY5RwA:9 a=B-_SwXlC1ScKmM3p:21 a=Q0pSg3e4EZZ9y6ij:21 a=wPNLvfGTeEIA:10 a=1rgnPY4EEFsA:10 a=zeshHG33Dl4A:10
Message-ID: <52139693.9040104@hansfords.net>
Date: Tue, 20 Aug 2013 17:17:23 +0100
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andy Bierman 
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130820-0, 20/08/2013), Outbound message
X-Antivirus-Status: Clean
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 20 Aug 2013 16:17:41 -0000

Having read RFC 6241 again (specifically, "a lock MUST NOT be granted if 
... the target configuration is , it has already been 
modified, and these changes have not been committed or rolled back"), am 
I correct in assuming the first two lines should be reversed which, when 
combined with Andy's correction below, would give:


  and 

On 12/08/2013 15:54, Andy Bierman wrote:
> Hi,
>
> The operations below are wrong.
>  (candidate, running) is  instead
>  (running, candidate) is  instead
>
> The problems occur when running is edited separately from candidate.
> I'm not going to spell it out.  Those who have implemented concurrent
> transactions understand the issues.
>
> Andy
>
>
> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>  wrote:
>> Andy,
>>
>> You propose that ":candidate and :writable-running together should be
>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>
>> ... it is important to recognize that some operations are clearly more
>> sensitive by nature than others.  For instance,  to the startup
>> or running configurations is clearly not a normal provisioning operation,
>> whereas  is.  Such global operations MUST disallow the changing
>> of information that an individual does not have authorization to perform.
>> For example, if user A is not allowed to configure an IP address on an
>> interface but user B has configured an IP address on an interface in the
>>  configuration, user A MUST NOT be allowed to commit the
>>  configuration.
>>
>> Presumably, if :candidate is supported, the approach would be to:
>>
>>   and 
>>   to 
>>   within the limits of the user's privileges
>>   (or use  set to  in the
>> previous set, if the change is trivial)
>>   to 
>>   and 
>>
>> But if the change were a simple change, wouldn't it be better to
>>   with the  set to , even
>> if :candidate is supported? Or are you just proposing that concurrent use of
>> the :candidate and :writable-running capabilities on  should be
>> deprecated? And if that is the case, wouldn't the use of  be
>> sufficient?
>>
>> Jonathan
>>
>> On 2013-08-08 16:37, Andy Bierman wrote:
>>
>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>  wrote:
>>
>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>
>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>> datastore defaults to read-only. Would it be worth raising an erratum to
>> clarify that point?
>>
>> Implementing NETCONF read-only has obviously little value for real
>> configuration management.
>>
>> Yes, but base:1.1 does not actually require any editing capabilities.
>> What if a company wanted to use NETCONF for monitoring and/or
>> notifications?  Then the base:1.1 operation set is simple to implement,
>> and they do not advertise any optional capabilities, so the client
>> should figure out what operations are allowed.
>>
>> The reason why we have :writable-running and :candidate is that some major
>> vendors use very different models when it comes to making configuration
>> changes and as such you will see implementations that either announce
>> :writable-running or :candidate or :writable-running and :candidate
>> together.
>>
>> :candidate and :writable-running together should be considered deprecated.
>> This is a degenerate use-case for concurrent transactions.  The WG should
>> standardize this properly at some point in the future, so clients can use
>> a predictable standard transaction model.
>>
>> /js
>>
>> Andy


From jonathan@hansfords.net  Tue Aug 20 09:28:47 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 1735711E8121 for ; Tue, 20 Aug 2013 09:28:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TpwPJTlLTzc for ; Tue, 20 Aug 2013 09:28:32 -0700 (PDT)
Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id E35CB11E80E4 for ; Tue, 20 Aug 2013 09:28:31 -0700 (PDT)
Received: from [127.0.0.1] ([84.92.149.4]) by avasout04 with smtp id F4UV1m00205w0Nk014UWYm; Tue, 20 Aug 2013 17:28:30 +0100
X-CM-Score: 0.00
X-CNFS-Analysis: v=2.1 cv=bL0vfpOZ c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=yCgouOt5RcIA:10 a=fsXQbgwv7fIA:10 a=0B8HqoTn75oA:10 a=8nJEP1OIZ-IA:10 a=6bkCdLdQAAAA:8 a=LcRfbuCf9oUA:10 a=48vgC7mUAAAA:8 a=uDMWStPFuUNJKKRDsMIA:9 a=KNEvsaN1qxigXzXH:21 a=UsYoALaWtLhf0hJq:21 a=wPNLvfGTeEIA:10 a=1rgnPY4EEFsA:10 a=zeshHG33Dl4A:10 a=lZB815dzVvQA:10
Message-ID: <5213992A.4030200@hansfords.net>
Date: Tue, 20 Aug 2013 17:28:26 +0100
From: Jonathan Hansford 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andy Bierman 
References:   <83653ec1603a918344265ff5a9b0bfd1@imap.plus.net> <20130808151740.GA10747@elstar.local>  <7dad41b1b73cbdfe6c6c7cf295149af7@imap.plus.net>  <52139693.9040104@hansfords.net>
In-Reply-To: <52139693.9040104@hansfords.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 130820-0, 20/08/2013), Outbound message
X-Antivirus-Status: Clean
Cc: netconf@ietf.org
Subject: Re: [Netconf] The  configuration datastore and :writable-running
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, 20 Aug 2013 16:28:48 -0000

In fact, thinking about it, it would make more sense to:

 



to ensure no changes were made to  after discarding changes.

On 20/08/2013 17:17, Jonathan Hansford wrote:
> Having read RFC 6241 again (specifically, "a lock MUST NOT be granted 
> if ... the target configuration is , it has already been 
> modified, and these changes have not been committed or rolled back"), 
> am I correct in assuming the first two lines should be reversed which, 
> when combined with Andy's correction below, would give:
>
> 
>   and 
>
> On 12/08/2013 15:54, Andy Bierman wrote:
>> Hi,
>>
>> The operations below are wrong.
>>  (candidate, running) is  instead
>>  (running, candidate) is  instead
>>
>> The problems occur when running is edited separately from candidate.
>> I'm not going to spell it out.  Those who have implemented concurrent
>> transactions understand the issues.
>>
>> Andy
>>
>>
>> On Mon, Aug 12, 2013 at 3:48 AM, Jonathan Hansford
>>  wrote:
>>> Andy,
>>>
>>> You propose that ":candidate and :writable-running together should be
>>> considered deprecated", yet RFC 6241 (pp.70-71) states:
>>>
>>> ... it is important to recognize that some operations are clearly more
>>> sensitive by nature than others.  For instance,  to the 
>>> startup
>>> or running configurations is clearly not a normal provisioning 
>>> operation,
>>> whereas  is.  Such global operations MUST disallow the 
>>> changing
>>> of information that an individual does not have authorization to 
>>> perform.
>>> For example, if user A is not allowed to configure an IP address on an
>>> interface but user B has configured an IP address on an interface in 
>>> the
>>>  configuration, user A MUST NOT be allowed to commit the
>>>  configuration.
>>>
>>> Presumably, if :candidate is supported, the approach would be to:
>>>
>>>   and 
>>>   to 
>>>   within the limits of the user's privileges
>>>   (or use  set to  
>>> in the
>>> previous set, if the change is trivial)
>>>   to 
>>>   and 
>>>
>>> But if the change were a simple change, wouldn't it be better to
>>>   with the  set to 
>>> , even
>>> if :candidate is supported? Or are you just proposing that 
>>> concurrent use of
>>> the :candidate and :writable-running capabilities on  
>>> should be
>>> deprecated? And if that is the case, wouldn't the use of  be
>>> sufficient?
>>>
>>> Jonathan
>>>
>>> On 2013-08-08 16:37, Andy Bierman wrote:
>>>
>>> On Thu, Aug 8, 2013 at 8:17 AM, Juergen Schoenwaelder
>>>  wrote:
>>>
>>> On Thu, Aug 08, 2013 at 04:06:55PM +0100, Jonathan Hansford wrote:
>>>
>>> I don't recall seeing it stated anywhere in RFC 6241 that the running
>>> datastore defaults to read-only. Would it be worth raising an 
>>> erratum to
>>> clarify that point?
>>>
>>> Implementing NETCONF read-only has obviously little value for real
>>> configuration management.
>>>
>>> Yes, but base:1.1 does not actually require any editing capabilities.
>>> What if a company wanted to use NETCONF for monitoring and/or
>>> notifications?  Then the base:1.1 operation set is simple to implement,
>>> and they do not advertise any optional capabilities, so the client
>>> should figure out what operations are allowed.
>>>
>>> The reason why we have :writable-running and :candidate is that some 
>>> major
>>> vendors use very different models when it comes to making configuration
>>> changes and as such you will see implementations that either announce
>>> :writable-running or :candidate or :writable-running and :candidate
>>> together.
>>>
>>> :candidate and :writable-running together should be considered 
>>> deprecated.
>>> This is a degenerate use-case for concurrent transactions. The WG 
>>> should
>>> standardize this properly at some point in the future, so clients 
>>> can use
>>> a predictable standard transaction model.
>>>
>>> /js
>>>
>>> Andy
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf


From nordmark@cisco.com  Fri Aug 23 19:19:57 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 EEA0721F9E21 for ; Fri, 23 Aug 2013 19:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5QYSrXMkzLa for ; Fri, 23 Aug 2013 19:19:52 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B721F9C69 for ; Fri, 23 Aug 2013 19:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=760; q=dns/txt; s=iport; t=1377310792; x=1378520392; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Wysq2V4pilzAyPcEnnoySeCH21UEVG2ydK2jahCKP0U=; b=i5pIcF2TrwaBPJ7Mib9jm/aNQ9Ga6eCX19Wwx77vJnAB29xlH3VXTRmo zdfJKvGM0wtsxGRb+rvxZO/YFoPgVfG3GEBMqLt2ZMQ1E6w8G5tbuxzMK uhwgLf8lPO16KHmHia4BAwnyuRa81gR9OL8O/OobTkfzVEmwZOxXPyaPZ 8=;
X-IronPort-AV: E=Sophos;i="4.89,946,1367971200"; d="scan'208";a="89960678"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 24 Aug 2013 02:19:48 +0000
Received: from [10.21.73.151] ([10.21.73.151]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7O2JlkR010015; Sat, 24 Aug 2013 02:19:47 GMT
Message-ID: <5218183D.1050400@cisco.com>
Date: Fri, 23 Aug 2013 19:19:41 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: netconf@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Netconf] Netconf notifications and transport flow control?
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: Sat, 24 Aug 2013 02:19:58 -0000

I was looking at RFC 5277 to see what would happen if a client 
subscribes to netconf events, there are lots of events generated, and 
the client is slow at receiving those events. That would result in the 
transport (e.g., ssh) being flow controlled.

The document looks silent on this topic.

In the extreme the netconf server might run out of memory if it needs to 
queue all the events for arbitrarily slow clients. Should the server 
rudely close the transport connection when this happens?
Or should the netconf server (silently) drop events if the client is 
slow at receiving them?
Or is there a mechanism by which the server can tell the client "I've 
dropped N events since you were too slow"?

RTFM's welcome.

Thanks,
    Erik

From bertietf@bwijnen.net  Wed Aug 28 01:40: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 7484111E8224 for ; Wed, 28 Aug 2013 01:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.996
X-Spam-Level: 
X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDNCuOxES63T for ; Wed, 28 Aug 2013 01:39:55 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4CD11E8151 for ; Wed, 28 Aug 2013 01:39:54 -0700 (PDT)
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 1VEbI5-0005Qy-K6; Wed, 28 Aug 2013 10:39:51 +0200
Received: from kitten.ripe.net ([193.0.1.240] helo=[IPv6:::1]) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1VEbI5-0003rD-Fh; Wed, 28 Aug 2013 10:39:49 +0200
Message-ID: <521DB755.9050304@bwijnen.net>
Date: Wed, 28 Aug 2013 10:39:49 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Erik Nordmark 
References: <5218183D.1050400@cisco.com>
In-Reply-To: <5218183D.1050400@cisco.com>
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: 20130828 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: 86ab03e524994f79ca2c75a176445dd4a0304ee5e90471e965f5acda1849453e
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 08:40:00 -0000

Could some of the implemetors respond to this question please?

Bert

On 8/24/13 4:19 AM, Erik Nordmark wrote:
>
> I was looking at RFC 5277 to see what would happen if a client subscribes to netconf events, there are lots of events generated, and
> the client is slow at receiving those events. That would result in the transport (e.g., ssh) being flow controlled.
>
> The document looks silent on this topic.
>
> In the extreme the netconf server might run out of memory if it needs to queue all the events for arbitrarily slow clients. Should
> the server rudely close the transport connection when this happens?
> Or should the netconf server (silently) drop events if the client is slow at receiving them?
> Or is there a mechanism by which the server can tell the client "I've dropped N events since you were too slow"?
>
> RTFM's welcome.
>
> Thanks,
>     Erik
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>

From mbj@tail-f.com  Wed Aug 28 01:47:56 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 6203411E8262 for ; Wed, 28 Aug 2013 01:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCqML6Hm0oOB for ; Wed, 28 Aug 2013 01:47:51 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8611E8151 for ; Wed, 28 Aug 2013 01:47:51 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 30DDA1200089; Wed, 28 Aug 2013 10:47:49 +0200 (CEST)
Date: Wed, 28 Aug 2013 10:47:48 +0200 (CEST)
Message-Id: <20130828.104748.13510328.mbj@tail-f.com>
To: bertietf@bwijnen.net
From: Martin Bjorklund 
In-Reply-To: <521DB755.9050304@bwijnen.net>
References: <5218183D.1050400@cisco.com> <521DB755.9050304@bwijnen.net>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 08:47:56 -0000

Hi,

"Bert Wijnen (IETF)"  wrote:
> Could some of the implemetors respond to this question please?
> 
> Bert
> 
> On 8/24/13 4:19 AM, Erik Nordmark wrote:
> >
> > I was looking at RFC 5277 to see what would happen if a client subscribes to
> > netconf events, there are lots of events generated, and
> > the client is slow at receiving those events. That would result in the
> > transport (e.g., ssh) being flow controlled.
> >
> > The document looks silent on this topic.

Correct.  Which means that this is currently no standard behavior in
this case, and thus up to the implementations to decide what to do.


/martin


> >
> > In the extreme the netconf server might run out of memory if it needs to
> > queue all the events for arbitrarily slow clients. Should
> > the server rudely close the transport connection when this happens?
> > Or should the netconf server (silently) drop events if the client is slow at
> > receiving them?
> > Or is there a mechanism by which the server can tell the client "I've dropped
> > N events since you were too slow"?
> >
> > RTFM's welcome.
> >
> > Thanks,
> >     Erik
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 

From nordmark@cisco.com  Wed Aug 28 07:36:25 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 205A511E81A1 for ; Wed, 28 Aug 2013 07:36:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwHXLuE0r7em for ; Wed, 28 Aug 2013 07:36:20 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BC18211E81BD for ; Wed, 28 Aug 2013 07:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1287; q=dns/txt; s=iport; t=1377700580; x=1378910180; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cH8sYivwYH/WGtg3HwQtE3PHVn03YD73tV+651hsUjw=; b=C66XJQi3MWp37/mfxbVyKG/Pf2paz8gAo/VFFx3zsBBq6Qjpvk5khllW h/KUZ8OmX/+jDpQ3vfAGV4lxOyHBTNu8CBPXkHqLg1Pk+B3tApouw5mQj jNiw1sDG5GBNDCUoJwyL5/UGJ+/KrCWHk+67xzQvFjcAkFn/cX+1Bhb3C U=;
X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="87156662"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Aug 2013 14:36:18 +0000
Received: from [10.21.89.156] (sjc-vpn5-412.cisco.com [10.21.89.156]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7SEaHdP016174; Wed, 28 Aug 2013 14:36:17 GMT
Message-ID: <521E0AE0.3070809@cisco.com>
Date: Wed, 28 Aug 2013 07:36:16 -0700
From: Erik Nordmark 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Martin Bjorklund 
References: <5218183D.1050400@cisco.com> <521DB755.9050304@bwijnen.net> <20130828.104748.13510328.mbj@tail-f.com>
In-Reply-To: <20130828.104748.13510328.mbj@tail-f.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 14:36:25 -0000

On 8/28/13 1:47 AM, Martin Bjorklund wrote:

> Correct.  Which means that this is currently no standard behavior in
> this case, and thus up to the implementations to decide what to do.

Thanks Martin.

Do you (or the list) know what the range of implementation choices that 
are out there?

The ones I could come up with (silently not send some events, or drop 
the transport connection) seems a bit surprising and disruptive.

    Erik

>
> /martin
>
>
>>>
>>> In the extreme the netconf server might run out of memory if it needs to
>>> queue all the events for arbitrarily slow clients. Should
>>> the server rudely close the transport connection when this happens?
>>> Or should the netconf server (silently) drop events if the client is slow at
>>> receiving them?
>>> Or is there a mechanism by which the server can tell the client "I've dropped
>>> N events since you were too slow"?
>>>
>>> RTFM's welcome.
>>>
>>> Thanks,
>>>      Erik
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
>>


From mbj@tail-f.com  Wed Aug 28 07:50:05 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 EA19A21F85B2 for ; Wed, 28 Aug 2013 07:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level: 
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwtDAIgnqXhr for ; Wed, 28 Aug 2013 07:50:01 -0700 (PDT)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4532D21F84E3 for ; Wed, 28 Aug 2013 07:49:53 -0700 (PDT)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 9604E12000A8; Wed, 28 Aug 2013 16:49:51 +0200 (CEST)
Date: Wed, 28 Aug 2013 16:49:51 +0200 (CEST)
Message-Id: <20130828.164951.405622477.mbj@tail-f.com>
To: nordmark@cisco.com
From: Martin Bjorklund 
In-Reply-To: <521E0AE0.3070809@cisco.com>
References: <521DB755.9050304@bwijnen.net> <20130828.104748.13510328.mbj@tail-f.com> <521E0AE0.3070809@cisco.com>
X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 14:50:06 -0000

Erik Nordmark  wrote:
> On 8/28/13 1:47 AM, Martin Bjorklund wrote:
> 
> > Correct.  Which means that this is currently no standard behavior in
> > this case, and thus up to the implementations to decide what to do.
> 
> Thanks Martin.
> 
> Do you (or the list) know what the range of implementation choices that are out
> there?
> 
> The ones I could come up with (silently not send some events, or drop the
> transport connection) seems a bit surprising and disruptive.

Assuming a stream with replay, dropping the transport might actually
not be that disruptive - since in this case the client can reconnect
and ask for a replay of the notifs that has occured since the last
successfully received one.

Silently dropping notifs is no different than whar would happen with a
UDP-based solution like SNMP or syslog (over UDP).

The problem should be similar for SNMP or syslog over TCP (over
something); it seems neither RFC 6587, RFC 6353, nor RFC 5592 mention
this problem, but I may have missed it.


/martin



> 
>    Erik
> 
> >
> > /martin
> >
> >
> >>>
> >>> In the extreme the netconf server might run out of memory if it needs to
> >>> queue all the events for arbitrarily slow clients. Should
> >>> the server rudely close the transport connection when this happens?
> >>> Or should the netconf server (silently) drop events if the client is slow
> >>> at
> >>> receiving them?
> >>> Or is there a mechanism by which the server can tell the client "I've
> >>> dropped
> >>> N events since you were too slow"?
> >>>
> >>> RTFM's welcome.
> >>>
> >>> Thanks,
> >>>      Erik
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netconf
> >>
> 

From michal.vaner@nic.cz  Wed Aug 28 08:00:50 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 7D7DC11E8197 for ; Wed, 28 Aug 2013 08:00:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.25
X-Spam-Level: 
X-Spam-Status: No, score=-1.25 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S02KDmudiQ5f for ; Wed, 28 Aug 2013 08:00:28 -0700 (PDT)
Received: from lair.vorner.cz (lair.vorner.cz [37.157.194.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5716F11E8195 for ; Wed, 28 Aug 2013 08:00:28 -0700 (PDT)
Received: by lair.vorner.cz (Postfix, from userid 1000) id E03153FAEE; Wed, 28 Aug 2013 17:00:24 +0200 (CEST)
Date: Wed, 28 Aug 2013 17:00:24 +0200
From: Michal 'vorner' Vaner 
To: netconf@ietf.org
Message-ID: <20130828150024.GB30554@ruth>
Mail-Followup-To: netconf@ietf.org
References: <5218183D.1050400@cisco.com> <521DB755.9050304@bwijnen.net> <20130828.104748.13510328.mbj@tail-f.com> <521E0AE0.3070809@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN"
Content-Disposition: inline
In-Reply-To: <521E0AE0.3070809@cisco.com>
User-Agent: Mutt 1.5.21 (2010-09-15, Gentoo 1.5.21-r12)
Jabber-ID: michal.vaner@nic.cz
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 15:00:51 -0000

--wzJLGUyc3ArbnUjN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hello

On Wed, Aug 28, 2013 at 07:36:16AM -0700, Erik Nordmark wrote:
> The ones I could come up with (silently not send some events, or drop=20
> the transport connection) seems a bit surprising and disruptive.

=46rom a common sense point of view, I'd be very afraid of silently droppin=
g,
since the receiving entity thinks everything is OK. Closing connection is n=
ot
optimal, but the other side at least knows there's a problem and someone wi=
ll
get prompted to investigate.

With regard

--=20
  I'm a dragon, and I will not be ignored, not even by a tree!
       Saphira Brightscales

Michal 'vorner' Vaner

--wzJLGUyc3ArbnUjN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iEYEARECAAYFAlIeEIgACgkQ7/oWwynB3bJqkQCeMS0wtJO5X8eSIW+4I9LIku2P
+S8An3omeMCRDXxlcDNHOTcKLQCcXYM5
=bUM5
-----END PGP SIGNATURE-----

--wzJLGUyc3ArbnUjN--

From andy@yumaworks.com  Wed Aug 28 08:07:09 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 CB80911E8195 for ; Wed, 28 Aug 2013 08:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Level: 
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=0.292,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkAsNO+TKayp for ; Wed, 28 Aug 2013 08:07:04 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6577611E80FA for ; Wed, 28 Aug 2013 08:07:04 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id y6so3844600lbh.7 for ; Wed, 28 Aug 2013 08:07:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Goj8m4e3sAEkeLHbX9Yz5ZO7ok+JoJPkbuquU53xPnA=; b=NT7EYgf6PGJ9LtwEnRF/gbf7QMQq3SaA0n1q3SLmON60IlqN82WHx24nfATI5T2PyU nr3dZTQBKjRJSYuaRxe7aJb02jFyYdQXTSF6FlC5Zo7PjlyrR6+12h1CiOuSOUm+w6Vg RGYWvbrJNNg4/lmOiXx6KSvH2DqaJITsNuATB9ojflSfd+dL14EYjnIn6NayfiHEXEJQ Xpharuk8DC1yKgMdaDC/7Jd8kvMIWHq01sUb9tD/+DLgtOxHEoHOB4BRk/bH7vyvHaRk BKd+eU5Mr4k3txtxUjVHoLPyQJO3r0ziDOl31A52AGfj5shyjaD//Xz4V3oWgVEj9vtK wLzw==
X-Gm-Message-State: ALoCoQldPJMZRgN2sV2UpujFc3XSvhk4I9q1mXEDtIw2m/a3RqE8qV8vtcO3PfPc5GHUfLmVCF1n
MIME-Version: 1.0
X-Received: by 10.152.22.198 with SMTP id g6mr23887052laf.5.1377702423152; Wed, 28 Aug 2013 08:07:03 -0700 (PDT)
Received: by 10.112.30.136 with HTTP; Wed, 28 Aug 2013 08:07:03 -0700 (PDT)
In-Reply-To: <20130828.164951.405622477.mbj@tail-f.com>
References: <521DB755.9050304@bwijnen.net> <20130828.104748.13510328.mbj@tail-f.com> <521E0AE0.3070809@cisco.com> <20130828.164951.405622477.mbj@tail-f.com>
Date: Wed, 28 Aug 2013 08:07:03 -0700
Message-ID: 
From: Andy Bierman 
To: Martin Bjorklund 
Content-Type: text/plain; charset=ISO-8859-1
Cc: netconf@ietf.org
Subject: Re: [Netconf] Netconf notifications and transport flow control?
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, 28 Aug 2013 15:07:09 -0000

On Wed, Aug 28, 2013 at 7:49 AM, Martin Bjorklund  wrote:
> Erik Nordmark  wrote:
>> On 8/28/13 1:47 AM, Martin Bjorklund wrote:
>>
>> > Correct.  Which means that this is currently no standard behavior in
>> > this case, and thus up to the implementations to decide what to do.
>>
>> Thanks Martin.
>>
>> Do you (or the list) know what the range of implementation choices that are out
>> there?
>>

One implementation strategy is to use a shared ring buffer for events.
If a notification is not delivered to a particular client before the ring buffer
wraps (to that event), then that client will lose that event. IMO dropping
the session because of a missed event is too disruptive.

This is why I added a  element to , but it is
disabled by default because the XSD does not allow extra nodes.

We also added a  operation.
Not sure why the RFC does not have it, but killing
the session and starting a new one in order to change
notification delivery seems extreme.


>> The ones I could come up with (silently not send some events, or drop the
>> transport connection) seems a bit surprising and disruptive.
>
> Assuming a stream with replay, dropping the transport might actually
> not be that disruptive - since in this case the client can reconnect
> and ask for a replay of the notifs that has occured since the last
> successfully received one.
>
> Silently dropping notifs is no different than whar would happen with a
> UDP-based solution like SNMP or syslog (over UDP).
>
> The problem should be similar for SNMP or syslog over TCP (over
> something); it seems neither RFC 6587, RFC 6353, nor RFC 5592 mention
> this problem, but I may have missed it.
>
>
> /martin
>
>
>
>>
>>    Erik
>>
>> >

Andy