From mehmet.ersue@nsn.com Mon May 6 08:27:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A459E21F869A for ; Mon, 6 May 2013 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 651Dcw5oVnWh for ; Mon, 6 May 2013 08:27:22 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 25A2021F8A74 for ; Mon, 6 May 2013 08:27:17 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r46FRBOh019912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 May 2013 17:27:11 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r46FRBLo026859 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 May 2013 17:27:11 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.156]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 6 May 2013 17:27:10 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: [Netconf] Developing Call-Home for the SSH and TLS transport bindings - New Charter text Thread-Index: Ac43gcZBI0IihwBoSgWyY8JKmyGZJgRSA0OwAF1Z7dAACi6PkA== Date: Mon, 6 May 2013 15:27:10 +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.109] 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: 5133 X-purgate-ID: 151667::1367854034-000027C8-DA2CFD9B/0-0/0-0 Subject: [Netconf] FW: Developing Call-Home for the SSH and TLS transport bindings - New Charter text 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, 06 May 2013 15:27:26 -0000 Dear Netconf WG, the co-chairs proposed a draft charter text to realize the call-home mechan= ism for the SSH and TLS bindings, as concluded in the IETF #86 meeting. We = did not get any substantial arguments against. Also, an attempt to discuss = on the priority of other issues in the queue did not bring any new perspect= ive. Based on this the co-chairs think that the WG should proceed, following the= discussion in the IETF #86, with the development of the call-home mechanis= m for the SSH and TLS bindings. We now will do slight changes to the milest= ones and give the proposed charter to our AD to initiate the approval. Concerning the Netconf RFC advancement, we did not get volunteers to co-aut= hor a deployment report and the number of deployment reports received so fa= r seems very thin to ask for advancement based on "wide deployment" at this= point in time. We therefore suggest to exclude this point from the charter= for the time being. It can be revived if things change hopefully soon. Bert & Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behal= f Of ext > Ersue, Mehmet (NSN - DE/Munich) > Sent: Friday, April 12, 2013 3:30 PM > To: netconf@ietf.org > Subject: [Netconf] Developing Call-Home for the SSH and TLS transport bin= dings - New > Charter text >=20 > Dear NETCONF WG, >=20 > we discussed in the IETF #86 Netconf session on resurrecting and developi= ng the call > home mechanism, i.e. initiation of session establishment by the server. T= he session > attendees supported the development of call home for both, the SSH and TL= S > transport bindings. >=20 > For the SSH binding, Kent Watsen volunteered to update his draft on Rever= se SSH. > Concerning the TLS binding, the authors of the rfc5539bis draft agreed to= add the > necessary text for call home. Based on the session agreement, the co-chai= rs promised > to verify the WG support on the mailing list and add call-home for the ss= h and tls > drafts to the charter. >=20 > If there are no substantial arguments against developing call home as pla= nned by April > 26, 2013 EOB, the co-chairs will add following addition to the charter an= d provide our > AD to review and initiate the IESG approval. >=20 > Whether point 3. on the list below remains in the charter depends on the = response we > get to the call on RFC advancement until May 1st. >=20 > Please send your comments to the Netconf maillist by April 26, 2013. >=20 > Draft authors: Please confirm or comment the deadlines listed in the char= ter text > below with a short note to the co-chairs. >=20 > Bert & Mehmet >=20 >=20 > =3D=3D=3D modified charter text =3D=3D=3D >=20 > In the current phase of NETCONF's incremental development the workgroup > will focus on following items: >=20 > 1. Add call home mechanism for the mandatory SSH binding providing a > server-initiated session establishment. >=20 > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., updat= e > RFC 5539) and add the call home mechanism to provide a server-initiated > session establishment. >=20 > 3. Based on the implementation, deployment experience and > interoperability testing, the WG will produce a NETCONF status report. > The result may be clarifications for RFC6241 and RFC6242 and addressing > any reported errata. >=20 > Goals and Milestones: > Done - WG Last Call on rfc4741bis > Done - Send with-defaults to IESG for consideration as Proposed Sta= ndard > Done - first WG draft (rev 00) on NACM posted > Done - rfc4741bis to IESG for consideration as Proposed Standard > Done - Send rfc4742bis to IESG for consideration as proposed Standa= rd > Done - first WG draft (rev 00) on NETCONF specific YANG modules pos= ted > Done - WGLC for NACM document > Done - WGLC for NETCONF specific notifications document > Done - submit NACM document to IESG for consideration as Proposed S= tandard > Done - submit NETCONF specific notifications document to IESG for c= onsideration > as Proposed Standard > May 2013 - Submit initial WG document on Reverse SSH > May 2013 - Collect Implementation/Deployment reports for RFC6241 and 62= 42 > May 2013 - IETF wiki page and/or initial I-D for RFC6241/6242 > implementation/deployment experience > Jun 2013 - WGLC for rfc5539bis > Jul 2013 - WGLC for Reverse SSH > Jul 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Jul 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed S= tandard > Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed = Standard > Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment exper= ience doc > to IESG for publication as Informational RFC >=20 > =3D=3D=3D end-of modified charter text =3D=3D=3D >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Tue May 7 09:40: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 A985C21F93E3 for ; Tue, 7 May 2013 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 G+ohhY+VXPsL for ; Tue, 7 May 2013 09:40:04 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8182E21F93E5 for ; Tue, 7 May 2013 09:40:03 -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 r47GdxMf010959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 May 2013 18:39:59 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r47GdxYr013871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 18:39:59 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 7 May 2013 18:39:59 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.156]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 7 May 2013 18:39:58 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Benoit Claise Thread-Topic: Proposed Netconf Charter for Approval Thread-Index: Ac5K/F/1QmzHo8tEQJObL1s6sxkZxAAMQKLA Date: Tue, 7 May 2013 16:39:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_" 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: 45289 X-purgate-ID: 151667::1367944799-000076D0-D697FBE2/0-0/0-0 Cc: "netconf@ietf.org" Subject: [Netconf] Proposed Netconf Charter for Approval 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, 07 May 2013 16:40:08 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_" --_000_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, below is the charter proposal we would like to provide for approval. After a call for comments on the Netconf maillist there was no substantial = argument against it. Especially, we think the TLS draft should developed fu= rther. A discussion on the prioritization of topics in the queue has been started = but there is no result yet. We will restart the discussion on the prioritie= s and hint the WG to prepare themselves to have an answer at the latest in = Berlin. For IETF #87 we asked for a Netconf session on Thursday to enable t= he WG members to have side discussions, which hopefully will help to weight= the priorities and to consolidate the views on particular topics like oper= ational state. However, we think that we shouldn't wait on the results of this discussion = hence should start now the work on the work items decided in IETF #86. Thank you for support. Bert & Mehmet =3D=3D=3D Proposed Charter text =3D=3D=3D Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen > Mehmet Ersue > Operations and Management Area Directors: Benoit Claise > Joel Jaeggli > Operations and Management Area Advisor: Benoit Claise > Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol has the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting- related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring the Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol is data modeling language independent, but YANG is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Add call home mechanism for the mandatory SSH binding providing a server-initiated session establishment. 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. Goals and Milestones: Done - WG Last Call on rfc4741bis Done - Send with-defaults to IESG for consideration as Proposed Stand= ard Done - first WG draft (rev 00) on NACM posted Done - rfc4741bis to IESG for consideration as Proposed Standard Done - Send rfc4742bis to IESG for consideration as proposed Standard Done - first WG draft (rev 00) on NETCONF specific YANG modules poste= d Done - WGLC for NACM document Done - WGLC for NETCONF specific notifications document Done - submit NACM document to IESG for consideration as Proposed Sta= ndard Done - submit NETCONF specific notifications document to IESG for con= sideration as Proposed Standard May 2013 - Submit initial WG document on Reverse SSH Jul 2013 - WGLC for rfc5539bis Jul 2013 - WGLC for Reverse SSH Aug 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed Sta= ndard Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed St= andard =3D=3D=3D End-of proposed charter text =3D=3D=3D > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:n= etconf-bounces@ietf.org] On Behalf Of ext > Ersue, Mehmet (NSN - DE/Munich) > Sent: Monday, May 06, 2013 5:27 PM > To: netconf@ietf.org > Subject: [Netconf] FW: Developing Call-Home for the SSH and TLS transport= bindings - > New Charter text > > Dear Netconf WG, > > the co-chairs proposed a draft charter text to realize the call-home mech= anism for the > SSH and TLS bindings, as concluded in the IETF #86 meeting. We did not ge= t any > substantial arguments against. Also, an attempt to discuss on the priorit= y of other > issues in the queue did not bring any new perspective. > > Based on this the co-chairs think that the WG should proceed, following t= he discussion > in the IETF #86, with the development of the call-home mechanism for the = SSH and > TLS bindings. We now will do slight changes to the milestones and give th= e proposed > charter to our AD to initiate the approval. > > Concerning the Netconf RFC advancement, we did not get volunteers to co-a= uthor a > deployment report and the number of deployment reports received so far se= ems very > thin to ask for advancement based on "wide deployment" at this point in t= ime. We > therefore suggest to exclude this point from the charter for the time bei= ng. It can be > revived if things change hopefully soon. > > Bert & Mehmet > > > > -----Original Message----- > > From: netconf-bounces@ietf.org [mailto= :netconf-bounces@ietf.org] On Behalf Of > ext > > Ersue, Mehmet (NSN - DE/Munich) > > Sent: Friday, April 12, 2013 3:30 PM > > To: netconf@ietf.org > > Subject: [Netconf] Developing Call-Home for the SSH and TLS transport b= indings - > New > > Charter text > > > > Dear NETCONF WG, > > > > we discussed in the IETF #86 Netconf session on resurrecting and develo= ping the call > > home mechanism, i.e. initiation of session establishment by the server.= The session > > attendees supported the development of call home for both, the SSH and = TLS > > transport bindings. > > > > For the SSH binding, Kent Watsen volunteered to update his draft on Rev= erse SSH. > > Concerning the TLS binding, the authors of the rfc5539bis draft agreed = to add the > > necessary text for call home. Based on the session agreement, the co-ch= airs > promised > > to verify the WG support on the mailing list and add call-home for the = ssh and tls > > drafts to the charter. > > > > If there are no substantial arguments against developing call home as p= lanned by > April > > 26, 2013 EOB, the co-chairs will add following addition to the charter = and provide our > > AD to review and initiate the IESG approval. > > > > Whether point 3. on the list below remains in the charter depends on th= e response > we > > get to the call on RFC advancement until May 1st. > > > > Please send your comments to the Netconf maillist by April 26, 2013. > > > > Draft authors: Please confirm or comment the deadlines listed in the ch= arter text > > below with a short note to the co-chairs. > > > > Bert & Mehmet > > > > > > =3D=3D=3D modified charter text =3D=3D=3D > > > > In the current phase of NETCONF's incremental development the workgro= up > > will focus on following items: > > > > 1. Add call home mechanism for the mandatory SSH binding providing a > > server-initiated session establishment. > > > > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., upd= ate > > RFC 5539) and add the call home mechanism to provide a server-initiat= ed > > session establishment. > > > > 3. Based on the implementation, deployment experience and > > interoperability testing, the WG will produce a NETCONF status report= . > > The result may be clarifications for RFC6241 and RFC6242 and addressi= ng > > any reported errata. > > > > Goals and Milestones: > > Done - WG Last Call on rfc4741bis > > Done - Send with-defaults to IESG for consideration as Proposed S= tandard > > Done - first WG draft (rev 00) on NACM posted > > Done - rfc4741bis to IESG for consideration as Proposed Standard > > Done - Send rfc4742bis to IESG for consideration as proposed Stan= dard > > Done - first WG draft (rev 00) on NETCONF specific YANG modules p= osted > > Done - WGLC for NACM document > > Done - WGLC for NETCONF specific notifications document > > Done - submit NACM document to IESG for consideration as Proposed= Standard > > Done - submit NETCONF specific notifications document to IESG for > consideration > > as Proposed Standard > > May 2013 - Submit initial WG document on Reverse SSH > > May 2013 - Collect Implementation/Deployment reports for RFC6241 and = 6242 > > May 2013 - IETF wiki page and/or initial I-D for RFC6241/6242 > > implementation/deployment experience > > Jun 2013 - WGLC for rfc5539bis > > Jul 2013 - WGLC for Reverse SSH > > Jul 2013 - WGLC on RFC6241/6242 implementation/deployment experience > > Jul 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed= Standard > > Aug 2013 - submit SSH binding to AD/IESG for consideration as Propose= d Standard > > Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment exp= erience > doc > > to IESG for publication as Informational RFC > > > > =3D=3D=3D end-of modified charter text =3D=3D=3D > > > > > > _______________________________________________ > > 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 --_000_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Benoit,
 
below is the charter proposal we would like to provide for approval.
 
After a call for comments on the Netconf maillist there was no substan= tial argument against it. Especially, we think the TLS draft should develop= ed further.
 
A discussion on the prioritization of topics in the queue has been sta= rted but there is no result yet. We will restart the discussion on the prio= rities and hint the WG to prepare themselves to have an answer at the lates= t in Berlin. For IETF #87 we asked for a Netconf session on Thursday to enable the WG members to have side dis= cussions, which hopefully will help to weight the priorities and to consoli= date the views on particular topics like operational state.
 
However, we think that we shouldn't wait on the results of this discus= sion hence should start now the work on the work items decided in IETF #86.=
&nbs= p;
Thank you for support.
&nbs= p;
Bert & Mehmet
&nbs= p;
&nbs= p;
= =3D=3D=3D Proposed Charter text =3D=3D=3D
=  
= Network Configuration (netconf)
= -------------------------------
=  
= Charter
=  
= Current Status: Active
=  
= Chairs:
=      Bert Wijnen <bertietf@bwijnen.net>
=      Mehmet Ersue <mehmet.ersue@nsn.com>
=  
= Operations and Management Area Directors:
=      Benoit Claise <bclaise@cisco.com>
=      Joel Jaeggli <joelja@bogus.com>
=  
= Operations and Management Area Advisor:
=      Benoit Claise <bclaise@cisco.com>
=  
= Mailing Lists:
=      General Discussion: netconf@ietf.org=
=      To Subscribe:       = https://www.ietf.org/mailman/listinfo/netconf<= /font>
=      Archive:       =      http://www.ietf.org/mail-archive/web/netcon= f/
 
= Description of Working Group:
=  
=   Configuration of networks of devices has become a critical requireme= nt
=   for operators in today's highly interconnected networks. Large and s= mall
=   operators alike have developed their own mechanisms or have used ven= dor
=   specific mechanisms to transfer configuration data to and from a dev= ice
=   and to examine device state information which may impact the<= /font>
=   configuration. Each of these mechanisms may be different in various<= /span>
=   aspects, such as session establishment, user authentication,<= /font>
=   configuration data exchange, and error responses.
=  
=   The NETCONF protocol has the following characteristics:
=  
=   - Provides retrieval mechanisms which can differentiate between
=   configuration data and non-configuration data
=   - Is extensible enough so that vendors can provide access to all
=   configuration data on the device using a single protocol
=   - Has a programmatic interface (avoids screen scraping and formattin= g-
=   related changes between releases)
=   - Uses an XML-based data representation, that can be easily manipula= ted
=   using non-specialized XML manipulation tools.
=   - Supports integration with existing user authentication methods
=   - Supports integration with existing configuration database systems<= /span>
=   - Supports multiple (e.g. candidate and running) data-stores to opti= mize
=   configuration preparation and activation
=   - Supports network wide configuration transactions (with features su= ch
=   as locking and rollback capability)
=   - Runs over a secure transport; SSH is mandatory to implement while = TLS,
=   BEEP, and SOAP are optional transports.
=   - Provides support for asynchronous notifications.
=   - Supports an Access Control Model and a YANG module for configuring= the
=   Access Control parameters.
=   - Supports a YANG module for System Notifications
=  
=   The NETCONF protocol is data modeling language independent, but YANG= is
=   the recommended NETCONF modeling language, which introduces advanced=
=   language features for configuration management.
=  
=   Based on the implementation, deployment experience and interoperabil= ity
=   testing, the WG aims to produce a NETCONF status report in a later s= tage.
=   The result may be clarifications for RFC6241 and RFC6242 and address= ing
=   any reported errata.
=  
=   In the current phase of NETCONF's incremental development the workgr= oup
=   will focus on following items:
=  
=   1. Add call home mechanism for the mandatory SSH binding providing a=
=   server-initiated session establishment.
=  
=   2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., up= date
=   RFC 5539) and add the call home mechanism to provide a server-initia= ted
=   session establishment.
=  
= Goals and Milestones:
=   Done     - WG Last Call on rfc4741bis
=   Done     - Send with-defaults to IESG for consid= eration as Proposed Standard
=   Done     - first WG draft (rev 00) on NACM poste= d
=   Done     - rfc4741bis to IESG for consideration = as Proposed Standard
=   Done     - Send rfc4742bis to IESG for considera= tion as proposed Standard
=   Done     - first WG draft (rev 00) on NETCONF sp= ecific YANG modules posted
=   Done     - WGLC for NACM document<= /div>
=   Done     - WGLC for NETCONF specific notificatio= ns document
=   Done     - submit NACM document to IESG for cons= ideration as Proposed Standard
=   Done     - submit NETCONF specific notifications= document to IESG for consideration as Proposed Standard
=   May 2013 - Submit initial WG document on Reverse SSH
=   Jul 2013 - WGLC for rfc5539bis
=   Jul 2013 - WGLC for Reverse SSH
=   Aug 2013 - submit rfc5539bis to AD/IESG for consideration as Propose= d Standard
=   Aug 2013 - submit SSH binding to AD/IESG for consideration as Propos= ed Standard
=  
= =3D=3D=3D End-of proposed charter text =3D=3D=3D
&nbs= p;
&nbs= p;
> -----Original Message-----
> Ersue, Mehmet (NSN - DE/Munich)
> Sent: Monday, May 06, 2013 5:27 PM
> Subject: [Netconf] FW: Developing Call-Home for the SSH and TLS t= ransport bindings -
> New Charter text
>
> Dear Netconf WG,
>
> the co-chairs proposed a draft charter text to realize the call-h= ome mechanism for the
> SSH and TLS bindings, as concluded in the IETF #86 meeting. We di= d not get any
> substantial arguments against. Also, an attempt to discuss on the= priority of other
> issues in the queue did not bring any new perspective.
>
> Based on this the co-chairs think that the WG should proceed, fol= lowing the discussion
> in the IETF #86, with the development of the call-home mechanism = for the SSH and
> TLS bindings. We now will do slight changes to the milestones and= give the proposed
> charter to our AD to initiate the approval.
>
> Concerning the Netconf RFC advancement, we did not get volunteers= to co-author a
> deployment report and the number of deployment reports received s= o far seems very
> thin to ask for advancement based on "wide deployment" = at this point in time. We
> therefore suggest to exclude this point from the charter for the = time being. It can be
> revived if things change hopefully soon.
>
> Bert & Mehmet
>
>
> > -----Original Message-----
> ext
> > Ersue, Mehmet (NSN - DE/Munich)
> > Sent: Friday, April 12, 2013 3:30 PM
> > Subject: [Netconf] Developing Call-Home for the SSH and TLS = transport bindings -
> New
> > Charter text
> >
> > Dear NETCONF WG,
> >
> > we discussed in the IETF #86 Netconf session on resurrecting= and developing the call
> > home mechanism, i.e. initiation of session establishment by = the server. The session
> > attendees supported the development of call home for both, t= he SSH and TLS
> > transport bindings.
> >
> > For the SSH binding, Kent Watsen volunteered to update his d= raft on Reverse SSH.
> > Concerning the TLS binding, the authors of the rfc5539bis dr= aft agreed to add the
> > necessary text for call home. Based on the session agreement= , the co-chairs
> promised
> > to verify the WG support on the mailing list and add call-ho= me for the ssh and tls
> > drafts to the charter.
> >
> > If there are no substantial arguments against developing cal= l home as planned by
> April
> > 26, 2013 EOB, the co-chairs will add following addition to t= he charter and provide our
> > AD to review and initiate the IESG approval.
> >
> > Whether point 3. on the list below remains in the charter de= pends on the response
> we
> > get to the call on RFC advancement until May 1st.
> >
> > Please send your comments to the Netconf maillist by April 2= 6, 2013.
> >
> > Draft authors: Please confirm or comment the deadlines liste= d in the charter text
> > below with a short note to the co-chairs.
> >
> > Bert & Mehmet
> >
> >
> > =3D=3D=3D modified charter text =3D=3D=3D
> >
> >   In the current phase of NETCONF's incremental de= velopment the workgroup
> >   will focus on following items:
> >
> >   1. Add call home mechanism for the mandatory SSH= binding providing a
> >   server-initiated session establishment.
> >
> >   2. Advance NETCONF over TLS to be in-line with N= ETCONF 1.1 (i.e., update
> >   RFC 5539) and add the call home mechanism to pro= vide a server-initiated
> >   session establishment.
> >
> >   3. Based on the implementation, deployment exper= ience and
> >   interoperability testing, the WG will produce a = NETCONF status report.
> >   The result may be clarifications for RFC6241 and= RFC6242 and addressing
> >   any reported errata.
> >
> > Goals and Milestones:
> >   Done     - WG Last Call on r= fc4741bis
> >   Done     - Send with-default= s to IESG for consideration as Proposed Standard
> >   Done     - first WG draft (r= ev 00) on NACM posted
> >   Done     - rfc4741bis to IES= G for consideration as Proposed Standard
> >   Done     - Send rfc4742bis t= o IESG for consideration as proposed Standard
> >   Done     - first WG draft (r= ev 00) on NETCONF specific YANG modules posted
> >   Done     - WGLC for NACM doc= ument
> >   Done     - WGLC for NETCONF = specific notifications document
> >   Done     - submit NACM docum= ent to IESG for consideration as Proposed Standard
> >   Done     - submit NETCONF sp= ecific notifications document to IESG for
> consideration
> > as Proposed Standard
> >   May 2013 - Submit initial WG document on Reverse= SSH
> >   May 2013 - Collect Implementation/Deployment rep= orts for RFC6241 and 6242
> >   May 2013 - IETF wiki page and/or initial I-D for= RFC6241/6242
> > implementation/deployment experience
> >   Jun 2013 - WGLC for rfc5539bis
> >   Jul 2013 - WGLC for Reverse SSH
> >   Jul 2013 - WGLC on RFC6241/6242 implementation/d= eployment experience
> >   Jul 2013 - submit rfc5539bis to AD/IESG for cons= ideration as Proposed Standard
> >   Aug 2013 - submit SSH binding to AD/IESG for con= sideration as Proposed Standard
> >   Aug 2013 - Possibly submit RFC6241/6242 implemen= tation/deployment experience
> doc
> > to IESG for publication as Informational RFC
> >
> > =3D=3D=3D end-of modified charter text =3D=3D=3D
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> _______________________________________________
> Netconf mailing list
&nbs= p;
&nbs= p;
 --_000_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_ Content-Type: text/plain; name="130507_Ersue_Charter proposal.txt" Content-Description: 130507_Ersue_Charter proposal.txt Content-Disposition: attachment; filename="130507_Ersue_Charter proposal.txt"; size=4318; creation-date="Tue, 07 May 2013 08:18:00 GMT"; modification-date="Tue, 07 May 2013 16:34:02 GMT" Content-Transfer-Encoding: base64 TmV0d29yayBDb25maWd1cmF0aW9uIChuZXRjb25mKQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQogQ2hhcnRlcg0KDQogQ3VycmVudCBTdGF0dXM6IEFjdGl2ZQ0KDQogQ2hhaXJz Og0KICAgICBCZXJ0IFdpam5lbiA8YmVydGlldGZAYndpam5lbi5uZXQ+DQogICAgIE1laG1ldCBF cnN1ZSA8bWVobWV0LmVyc3VlQG5zbi5jb20+DQoNCiBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50 IEFyZWEgRGlyZWN0b3JzOg0KICAgICBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4N CiAgICAgSm9lbCBKYWVnZ2xpIDxqb2VsamFAYm9ndXMuY29tPg0KDQogT3BlcmF0aW9ucyBhbmQg TWFuYWdlbWVudCBBcmVhIEFkdmlzb3I6DQogICAgIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lz Y28uY29tPg0KDQogTWFpbGluZyBMaXN0czoNCiAgICAgR2VuZXJhbCBEaXNjdXNzaW9uOiBuZXRj b25mQGlldGYub3JnDQogICAgIFRvIFN1YnNjcmliZTogICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQogICAgIEFyY2hpdmU6ICAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvDQoNCkRlc2NyaXB0aW9u IG9mIFdvcmtpbmcgR3JvdXA6DQoNCiAgQ29uZmlndXJhdGlvbiBvZiBuZXR3b3JrcyBvZiBkZXZp Y2VzIGhhcyBiZWNvbWUgYSBjcml0aWNhbCByZXF1aXJlbWVudA0KICBmb3Igb3BlcmF0b3JzIGlu IHRvZGF5J3MgaGlnaGx5IGludGVyY29ubmVjdGVkIG5ldHdvcmtzLiBMYXJnZSBhbmQgc21hbGwN CiAgb3BlcmF0b3JzIGFsaWtlIGhhdmUgZGV2ZWxvcGVkIHRoZWlyIG93biBtZWNoYW5pc21zIG9y IGhhdmUgdXNlZCB2ZW5kb3INCiAgc3BlY2lmaWMgbWVjaGFuaXNtcyB0byB0cmFuc2ZlciBjb25m aWd1cmF0aW9uIGRhdGEgdG8gYW5kIGZyb20gYSBkZXZpY2UNCiAgYW5kIHRvIGV4YW1pbmUgZGV2 aWNlIHN0YXRlIGluZm9ybWF0aW9uIHdoaWNoIG1heSBpbXBhY3QgdGhlDQogIGNvbmZpZ3VyYXRp b24uIEVhY2ggb2YgdGhlc2UgbWVjaGFuaXNtcyBtYXkgYmUgZGlmZmVyZW50IGluIHZhcmlvdXMN CiAgYXNwZWN0cywgc3VjaCBhcyBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHVzZXIgYXV0aGVudGlj YXRpb24sDQogIGNvbmZpZ3VyYXRpb24gZGF0YSBleGNoYW5nZSwgYW5kIGVycm9yIHJlc3BvbnNl cy4NCg0KICBUaGUgTkVUQ09ORiBwcm90b2NvbCBoYXMgdGhlIGZvbGxvd2luZyBjaGFyYWN0ZXJp c3RpY3M6DQoNCiAgLSBQcm92aWRlcyByZXRyaWV2YWwgbWVjaGFuaXNtcyB3aGljaCBjYW4gZGlm ZmVyZW50aWF0ZSBiZXR3ZWVuDQogIGNvbmZpZ3VyYXRpb24gZGF0YSBhbmQgbm9uLWNvbmZpZ3Vy YXRpb24gZGF0YQ0KICAtIElzIGV4dGVuc2libGUgZW5vdWdoIHNvIHRoYXQgdmVuZG9ycyBjYW4g cHJvdmlkZSBhY2Nlc3MgdG8gYWxsDQogIGNvbmZpZ3VyYXRpb24gZGF0YSBvbiB0aGUgZGV2aWNl IHVzaW5nIGEgc2luZ2xlIHByb3RvY29sDQogIC0gSGFzIGEgcHJvZ3JhbW1hdGljIGludGVyZmFj ZSAoYXZvaWRzIHNjcmVlbiBzY3JhcGluZyBhbmQgZm9ybWF0dGluZy0NCiAgcmVsYXRlZCBjaGFu Z2VzIGJldHdlZW4gcmVsZWFzZXMpDQogIC0gVXNlcyBhbiBYTUwtYmFzZWQgZGF0YSByZXByZXNl bnRhdGlvbiwgdGhhdCBjYW4gYmUgZWFzaWx5IG1hbmlwdWxhdGVkDQogIHVzaW5nIG5vbi1zcGVj aWFsaXplZCBYTUwgbWFuaXB1bGF0aW9uIHRvb2xzLg0KICAtIFN1cHBvcnRzIGludGVncmF0aW9u IHdpdGggZXhpc3RpbmcgdXNlciBhdXRoZW50aWNhdGlvbiBtZXRob2RzDQogIC0gU3VwcG9ydHMg aW50ZWdyYXRpb24gd2l0aCBleGlzdGluZyBjb25maWd1cmF0aW9uIGRhdGFiYXNlIHN5c3RlbXMN CiAgLSBTdXBwb3J0cyBtdWx0aXBsZSAoZS5nLiBjYW5kaWRhdGUgYW5kIHJ1bm5pbmcpIGRhdGEt c3RvcmVzIHRvIG9wdGltaXplDQogIGNvbmZpZ3VyYXRpb24gcHJlcGFyYXRpb24gYW5kIGFjdGl2 YXRpb24NCiAgLSBTdXBwb3J0cyBuZXR3b3JrIHdpZGUgY29uZmlndXJhdGlvbiB0cmFuc2FjdGlv bnMgKHdpdGggZmVhdHVyZXMgc3VjaA0KICBhcyBsb2NraW5nIGFuZCByb2xsYmFjayBjYXBhYmls aXR5KQ0KICAtIFJ1bnMgb3ZlciBhIHNlY3VyZSB0cmFuc3BvcnQ7IFNTSCBpcyBtYW5kYXRvcnkg dG8gaW1wbGVtZW50IHdoaWxlIFRMUywNCiAgQkVFUCwgYW5kIFNPQVAgYXJlIG9wdGlvbmFsIHRy YW5zcG9ydHMuDQogIC0gUHJvdmlkZXMgc3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIG5vdGlmaWNh dGlvbnMuDQogIC0gU3VwcG9ydHMgYW4gQWNjZXNzIENvbnRyb2wgTW9kZWwgYW5kIGEgWUFORyBt b2R1bGUgZm9yIGNvbmZpZ3VyaW5nIHRoZQ0KICBBY2Nlc3MgQ29udHJvbCBwYXJhbWV0ZXJzLg0K ICAtIFN1cHBvcnRzIGEgWUFORyBtb2R1bGUgZm9yIFN5c3RlbSBOb3RpZmljYXRpb25zDQoNCiAg VGhlIE5FVENPTkYgcHJvdG9jb2wgaXMgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBpbmRlcGVuZGVu dCwgYnV0IFlBTkcgaXMNCiAgdGhlIHJlY29tbWVuZGVkIE5FVENPTkYgbW9kZWxpbmcgbGFuZ3Vh Z2UsIHdoaWNoIGludHJvZHVjZXMgYWR2YW5jZWQNCiAgbGFuZ3VhZ2UgZmVhdHVyZXMgZm9yIGNv bmZpZ3VyYXRpb24gbWFuYWdlbWVudC4NCg0KICBCYXNlZCBvbiB0aGUgaW1wbGVtZW50YXRpb24s IGRlcGxveW1lbnQgZXhwZXJpZW5jZSBhbmQgaW50ZXJvcGVyYWJpbGl0eSANCiAgdGVzdGluZywg dGhlIFdHIGFpbXMgdG8gcHJvZHVjZSBhIE5FVENPTkYgc3RhdHVzIHJlcG9ydCBpbiBhIGxhdGVy IHN0YWdlLiANCiAgVGhlIHJlc3VsdCBtYXkgYmUgY2xhcmlmaWNhdGlvbnMgZm9yIFJGQzYyNDEg YW5kIFJGQzYyNDIgYW5kIGFkZHJlc3NpbmcgDQogIGFueSByZXBvcnRlZCBlcnJhdGEuDQoNCiAg SW4gdGhlIGN1cnJlbnQgcGhhc2Ugb2YgTkVUQ09ORidzIGluY3JlbWVudGFsIGRldmVsb3BtZW50 IHRoZSB3b3JrZ3JvdXANCiAgd2lsbCBmb2N1cyBvbiBmb2xsb3dpbmcgaXRlbXM6DQoNCiAgMS4g QWRkIGNhbGwgaG9tZSBtZWNoYW5pc20gZm9yIHRoZSBtYW5kYXRvcnkgU1NIIGJpbmRpbmcgcHJv dmlkaW5nIGENCiAgc2VydmVyLWluaXRpYXRlZCBzZXNzaW9uIGVzdGFibGlzaG1lbnQuDQoNCiAg Mi4gQWR2YW5jZSBORVRDT05GIG92ZXIgVExTIHRvIGJlIGluLWxpbmUgd2l0aCBORVRDT05GIDEu MSAoaS5lLiwgdXBkYXRlDQogIFJGQyA1NTM5KSBhbmQgYWRkIHRoZSBjYWxsIGhvbWUgbWVjaGFu aXNtIHRvIHByb3ZpZGUgYSBzZXJ2ZXItaW5pdGlhdGVkDQogIHNlc3Npb24gZXN0YWJsaXNobWVu dC4NCg0KR29hbHMgYW5kIE1pbGVzdG9uZXM6DQogIERvbmUgICAgIC0gV0cgTGFzdCBDYWxsIG9u IHJmYzQ3NDFiaXMNCiAgRG9uZSAgICAgLSBTZW5kIHdpdGgtZGVmYXVsdHMgdG8gSUVTRyBmb3Ig Y29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KICBEb25lICAgICAtIGZpcnN0IFdH IGRyYWZ0IChyZXYgMDApIG9uIE5BQ00gcG9zdGVkDQogIERvbmUgICAgIC0gcmZjNDc0MWJpcyB0 byBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQogIERvbmUgICAg IC0gU2VuZCByZmM0NzQyYmlzIHRvIElFU0cgZm9yIGNvbnNpZGVyYXRpb24gYXMgcHJvcG9zZWQg U3RhbmRhcmQNCiAgRG9uZSAgICAgLSBmaXJzdCBXRyBkcmFmdCAocmV2IDAwKSBvbiBORVRDT05G IHNwZWNpZmljIFlBTkcgbW9kdWxlcyBwb3N0ZWQNCiAgRG9uZSAgICAgLSBXR0xDIGZvciBOQUNN IGRvY3VtZW50DQogIERvbmUgICAgIC0gV0dMQyBmb3IgTkVUQ09ORiBzcGVjaWZpYyBub3RpZmlj YXRpb25zIGRvY3VtZW50DQogIERvbmUgICAgIC0gc3VibWl0IE5BQ00gZG9jdW1lbnQgdG8gSUVT RyBmb3IgY29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KICBEb25lICAgICAtIHN1 Ym1pdCBORVRDT05GIHNwZWNpZmljIG5vdGlmaWNhdGlvbnMgZG9jdW1lbnQgdG8gSUVTRyBmb3Ig Y29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KICBNYXkgMjAxMyAtIFN1Ym1pdCBp bml0aWFsIFdHIGRvY3VtZW50IG9uIFJldmVyc2UgU1NIDQogIEp1bCAyMDEzIC0gV0dMQyBmb3Ig cmZjNTUzOWJpcw0KICBKdWwgMjAxMyAtIFdHTEMgZm9yIFJldmVyc2UgU1NIDQogIEF1ZyAyMDEz IC0gc3VibWl0IHJmYzU1MzliaXMgdG8gQUQvSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBQcm9w b3NlZCBTdGFuZGFyZA0KICBBdWcgMjAxMyAtIHN1Ym1pdCBTU0ggYmluZGluZyB0byBBRC9JRVNH IGZvciBjb25zaWRlcmF0aW9uIGFzIFByb3Bvc2VkIFN0YW5kYXJkDQoNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F80CD0ECDEMUMBX005nsnintr_-- From prvs=884060992f=balazs.lengyel@ericsson.com Wed May 8 07:26: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 825AF21F926E for ; Wed, 8 May 2013 07:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7KHUsI8wYJS for ; Wed, 8 May 2013 07:26:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B9B1721F930A for ; Wed, 8 May 2013 07:26:45 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-a7-518a60a4824c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 57.2E.01956.4A06A815; Wed, 8 May 2013 16:26:44 +0200 (CEST) Received: from [130.100.88.224] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 8 May 2013 16:26:44 +0200 Message-ID: <518A60A4.1020907@ericsson.com> Date: Wed, 8 May 2013 16:26:44 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: netconf@ietf.org References: <20130508061634.2410.68675.idtracker@ietfa.amsl.com> <20130508063355.GB61484@elstar.local> In-Reply-To: <20130508063355.GB61484@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKJMWRmVeSWpSXmKPExsUyM+Jvre6ShK5Ag/2nzS2mbrrN6sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7oytHZ0sBW3cFQtXXWBpYDzJ0cXIySEhYCLxfH0fM4QtJnHh 3nq2LkYuDiGBU4wS7w90MUE4qxklJq86yg5SxSugLfHn6zYWEJtFQEXi7J/XYDabgJHE1P7z YLaoQJTEv7e7GSHqBSVOznwCFhcREJE4uuEt2BxhAUeJxTsmsoHYQgJpElc/LAWzOYHmfG88 BdbLLGArcWHOdRYIW15i+9s5zBD1GhIPL/xlncAoMAvJillIWmYhaVnAyLyKkT03MTMnvdx8 EyMw1A5u+W2wg3HTfbFDjNIcLErivMlcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QD Y9piydNHVXf1Xvu+matDYRrPRRvX1WdfTPJrzL2bptouyvZI/uybwlnPvba8mP9hQp7O8jXT b3Ye33SRecOfkprdMnxay2aafo94tU7r30+P9KSIgmvzy/YmqC9wThSPFDrWU78xasnZ7UfY w3iPVdv3WZ/IZJR/PueZ8NOTorZzFYVE5rvsKlBiKc5INNRiLipOBACgbU8LCAIAAA== Subject: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 08 May 2013 14:26:52 -0000 Hello, How do you use candidate config with big, multiuser nodes? In these big nodes you can not lock the full running configuration for any reasonable time, as other operators might want to configure different parts of the nodes configuration. The normal operation would be 1) copy running to candidate 2) partially lock the running config (and the candidate config) to cover my interesting parts 3) edit the candidate 4) commit the candidate 5) release the locks There are multiple problems with this: A) if someone else updates another part of the configuration with perfectly OK and independent configuration, the commit operation overwrites these changes. While the locks might be partial, but the commit according to the RFC is global. This effectively rules out using the candidate configuration if you must allow parallel configuration by multiple users. Is this true? What do you do in your implementation to avoid this problem? On the CLI configure does not have to be exclusive, but do you have something similar on Netconf? B) If you don't have access rights to parts of the configuration you will not be allowed to commit. True? 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 Wed May 8 08:17: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 2E88E21F92BC for ; Wed, 8 May 2013 08:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 GN86TdSyYVdG for ; Wed, 8 May 2013 08:17:41 -0700 (PDT) Received: from mail-ia0-x233.google.com (mail-ia0-x233.google.com [IPv6:2607:f8b0:4001:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFB721F9113 for ; Wed, 8 May 2013 08:17:41 -0700 (PDT) Received: by mail-ia0-f179.google.com with SMTP id g4so2107349iae.10 for ; Wed, 08 May 2013 08:17:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=zSz46YwLvvAEq0QKPnT7umdl0Sqv4ospcN+iJ7AsX1k=; b=T4FW56cUG1wpWBZ6yOb5hJVm/kNlY0n9BqqaB/mX/fs//h0oEwP9qdoxFeDb5Dra/d mQd6zEW0/euK+Up+oF+pk6n5M0ovWO0uAGMR4OO33/xGeLpL+i5U+e6tUoDSdYD8akJg VxtPhAlOZ1EmKOp56p3RBg0kiwDV1MrRPVq/TZmyjrwoqrgp66lJyMWcMt6ONw3o2JvO xNxf/4QPqogtpHDd3RckAfg3cIFVMA0JomgATC6yimC2AdJd8YdYMx9AgFksoznOBHph bFWXsMm2f31oLFSlvurpJqRP2NUI2mbpSpxe7YuG4oq+KcUBtajaOFKHDwaFPYVArUOQ O0fg== MIME-Version: 1.0 X-Received: by 10.50.236.100 with SMTP id ut4mr5829685igc.86.1368026260828; Wed, 08 May 2013 08:17:40 -0700 (PDT) Received: by 10.231.125.202 with HTTP; Wed, 8 May 2013 08:17:40 -0700 (PDT) In-Reply-To: <518A60A4.1020907@ericsson.com> References: <20130508061634.2410.68675.idtracker@ietfa.amsl.com> <20130508063355.GB61484@elstar.local> <518A60A4.1020907@ericsson.com> Date: Wed, 8 May 2013 08:17:40 -0700 Message-ID: From: Andy Bierman To: Balazs Lengyel Content-Type: multipart/alternative; boundary=14dae9399de3520a6404dc366fae X-Gm-Message-State: ALoCoQnGqDOpWZIBmY3JGFZsGuYd6QZNJ1W+krv1f2x5yFt0aK8c/9iaewwO+2/ZCgg2PE4LCg/0 Cc: netconf@ietf.org Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 08 May 2013 15:17:42 -0000 --14dae9399de3520a6404dc366fae Content-Type: text/plain; charset=ISO-8859-1 Hi, The shared candidate config has known problems. The main problem is that a shared candidate doesn't work well with multiple writers. The candidate works well when a writer takes out global locks and holds them until the [confirmed] commit is done. Then the next writer can do the same. This probably isn't the definition of "shared" you had in mind. Concurrent transactions are way outside the scope of the standard. Andy On Wed, May 8, 2013 at 7:26 AM, Balazs Lengyel wrote: > Hello, > How do you use candidate config with big, multiuser nodes? > In these big nodes you can not lock the full running configuration for any > reasonable time, as other operators might want to configure different parts > of the nodes configuration. > The normal operation would be > 1) copy running to candidate > 2) partially lock the running config (and the candidate config) to cover > my interesting parts > 3) edit the candidate > 4) commit the candidate > 5) release the locks > > There are multiple problems with this: > A) if someone else updates another part of the configuration with > perfectly OK and independent configuration, the commit operation overwrites > these changes. While the locks might be partial, but the commit according > to the RFC is global. This effectively rules out using the candidate > configuration if you must allow parallel configuration by multiple users. > Is this true? > What do you do in your implementation to avoid this problem? > On the CLI configure does not have to be exclusive, but do you have > something similar on Netconf? > > B) If you don't have access rights to parts of the configuration you will > not be allowed to commit. True? > 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 > > ______________________________**_________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/**listinfo/netconf > --14dae9399de3520a6404dc366fae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The shared candidate config has known problems.
The main problem is that a shared candidate
doesn't wor= k well with multiple writers.

The candidate works = well when a writer takes out global locks and holds
them until the [confirmed] commit is done. =A0Then the next writer can=
do the same. =A0This probably isn't the definition of "= shared" you had in mind.

Concurrent transacti= ons are way outside the scope of the standard.


Andy

On Wed, May 8, 2013 at 7:26 AM, Balazs Lengyel <= balazs.len= gyel@ericsson.com> wrote:
Hello,
How do you use candidate config with big, multiuser nodes?
In these big nodes you can not lock the full running configuration for any = reasonable time, as other operators might want to configure different parts= of the nodes configuration.
The normal operation would be
1) copy running to candidate
2) partially lock the running config (and the candidate config) to cover my= interesting parts
3) edit the candidate
4) commit the candidate
5) release the locks

There are multiple problems with this:
A) if someone else updates another part of the configuration with perfectly= OK and independent configuration, the commit operation overwrites these ch= anges. While the locks might be partial, but the commit according to the = =A0RFC is global. This effectively rules out using the candidate configurat= ion if you must allow parallel configuration by multiple users.
Is this true?
What do you do in your implementation to avoid this problem?
On the CLI configure does not have to be exclusive, but do you have somethi= ng similar on Netconf?

B) If you don't have access rights to parts of the configuration you wi= ll not be allowed to commit. True?
regards Balazs

--
Balazs Lengyel =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ericsson Hungary= Ltd.
System Manager
ECN: 831 7320 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Tel: +36-1-437= -7320
Mobile: +36-70-330-7909 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: Balazs.Lengyel@ericsson.com=

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--14dae9399de3520a6404dc366fae-- From kwatsen@juniper.net Wed May 8 11:26:21 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 4967321F8506 for ; Wed, 8 May 2013 11:26:21 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, 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 VJrMhihVrOI3 for ; Wed, 8 May 2013 11:26:02 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 74C4E21F826B for ; Wed, 8 May 2013 11:26:02 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUYqYtfFTjfwHGkpMUv3iW2wxVeVcnyEL@postini.com; Wed, 08 May 2013 11:26:02 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 May 2013 11:23:31 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 8 May 2013 11:23:30 -0700 Received: from CO9EHSOBE026.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 May 2013 11:26:42 -0700 Received: from mail77-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE026.bigfish.com (10.236.130.89) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 May 2013 18:23:29 +0000 Received: from mail77-co9 (localhost [127.0.0.1]) by mail77-co9-R.bigfish.com (Postfix) with ESMTP id C0BDD20794 for ; Wed, 8 May 2013 18:23:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371Ic85ehd799h4015I62a3Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL18c673h8275bh8275dhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail77-co9 (localhost.localdomain [127.0.0.1]) by mail77-co9 (MessageSwitch) id 1368037367475861_19986; Wed, 8 May 2013 18:22:47 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.230]) by mail77-co9.bigfish.com (Postfix) with ESMTP id 70FE5140359; Wed, 8 May 2013 18:22:47 +0000 (UTC) Received: from CH1PRD0511HT003.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 May 2013 18:22:45 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.64]) by CH1PRD0511HT003.namprd05.prod.outlook.com ([10.255.159.38]) with mapi id 14.16.0293.003; Wed, 8 May 2013 18:22:39 +0000 From: Kent Watsen To: Andy Bierman , Balazs Lengyel Thread-Topic: [Netconf] Candidate config for big multiuser nodes - is it usable? Thread-Index: AQHOTBkF+nh3eWvT10+3IW6V2nm2jQ== Date: Wed, 8 May 2013 18:22:38 +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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CDB00C5E302D4kwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 08 May 2013 18:26:24 -0000 --_000_CDB00C5E302D4kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Balazs, Another solution is to define a capability for private candidate datastores= (per-session, not per-user). This is what a couple Juniper products do. = Recall, NETCONF is an extensible protocol, so Ericsson can define a proprie= tary capability for this. Alternatively, if interested, I'd be willing to = co-author an I-D with you, maybe it would get picked up by the WG=85 This is essentially the same as transactions Andy mentioned, only how it's = presented seems to be different. I like private candidate datastores more = only because it's more like existing NETCONF =96 even :confirmed-commit car= ries over=85 Thanks, Kent From: Andy Bierman > Date: Wednesday, May 8, 2013 11:17 AM To: Balazs Lengyel > Cc: NetConf > Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usa= ble? Hi, The shared candidate config has known problems. The main problem is that a shared candidate doesn't work well with multiple writers. The candidate works well when a writer takes out global locks and holds them until the [confirmed] commit is done. Then the next writer can do the same. This probably isn't the definition of "shared" you had in min= d. Concurrent transactions are way outside the scope of the standard. Andy On Wed, May 8, 2013 at 7:26 AM, Balazs Lengyel > wrote: Hello, How do you use candidate config with big, multiuser nodes? In these big nodes you can not lock the full running configuration for any = reasonable time, as other operators might want to configure different parts= of the nodes configuration. The normal operation would be 1) copy running to candidate 2) partially lock the running config (and the candidate config) to cover my= interesting parts 3) edit the candidate 4) commit the candidate 5) release the locks There are multiple problems with this: A) if someone else updates another part of the configuration with perfectly= OK and independent configuration, the commit operation overwrites these ch= anges. While the locks might be partial, but the commit according to the R= FC is global. This effectively rules out using the candidate configuration = if you must allow parallel configuration by multiple users. Is this true? What do you do in your implementation to avoid this problem? On the CLI configure does not have to be exclusive, but do you have somethi= ng similar on Netconf? B) If you don't have access rights to parts of the configuration you will n= ot be allowed to commit. True? 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 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_CDB00C5E302D4kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7AE1239243E51340BD0B0B326E585C20@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Hi Balazs, 

Another solution is to define a capability for private candidate = datastores (per-session, not per-user).  This is what a couple Juniper= products do.  Recall, NETCONF is an extensible protocol, so Ericsson = can define a proprietary capability for this.  Alternatively, if interested, I'd be willing to co-author an I-D with you, maybe it would= get picked up by the WG=85

This is essentially the same as transactions Andy mentioned, only how = it's presented seems to be different.  I like private candidate datast= ores more only because it's more like existing NETCONF =96 even :confirmed-= commit carries over=85

Thanks,
Kent




From: Andy Bierman <andy@yumaworks.com>
Date: Wednesday, May 8, 2013 11:17 = AM
To: Balazs Lengyel <balazs.lengyel@ericsson.com>
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Candidate co= nfig for big multiuser nodes - is it usable?

Hi,

The shared candidate config has known problems.
The main problem is that a shared candidate
doesn't work well with multiple writers.

The candidate works well when a writer takes out global locks and hold= s
them until the [confirmed] commit is done.  Then the next writer = can
do the same.  This probably isn't the definition of "shared&= quot; you had in mind.

Concurrent transactions are way outside the scope of the standard.


Andy

On Wed, May 8, 2013 at 7:26 AM, Balazs Lengyel <= span dir=3D"ltr"> <balazs= .lengyel@ericsson.com> wrote:
Hello,
How do you use candidate config with big, multiuser nodes?
In these big nodes you can not lock the full running configuration for any = reasonable time, as other operators might want to configure different parts= of the nodes configuration.
The normal operation would be
1) copy running to candidate
2) partially lock the running config (and the candidate config) to cover my= interesting parts
3) edit the candidate
4) commit the candidate
5) release the locks

There are multiple problems with this:
A) if someone else updates another part of the configuration with perfectly= OK and independent configuration, the commit operation overwrites these ch= anges. While the locks might be partial, but the commit according to the &n= bsp;RFC is global. This effectively rules out using the candidate configuration if you must allow parallel configura= tion by multiple users.
Is this true?
What do you do in your implementation to avoid this problem?
On the CLI configure does not have to be exclusive, but do you have somethi= ng similar on Netconf?

B) If you don't have access rights to parts of the configuration you will n= ot be allowed to commit. True?
regards Balazs

--
Balazs Lengyel                 &nbs= p;     Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                  = ;      Tel: +36-1-437-7320
Mobile: +36-70-330-7909              = ;email: Balazs.Lengyel@ericsson.com

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--_000_CDB00C5E302D4kwatsenjunipernet_-- From internet-drafts@ietf.org Fri May 10 13:33: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 6058F21F918C; Fri, 10 May 2013 13:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, 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 24NmIaRcjYYc; Fri, 10 May 2013 13:33:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2221F910D; Fri, 10 May 2013 13:33:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130510203302.28487.41689.idtracker@ietfa.amsl.com> Date: Fri, 10 May 2013 13:33:02 -0700 Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 20:33:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration Working Group of th= e IETF. Title : Using the NETCONF Protocol over Transport Layer Security= (TLS) Author(s) : Mohamad Badra Alan Luchuk Juergen Schoenwaelder Filename : draft-ietf-netconf-rfc5539bis-03.txt Pages : 22 Date : 2013-05-10 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Security (TLS) protocol to secure the exchange of NETCONF messages. This document obsoletes RFC 5539. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From j.schoenwaelder@jacobs-university.de Fri May 10 13:43: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 BFE3D21F92F5 for ; Fri, 10 May 2013 13:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.163 X-Spam-Level: X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.086, 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 WySnWuBGRTHQ for ; Fri, 10 May 2013 13:43:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF0621F92EC for ; Fri, 10 May 2013 13:43:50 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1AC5D20BF6; Fri, 10 May 2013 22:43:48 +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 BFbLa6qjSFNO; Fri, 10 May 2013 22:43:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8856420BE3; Fri, 10 May 2013 22:43:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D894261D210; Fri, 10 May 2013 22:43:43 +0200 (CEST) Date: Fri, 10 May 2013 22:43:43 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20130510204343.GB73304@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Netconf] draft-ietf-netconf-rfc5539bis-03.txt 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: Fri, 10 May 2013 20:43:55 -0000 Hi, I have posted a new revision - here is the summary of the changes: A.1. draft-ietf-netconf-rfc5539bis-03 o Added support for call home (allocation of a new port number, rewrote text to allow a NETCONF client to be a TLS server and a NETCONF server to be a TLS client). o Merged sections 2 and 3 into a new section 2 and restructured the text. o Extended the IANA considerations section. o Using the cert-to-name mapping grouping from the SNMP configuration data model and updated the examples. o Creating an extensible set of YANG (sub)modules for NETCONF following the (sub)module structure of the SNMP configuration model. The call home support is still somewhat incomplete and we continue working on that (e.g., we may want to configure where to call home, which credentials to use, and the policy used to call home). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jbardgett@hotmail.com Sat May 11 12:20: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 041BF21F8BC0 for ; Sat, 11 May 2013 12:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 vZmxa7zg0W7H for ; Sat, 11 May 2013 12:19:57 -0700 (PDT) Received: from blu0-omc1-s12.blu0.hotmail.com (blu0-omc1-s12.blu0.hotmail.com [65.55.116.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2F87721F8B9C for ; Sat, 11 May 2013 12:19:57 -0700 (PDT) Received: from BLU168-W59 ([65.55.116.8]) by blu0-omc1-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 May 2013 12:19:56 -0700 X-EIP: [a2ajuPoENxUWQypFIdvRHIw0FUcl2BZ8] X-Originating-Email: [jbardgett@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_15382750-e851-431f-87fc-6bc7a5cebf5f_" From: jim bardgett To: "netconf@ietf.org" Date: Sat, 11 May 2013 15:19:56 -0400 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 11 May 2013 19:19:56.0339 (UTC) FILETIME=[85861030:01CE4E7C] Subject: [Netconf] help 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, 11 May 2013 19:20:02 -0000 --_15382750-e851-431f-87fc-6bc7a5cebf5f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: netconf-request@ietf.org > Subject: Netconf Digest=2C Vol 63=2C Issue 4 > To: netconf@ietf.org > Date: Sat=2C 11 May 2013 12:00:05 -0700 >=20 > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so=2C go to=20 >=20 > https://www.ietf.org/mailman/listinfo/netconf >=20 > Click the 'Unsubscribe or edit options' button=2C log in=2C and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send Netconf mailing list submissions to > netconf@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web=2C visit > https://www.ietf.org/mailman/listinfo/netconf > or=2C via email=2C send a message with subject or body 'help' to > netconf-request@ietf.org >=20 > You can reach the person managing the list at > netconf-owner@ietf.org >=20 > When replying=2C please edit your Subject line so it is more specific > than "Re: Contents of Netconf digest..." >=20 >=20 > Today's Topics: >=20 > 1. I-D Action: draft-ietf-netconf-rfc5539bis-03.txt > (internet-drafts@ietf.org) > 2. draft-ietf-netconf-rfc5539bis-03.txt (Juergen Schoenwaelder) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Fri=2C 10 May 2013 13:33:02 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc5539bis-03.txt > Message-ID: <20130510203302.28487.41689.idtracker@ietfa.amsl.com> > Content-Type: text/plain=3B charset=3D"utf-8" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration Working Group of = the IETF. >=20 > Title : Using the NETCONF Protocol over Transport Layer Securi= ty (TLS) > Author(s) : Mohamad Badra > Alan Luchuk > Juergen Schoenwaelder > Filename : draft-ietf-netconf-rfc5539bis-03.txt > Pages : 22 > Date : 2013-05-10 >=20 > Abstract: > The Network Configuration Protocol (NETCONF) provides mechanisms to > install=2C manipulate=2C and delete the configuration of network devic= es. > This document describes how to use the Transport Layer Security (TLS) > protocol to secure the exchange of NETCONF messages. This document > obsoletes RFC 5539. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Fri=2C 10 May 2013 22:43:43 +0200 > From: Juergen Schoenwaelder > To: netconf@ietf.org > Subject: [Netconf] draft-ietf-netconf-rfc5539bis-03.txt > Message-ID: <20130510204343.GB73304@elstar.local> > Content-Type: text/plain=3B charset=3Dus-ascii >=20 > Hi=2C >=20 > I have posted a new revision - here is the summary of the changes: >=20 > A.1. draft-ietf-netconf-rfc5539bis-03 >=20 > o Added support for call home (allocation of a new port number=2C > rewrote text to allow a NETCONF client to be a TLS server and a > NETCONF server to be a TLS client). >=20 > o Merged sections 2 and 3 into a new section 2 and restructured the > text. >=20 > o Extended the IANA considerations section. >=20 > o Using the cert-to-name mapping grouping from the SNMP > configuration data model and updated the examples. >=20 > o Creating an extensible set of YANG (sub)modules for NETCONF > following the (sub)module structure of the SNMP configuration > model. >=20 > The call home support is still somewhat incomplete and we continue > working on that (e.g.=2C we may want to configure where to call home=2C > which credentials to use=2C and the policy used to call home). >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1=2C 28759 Bremen=2C Germany > Fax: +49 421 200 3103 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 > End of Netconf Digest=2C Vol 63=2C Issue 4 > ************************************** = --_15382750-e851-431f-87fc-6bc7a5cebf5f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>=3B From: netconf-request@ietf.org
>=3B Subject:= Netconf Digest=2C Vol 63=2C Issue 4
>=3B To: netconf@ietf.org
>= =3B Date: Sat=2C 11 May 2013 12:00:05 -0700
>=3B
>=3B If you hav= e received this digest without all the individual message
>=3B attachm= ents you will need to update your digest options in your list
>=3B sub= scription. To do so=2C go to
>=3B
>=3B https://www.ietf.org/ma= ilman/listinfo/netconf
>=3B
>=3B Click the 'Unsubscribe or edit = options' button=2C log in=2C and set "Get
>=3B MIME or Plain Text Dige= sts?" to MIME. You can set this option
>=3B globally for all the list= digests you receive at this point.
>=3B
>=3B
>=3B
>= =3B Send Netconf mailing list submissions to
>=3B netconf@ietf.org>=3B
>=3B To subscribe or unsubscribe via the World Wide Web=2C vi= sit
>=3B https://www.ietf.org/mailman/listinfo/netconf
>=3B or= =2C via email=2C send a message with subject or body 'help' to
>=3B n= etconf-request@ietf.org
>=3B
>=3B You can reach the person manag= ing the list at
>=3B netconf-owner@ietf.org
>=3B
>=3B When= replying=2C please edit your Subject line so it is more specific
>=3B= than "Re: Contents of Netconf digest..."
>=3B
>=3B
>=3B T= oday's Topics:
>=3B
>=3B 1. I-D Action: draft-ietf-netconf-rf= c5539bis-03.txt
>=3B (internet-drafts@ietf.org)
>=3B 2. = draft-ietf-netconf-rfc5539bis-03.txt (Juergen Schoenwaelder)
>=3B
= >=3B
>=3B ---------------------------------------------------------= -------------
>=3B
>=3B Message: 1
>=3B Date: Fri=2C 10 May= 2013 13:33:02 -0700
>=3B From: internet-drafts@ietf.org
>=3B To:= i-d-announce@ietf.org
>=3B Cc: netconf@ietf.org
>=3B Subject: [N= etconf] I-D Action: draft-ietf-netconf-rfc5539bis-03.txt
>=3B Message-= ID: <=3B20130510203302.28487.41689.idtracker@ietfa.amsl.com>=3B
>= =3B Content-Type: text/plain=3B charset=3D"utf-8"
>=3B
>=3B
= >=3B A New Internet-Draft is available from the on-line Internet-Drafts d= irectories.
>=3B This draft is a work item of the Network Configurati= on Working Group of the IETF.
>=3B
>=3B Title : Using= the NETCONF Protocol over Transport Layer Security (TLS)
>=3B Author= (s) : Mohamad Badra
>=3B Alan Luchuk>=3B Juergen Schoenwaelder
>=3B Filenam= e : draft-ietf-netconf-rfc5539bis-03.txt
>=3B Pages = : 22
>=3B Date : 2013-05-10
>=3B
>=3B Abstract:=
>=3B The Network Configuration Protocol (NETCONF) provides mechani= sms to
>=3B install=2C manipulate=2C and delete the configuration o= f network devices.
>=3B This document describes how to use the Tran= sport Layer Security (TLS)
>=3B protocol to secure the exchange of = NETCONF messages. This document
>=3B obsoletes RFC 5539.
>=3B=
>=3B
>=3B The IETF datatracker status page for this draft is:<= br>>=3B https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc5539bis>=3B
>=3B There's also a htmlized version available at:
>=3B = http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-03
>=3B
&= gt=3B A diff from the previous version is available at:
>=3B http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-rfc5539bis-03
>=3B
&g= t=3B
>=3B Internet-Drafts are also available by anonymous FTP at:
= >=3B ftp://ftp.ietf.org/internet-drafts/
>=3B
>=3B
>=3B =
>=3B ------------------------------
>=3B
>=3B Message: 2>=3B Date: Fri=2C 10 May 2013 22:43:43 +0200
>=3B From: Juergen Sc= hoenwaelder <=3Bj.schoenwaelder@jacobs-university.de>=3B
>=3B To: = netconf@ietf.org
>=3B Subject: [Netconf] draft-ietf-netconf-rfc5539bis= -03.txt
>=3B Message-ID: <=3B20130510204343.GB73304@elstar.local>= =3B
>=3B Content-Type: text/plain=3B charset=3Dus-ascii
>=3B
= >=3B Hi=2C
>=3B
>=3B I have posted a new revision - here is th= e summary of the changes:
>=3B
>=3B A.1. draft-ietf-netconf-rfc= 5539bis-03
>=3B
>=3B o Added support for call home (allocati= on of a new port number=2C
>=3B rewrote text to allow a NETCONF = client to be a TLS server and a
>=3B NETCONF server to be a TLS = client).
>=3B
>=3B o Merged sections 2 and 3 into a new sect= ion 2 and restructured the
>=3B text.
>=3B
>=3B o = Extended the IANA considerations section.
>=3B
>=3B o Using= the cert-to-name mapping grouping from the SNMP
>=3B configurat= ion data model and updated the examples.
>=3B
>=3B o Creatin= g an extensible set of YANG (sub)modules for NETCONF
>=3B follow= ing the (sub)module structure of the SNMP configuration
>=3B mod= el.
>=3B
>=3B The call home support is still somewhat incomplete= and we continue
>=3B working on that (e.g.=2C we may want to configur= e where to call home=2C
>=3B which credentials to use=2C and the polic= y used to call home).
>=3B
>=3B /js
>=3B
>=3B --
= >=3B Juergen Schoenwaelder Jacobs University Bremen gGmbH
&g= t=3B Phone: +49 421 200 3587 Campus Ring 1=2C 28759 Bremen=2C Germa= ny
>=3B Fax: +49 421 200 3103 <=3Bhttp://www.jacobs-univer= sity.de/>=3B
>=3B
>=3B
>=3B ----------------------------= --
>=3B
>=3B _______________________________________________
= >=3B Netconf mailing list
>=3B Netconf@ietf.org
>=3B https://ww= w.ietf.org/mailman/listinfo/netconf
>=3B
>=3B
>=3B End of = Netconf Digest=2C Vol 63=2C Issue 4
>=3B *****************************= *********
= --_15382750-e851-431f-87fc-6bc7a5cebf5f_-- From dglaser@glaserresearch.net Sun May 12 16: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 4B34421F8E6E for ; Sun, 12 May 2013 16:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, HTML_MESSAGE=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 w8cB3uHwwTzP for ; Sun, 12 May 2013 16:24:11 -0700 (PDT) Received: from atl4mhob04.myregisteredsite.com (atl4mhob04.myregisteredsite.com [209.17.115.42]) by ietfa.amsl.com (Postfix) with ESMTP id 690C621F871D for ; Sun, 12 May 2013 16:24:10 -0700 (PDT) Received: from mailpod1.hostingplatform.com ([10.30.71.114]) by atl4mhob04.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4CNO9M9016747 for ; Sun, 12 May 2013 19:24:09 -0400 Received: (qmail 1293 invoked by uid 0); 12 May 2013 23:24:09 -0000 Received: from unknown (HELO ?192.168.1.10?) (dglaser@glaserresearch.net@68.184.35.200) by 0 with ESMTPA; 12 May 2013 23:24:09 -0000 Message-ID: <519024BB.9030101@glaserresearch.net> Date: Sun, 12 May 2013 19:24:43 -0400 From: David Glaser User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: netconf@ietf.org Content-Type: multipart/alternative; boundary="------------050205000808000801010303" Subject: [Netconf] Test - please ignore X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 23:24:17 -0000 This is a multi-part message in MIME format. --------------050205000808000801010303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Testing my new membership. Pls ignore --------------050205000808000801010303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Testing my new membership.

Pls ignore
 --------------050205000808000801010303-- From wjhns1@hardakers.net Mon May 13 12:39: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 E2A6C21F8E2C for ; Mon, 13 May 2013 12:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.19 X-Spam-Level: X-Spam-Status: No, score=0.19 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MANGLED_TOOL=2.3, 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 c6oLwvnLYVBp for ; Mon, 13 May 2013 12:39:36 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3321F89A6 for ; Mon, 13 May 2013 12:39:35 -0700 (PDT) Received: from localhost (50-1-19-94.dsl.dynamic.sonic.net [50.1.19.94]) by mail.hardakers.net (Postfix) with ESMTPSA id 6D9382ABAF; Mon, 13 May 2013 12:38:51 -0700 (PDT) From: Wes Hardaker To: Kent Watsen References: Date: Mon, 13 May 2013 12:38:29 -0700 In-Reply-To: (Kent Watsen's message of "Wed, 8 May 2013 18:22:38 +0000") Message-ID: <0lvc6mhdqi.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 13 May 2013 19:39:42 -0000 Kent Watsen writes: > Another solution is to define a capability for private candidate > datastores (per-session, not per-user). This is what a couple Juniper > products do. Recall, NETCONF is an extensible protocol, so Ericsson > can define a proprietary capability for this. Alternatively, if > interested, I'd be willing to co-author an I-D with you, maybe it > would get picked up by the WG=E2=80=A6 That's definitely better in terms of making sure you don't stomp each other during editing, but it still lets you accidentally wipe out changes that other operators made because of when you started. Consider the following time table: | time | operator 1 | operator 2 = | |------+-----------------------------+-----------------------------------= --| | T0 | copies running to O1-config | = | | T1 | | copies running to O2-config = | | T2 | Modifies O1-config.foo | Modifies O2-config.bar = | | T3 | Commits O1-config | = | | T4 | | Commits O2-config = | | | | (which drops the O1-config.foo mod= ) | Netconf's commit/copy mechanisms between global copies aren't safe for multi-user use. So make sure you lock running during the copy-away and back. You need some mechanism to signal that you need to be the only writer for a while. But that should work as long as you're noting doing so many config changes at once that users will need to wait a long time. Note, though, that with the copy-to/from-URL URL feature you can already have separate candidate configs essentially. You don't need a vendor-feature to achieve it (though you may want to anyway). --=20 Wes Hardaker Parsons From andy@yumaworks.com Mon May 13 13:45:26 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD221F8FB6 for ; Mon, 13 May 2013 13:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.923 X-Spam-Level: X-Spam-Status: No, score=0.923 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MANGLED_TOOL=2.3, 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 7b9rRc8iN4zU for ; Mon, 13 May 2013 13:45:25 -0700 (PDT) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id B160E21F9003 for ; Mon, 13 May 2013 13:45:25 -0700 (PDT) Received: by mail-ia0-f176.google.com with SMTP id j38so7867694iad.35 for ; Mon, 13 May 2013 13:45:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Z2G7HzF3DqNfIz8UqYjk5e1JU50Y3XzBZEXeC8wHxro=; b=VMlld4hXOLD6rINuyLSHAo2/qrsqXFPCqatMG7ENB4DhRhADHDQrpX1nJsLGfZzmgb ylrQ3lv1oVCi63vFgpv6zOlLa7JUxNHbuVni+NnYOIF1NKKzkpnjwybkg0LMxwy/liPH QpudPkfx/sHXF36ADgNDBJcUKbb4wHmlyOd+mU+dYWwJv31d+vMzxmqIJ6mSh3xxizzT AbsnHFd1gB5sAVPkWUqjHDc/XqDEQvtIvCBeLqQlpkbZi4ai3bjKkTNeUEOIRQWInqnL juXo4WGPP8CZ/glBFvHNk3YVOHy8WI9vbX0e3n3iKeeVUeX5fZ94sTHaSngg8Q7w72l6 atAw== MIME-Version: 1.0 X-Received: by 10.50.62.14 with SMTP id u14mr11016437igr.41.1368477924945; Mon, 13 May 2013 13:45:24 -0700 (PDT) Received: by 10.231.72.72 with HTTP; Mon, 13 May 2013 13:45:24 -0700 (PDT) In-Reply-To: <0lvc6mhdqi.fsf@wjh.hardakers.net> References: <0lvc6mhdqi.fsf@wjh.hardakers.net> Date: Mon, 13 May 2013 13:45:24 -0700 Message-ID: From: Andy Bierman To: Wes Hardaker Content-Type: multipart/alternative; boundary=047d7bdca6189986db04dc9f98bf X-Gm-Message-State: ALoCoQnZhf+bUHnMT/BCZtdQjI3r2m2Cf1UZlwQNZhn1s0Jf8KTO0JW1NumVCOc4QUyQBYjFFkvj Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 13 May 2013 20:45:26 -0000 --047d7bdca6189986db04dc9f98bf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2013 at 12:38 PM, Wes Hardaker wrote= : > Kent Watsen writes: > > > Another solution is to define a capability for private candidate > > datastores (per-session, not per-user). This is what a couple Juniper > > products do. Recall, NETCONF is an extensible protocol, so Ericsson > > can define a proprietary capability for this. Alternatively, if > > interested, I'd be willing to co-author an I-D with you, maybe it > > would get picked up by the WG=85 > > That's definitely better in terms of making sure you don't stomp each > other during editing, but it still lets you accidentally wipe out > changes that other operators made because of when you started. Consider > the following time table: > > | time | operator 1 | operator 2 > | > > |------+-----------------------------+-----------------------------------= --| > | T0 | copies running to O1-config | > | > | T1 | | copies running to O2-config > | > | T2 | Modifies O1-config.foo | Modifies O2-config.bar > | > | T3 | Commits O1-config | > | > | T4 | | Commits O2-config > | > | | | (which drops the O1-config.foo > mod) | > > Netconf's commit/copy mechanisms between global copies aren't safe for > multi-user use. So make sure you lock running during the copy-away and > back. You need some mechanism to signal that you need to be the only > writer for a while. But that should work as long as you're noting doing > so many config changes at once that users will need to wait a long time. > > Note, though, that with the copy-to/from-URL URL feature you can already > have separate candidate configs essentially. You don't need a > vendor-feature to achieve it (though you may want to anyway). > There are ways for the server to figure out that this is not a collision. If they both wrote config.bar, that would be a collision. The transaction commit procedure does not exactly follow RFC 6241 or else the deletion of edits from other clients would occur. It's basically the same except the server keeps track of the changed data, etc. > > -- > Wes Hardaker > Parsons > Andy --047d7bdca6189986db04dc9f98bf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2013 at 12:38 PM, Wes Ha= rdaker <wjhns1@hardakers.net> wrote:
Kent Watsen <kwatsen@juniper.net<= /a>> writes:

> Another solution is to define a capability for private candidate
> datastores (per-session, not per-user). =A0This is what a couple Junip= er
> products do. =A0Recall, NETCONF is an extensible protocol, so Ericsson=
> can define a proprietary capability for this. =A0Alternatively, if
> interested, I'd be willing to co-author an I-D with you, maybe it<= br> > would get picked up by the WG=85

That's definitely better in terms of making sure you don't stomp ea= ch
other during editing, but it still lets you accidentally wipe out
changes that other operators made because of when you started. =A0Consider<= br> the following time table:

=A0 | time | operator 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| operator 2 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 |------+-----------------------------+---------------------------------= ----|
=A0 | T0 =A0 | copies running to O1-config | =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 | T1 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | co= pies running to O2-config =A0 =A0 =A0 =A0 |
=A0 | T2 =A0 | Modifies O1-config.foo =A0 =A0 =A0| Modifies O2-config.bar = =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 | T3 =A0 | Commits O1-config =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 | T4 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Co= mmits O2-config =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 | =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = | (which drops the O1-config.foo mod) |

Netconf's commit/copy mechanisms between global copies aren't safe = for
multi-user use. =A0So make sure you lock running during the copy-away and back. =A0You need some mechanism to signal that you need to be the only
writer for a while. =A0But that should work as long as you're noting do= ing
so many config changes at once that users will need to wait a long time.
Note, though, that with the copy-to/from-URL URL feature you can already have separate candidate configs essentially. =A0You don't need a
vendor-feature to achieve it (though you may want to anyway).

There are ways for the server to figure out that thi= s is not a collision.
If they both wrote config.bar, that would b= e a collision. =A0The transaction
commit procedure does not exactly follow RFC 6241 or else the deletion=
of edits from other clients would occur. =A0It's basically t= he same except
the server keeps track of the changed data, etc.

=A0

--
Wes Hardaker
Parsons

Andy

--047d7bdca6189986db04dc9f98bf-- From kwatsen@juniper.net Mon May 13 15:46: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 D056821F9239 for ; Mon, 13 May 2013 15:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.867 X-Spam-Level: X-Spam-Status: No, score=-2.867 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, 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 gcm5A+nY3n3I for ; Mon, 13 May 2013 15:46:35 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2644121F9409 for ; Mon, 13 May 2013 15:46:35 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUZFtSkUfKOpTxDKHCirysrpeK5j9DNNm@postini.com; Mon, 13 May 2013 15:46:35 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 May 2013 15:42:07 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 13 May 2013 15:42:07 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.186) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 13 May 2013 15:45:07 -0700 Received: from mail1-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Mon, 13 May 2013 22:42:06 +0000 Received: from mail1-co1 (localhost [127.0.0.1]) by mail1-co1-R.bigfish.com (Postfix) with ESMTP id 51922160680 for ; Mon, 13 May 2013 22:42:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -2 X-BigFish: PS-2(zz1432Id799h4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz8275bhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail1-co1 (localhost.localdomain [127.0.0.1]) by mail1-co1 (MessageSwitch) id 1368484924858011_26826; Mon, 13 May 2013 22:42:04 +0000 (UTC) Received: from CO1EHSMHS001.bigfish.com (unknown [10.243.78.254]) by mail1-co1.bigfish.com (Postfix) with ESMTP id CE6AA6C0048; Mon, 13 May 2013 22:42:04 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by CO1EHSMHS001.bigfish.com (10.243.66.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 13 May 2013 22:42:04 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.64]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0293.003; Mon, 13 May 2013 22:42:03 +0000 From: Kent Watsen To: Andy Bierman , Wes Hardaker Thread-Topic: [Netconf] Candidate config for big multiuser nodes - is it usable? Thread-Index: AQHOTBkF+nh3eWvT10+3IW6V2nm2jZkDi0JegAASIQD//92GAA== Date: Mon, 13 May 2013 22:42:02 +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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <2230731C7159154590CF1E6FCFEA9F8D@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%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HARDAKERS.NET$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 13 May 2013 22:46:41 -0000 From: Andy Bierman > There are ways for the server to figure out that this is not a collision. > If they both wrote config.bar, that would be a collision. The >transaction > commit procedure does not exactly follow RFC 6241 or else the deletion > of edits from other clients would occur. It's basically the same except > the server keeps track of the changed data, etc. =20 Exactly, the from the 2nd client could return an indicating that a conflict was detected, so the 2nd client can retry after resynchronizing itself to the device's new configuration. Thanks, Kent From mehmet.ersue@nsn.com Tue May 14 01:40: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 AF97621F8C1A for ; Tue, 14 May 2013 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJgaAnMSoL6v for ; Tue, 14 May 2013 01:40:46 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0623F21F8F83 for ; Tue, 14 May 2013 01:40:45 -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 r4E8ei4I020427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 14 May 2013 10:40:44 +0200 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r4E8efT2008601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 14 May 2013 10:40:44 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 14 May 2013 10:40:41 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.156]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Tue, 14 May 2013 10:40:41 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence Thread-Index: AQHOUCCmBLbvJmEKmEyg4la0xaxgjpkEWxpA Date: Tue, 14 May 2013 08:40:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] 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: 4219 X-purgate-ID: 151667::1368520844-000076D0-B10173F8/0-0/0-0 Subject: [Netconf] FW: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence 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, 14 May 2013 08:40:51 -0000 Please consider volunteering to NomCom 2013-2014.=20 This is an essential opportunity to contribute to the IETF and help to=20 select the appropriate people for the open positions listed below. Cheers,=20 Mehmet=20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of ext Mankin, Allison Sent: Monday, May 13, 2013 11:27 PM To: ietf-announce@ietf.org Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first se= ntence The IETF nominating committee (nomcom) process for 2013-14 has begun. The=20 IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y random way from a pool of volunteers. The more volunteers, the better chanc= e we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. =20 =20 Volunteers must have attended 3 of the past 5 IETF meetings. As specified = in RFC 3777, that means three out of the five past meetings up to the time thi= s email announcement goes out to start the solicitation of volunteers. The fi= ve meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86. If you qualify, please volunteer. However, much as we want this, before yo= u=20 decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. =20 =20 The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect=20 requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to=20 candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)= =20 June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: =20 // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] =20 =20 // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF!=20 I will be publishing a more detailed target timetable, as well as details=20 of the randomness seeds to be used for the RFC 3797 selection process,=20 within the next couple weeks. =20 Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the=20 address given.=20 From wjhns1@hardakers.net Tue May 14 06:27: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 B0D9921F8F32 for ; Tue, 14 May 2013 06:27:32 -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 ElbjMX0kaIUc for ; Tue, 14 May 2013 06:27:27 -0700 (PDT) Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4F10421F8203 for ; Tue, 14 May 2013 06:27:27 -0700 (PDT) Received: from localhost (wjh.hardakers.net [IPv6:2001:470:1f00:187:f2de:f1ff:fee6:e6e8]) by mail.hardakers.net (Postfix) with ESMTPSA id 330382AA0C; Tue, 14 May 2013 06:27:23 -0700 (PDT) From: Wes Hardaker To: Kent Watsen References: Date: Tue, 14 May 2013 06:27:23 -0700 In-Reply-To: (Kent Watsen's message of "Mon, 13 May 2013 22:42:02 +0000") Message-ID: <0l38tpu1xg.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 13:27:32 -0000 Kent Watsen writes: > Exactly, the from the 2nd client could return an > indicating that a conflict was detected, so the 2nd client can retry after > resynchronizing itself to the device's new configuration. But that's not something that is standardized. And it throws into question whether operator1 actually wanted to revert operator2's changes in the first place. Yes, there are many hacks you can (and maybe some do) put in place to detect, track, etc these changes. But how is a management station framework supposed to be written based on the protocol itself? Is it supposed to detect that this device is a FooBar version 2, which does conflict detection? I sure hope those features are advertised in the hello exchange. This just smells like a need for standardization before it gets out of hand if different companies are taking different approaches about what to do in the case of conflicts. -- Wes Hardaker Parsons From andy@yumaworks.com Tue May 14 06:48: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 3EF9E21F90AC for ; Tue, 14 May 2013 06:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 VTBFgwDLDaXv for ; Tue, 14 May 2013 06:48:31 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8267B21F905F for ; Tue, 14 May 2013 06:48:30 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so1014862ief.40 for ; Tue, 14 May 2013 06:48:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=c3PR34WC5s/VjsrOpRCaTe7NwQAhDpaAVAqNs0IUXuM=; b=chxLqYex26qLzzpEHDmv63eO8HzVq75h4PhFdpRaLqEblNMRtUaJ8C6fHy7MXQ8m9o nvk8iFN+6a5emVP8KC7VMJzxEOzoFbmVgqcDEYv3SY7R0MItSqGsNawhHTfULlqnZ0So qCchmIOJd9Hz7djDVFB0w79BvpvDwrOc9f/I/tea8q1tEIIuY80mlqEiG5YKXIt1Gf7C PdmA7l4UsfEE7bu+WQpDmrsDUD508QQg3tPc0rAqU9YhI0P3l7yvneqhlNxcXUchwX9J k2qGEAo6W8CU4wC6XgMsDEoutPb8maF7EFT/Qe4abAs4MeXgKYk4d8zPnrg+UAXwsvkh kMxA== MIME-Version: 1.0 X-Received: by 10.50.102.67 with SMTP id fm3mr2211649igb.5.1368539310241; Tue, 14 May 2013 06:48:30 -0700 (PDT) Received: by 10.231.206.71 with HTTP; Tue, 14 May 2013 06:48:30 -0700 (PDT) In-Reply-To: <0l38tpu1xg.fsf@wjh.hardakers.net> References: <0l38tpu1xg.fsf@wjh.hardakers.net> Date: Tue, 14 May 2013 06:48:30 -0700 Message-ID: From: Andy Bierman To: Wes Hardaker Content-Type: multipart/alternative; boundary=047d7b10ca1372cd9804dcade354 X-Gm-Message-State: ALoCoQmEFu6e235vOkIIZVw9nFO4xVOz4XNdRki5mDqNeLdWoTCSpFiqlUB6dmfghYUMRvu9HrmS Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 13:48:32 -0000 --047d7b10ca1372cd9804dcade354 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 6:27 AM, Wes Hardaker wrote: > Kent Watsen writes: > > > Exactly, the from the 2nd client could return an > > indicating that a conflict was detected, so the 2nd client can retry > after > > resynchronizing itself to the device's new configuration. > > But that's not something that is standardized. And it throws into > question whether operator1 actually wanted to revert operator2's changes > in the first place. > If operator1 wants to delete /foo, then an explicit edit within their transaction is required. The reason shared candidate is useless for multiple writers is that there are implicit actions all over the place. - a missing node is an implicit delete - an unchanged user-ordered list becomes an implicit request to re-order the list - a commit operation implicitly acts as the confirming commit for another operator's changes Collision detection works better if you compare only explicit changes. > > Yes, there are many hacks you can (and maybe some do) put in place to > detect, track, etc these changes. But how is a management station > framework supposed to be written based on the protocol itself? Is it > supposed to detect that this device is a FooBar version 2, which does > conflict detection? I sure hope those features are advertised in the > hello exchange. > If a request fails, the client gets an back. It's not as if the handful of standard operations and data in NETCONF somehow eliminated the need for vendor-specific features. > This just smells like a need for standardization before it gets out of > hand if different companies are taking different approaches about what > to do in the case of conflicts. > I don't see any problem with vendors figuring out what works best. Concurrent transactions are fairly worthless if the minute you start using them, first writer wins and everything else is rejected. The NETCONF WG is busy working on other things anyway. -- > Wes Hardaker > Parsons > Andy --047d7b10ca1372cd9804dcade354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2013 at 6:27 AM, Wes Har= daker <wjhns1@hardakers.net> wrote:
Kent Watsen <kwatsen@juniper.net<= /a>> writes:

> Exactly, the <commit> from the 2nd client could return an <rp= c-error>
> indicating that a conflict was detected, so the 2nd client can retry a= fter
> resynchronizing itself to the device's new configuration.

But that's not something that is standardized. =A0And it throws into question whether operator1 actually wanted to revert operator2's change= s
in the first place.


all over the place.
=A0 - a missing node is an implicit dele= te
=A0 - an unchanged user-ordered list becomes an implicit
=
=A0 =A0 request to re-order the list
=A0 - a commit operatio= n implicitly acts as the confirming commit
=A0 =A0 for another operator's changes

Co= llision detection works better if you compare only explicit changes.
<= div>=A0

Yes, there are many hacks you can (and maybe some do) put in place to
detect, track, etc these changes. =A0But how is a management station
framework supposed to be written based on the protocol itself? =A0Is it
supposed to detect that this device is a FooBar version 2, which does
conflict detection? =A0I sure hope those features are advertised in the
hello exchange.



This just smells like a need for standardization before it gets out of
hand if different companies are taking different approaches about what
to do in the case of conflicts.

I don&#= 39;t see any problem with vendors figuring out what works best.
C= oncurrent transactions are fairly worthless if the minute you start
using them, first writer wins and everything else is rejected.
The NETCONF WG is busy working on other things anyway.

Andy

--047d7b10ca1372cd9804dcade354-- From xiangli@seguesoft.com Tue May 14 07:04: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 7EC0121F901D for ; Tue, 14 May 2013 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 LExKYkWftTYX for ; Tue, 14 May 2013 07:03:55 -0700 (PDT) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id AF4B921F9049 for ; Tue, 14 May 2013 07:03:54 -0700 (PDT) Received: from [192.168.2.16] ([98.212.151.151]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id bq3s1l00E3GEayi01q3shy; Tue, 14 May 2013 07:03:54 -0700 Message-ID: <51924449.8000900@seguesoft.com> Date: Tue, 14 May 2013 09:03:53 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: netconf@ietf.org References: <0l38tpu1xg.fsf@wjh.hardakers.net> In-Reply-To: <0l38tpu1xg.fsf@wjh.hardakers.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 14:04:03 -0000 On 5/14/2013 8:27 AM, Wes Hardaker wrote: > Kent Watsen writes: > >> Exactly, the from the 2nd client could return an >> indicating that a conflict was detected, so the 2nd client can retry after >> resynchronizing itself to the device's new configuration. > But that's not something that is standardized. And it throws into > question whether operator1 actually wanted to revert operator2's changes > in the first place. agreed > Yes, there are many hacks you can (and maybe some do) put in place to > detect, track, etc these changes. But how is a management station > framework supposed to be written based on the protocol itself? Is it > supposed to detect that this device is a FooBar version 2, which does > conflict detection? I sure hope those features are advertised in the > hello exchange. > This just smells like a need for standardization before it gets out of > hand if different companies are taking different approaches about what > to do in the case of conflicts. +1 Without this clarified/standardized, a client must first lock candidate during the whole process of editing candidate/committing, otherwise things won't work as expected when there are multiple clients competing editing. That might well work in the real word and perhaps it is the intended way? Because RFC6241 says: The candidate configuration can be shared among multiple sessions. Unless a client has specific information that the candidate configuration is not shared, it MUST assume that other sessions are able to modify the candidate configuration at the same time. It is therefore prudent for a client to lock the candidate configuration before modifying it. --Xiang From xiangli@seguesoft.com Tue May 14 07:11:21 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 81E3921F9029 for ; Tue, 14 May 2013 07:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=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 oRJhLiM4mjWz for ; Tue, 14 May 2013 07:11:16 -0700 (PDT) Received: from m1plsmtpa01-04.prod.mesa1.secureserver.net (m1plsmtpa01-04.prod.mesa1.secureserver.net [64.202.165.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF4AA21F901D for ; Tue, 14 May 2013 07:11:16 -0700 (PDT) Received: from [192.168.2.16] ([98.212.151.151]) by m1plsmtpa01-04.prod.mesa1.secureserver.net with id bqBB1l00V3GEayi01qBCBD; Tue, 14 May 2013 07:11:16 -0700 Message-ID: <51924601.2090504@seguesoft.com> Date: Tue, 14 May 2013 09:11:13 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: netconf@ietf.org References: <0l38tpu1xg.fsf@wjh.hardakers.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000709070900010403050002" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 14:11:21 -0000 This is a multi-part message in MIME format. --------------000709070900010403050002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/14/2013 8:48 AM, Andy Bierman wrote: > > > On Tue, May 14, 2013 at 6:27 AM, Wes Hardaker > wrote: > > Kent Watsen > writes: > > > Exactly, the from the 2nd client could return an > > > indicating that a conflict was detected, so the 2nd client can > retry after > > resynchronizing itself to the device's new configuration. > > But that's not something that is standardized. And it throws into > question whether operator1 actually wanted to revert operator2's > changes > in the first place. > > > > If operator1 wants to delete /foo, then an explicit edit > within their transaction is required. The reason shared candidate > is useless for multiple writers is that there are implicit actions > all over the place. > - a missing node is an implicit delete > - an unchanged user-ordered list becomes an implicit > request to re-order the list > - a commit operation implicitly acts as the confirming commit > for another operator's changes > > Collision detection works better if you compare only explicit changes. I could not find any texts in RFC6241 that require a server to do collision detection. We sure can make NETCONF server to do version control like CVS/SVN/Git but that's not how the current NETCONF is define , and whether we need that is IMO debatable. > > Yes, there are many hacks you can (and maybe some do) put in place to > detect, track, etc these changes. But how is a management station > framework supposed to be written based on the protocol itself? Is it > supposed to detect that this device is a FooBar version 2, which does > conflict detection? I sure hope those features are advertised in the > hello exchange. > > > If a request fails, the client gets an back. > It's not as if the handful of standard operations and data > in NETCONF somehow eliminated the need for vendor-specific features. > > > This just smells like a need for standardization before it gets out of > hand if different companies are taking different approaches about what > to do in the case of conflicts. > > > I don't see any problem with vendors figuring out what works best. > Concurrent transactions are fairly worthless if the minute you start > using them, first writer wins and everything else is rejected. +1 --Xiang > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/ --------------000709070900010403050002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 5/14/2013 8:48 AM, Andy Bierman wrote:


On Tue, May 14, 2013 at 6:27 AM, Wes Hardaker <wjhns1@hardakers.net> wrote:
Kent Watsen <kwatsen@juniper.net> writes:

> Exactly, the <commit> from the 2nd client could return an <rpc-error>
> indicating that a conflict was detected, so the 2nd client can retry after
> resynchronizing itself to the device's new configuration.

But that's not something that is standardized.  And it throws into
question whether operator1 actually wanted to revert operator2's changes
in the first place.


If operator1 wants to delete /foo, then an explicit edit
within their transaction is required.  The reason shared candidate
is useless for multiple writers is that there are implicit actions
all over the place.
  - a missing node is an implicit delete
  - an unchanged user-ordered list becomes an implicit
    request to re-order the list
  - a commit operation implicitly acts as the confirming commit
    for another operator's changes

Collision detection works better if you compare only explicit changes.

I could not  find any texts in RFC6241 that require a server to do collision
detection. 

We sure can make NETCONF server to do version control like CVS/SVN/Git but
that's not how the current NETCONF is define , and whether we need that is
IMO debatable.



Yes, there are many hacks you can (and maybe some do) put in place to
detect, track, etc these changes.  But how is a management station
framework supposed to be written based on the protocol itself?  Is it
supposed to detect that this device is a FooBar version 2, which does
conflict detection?  I sure hope those features are advertised in the
hello exchange.

If a request fails, the client gets an <rpc-error> back.
It's not as if the handful of standard operations and data
in NETCONF somehow eliminated the need for vendor-specific features.


This just smells like a need for standardization before it gets out of
hand if different companies are taking different approaches about what
to do in the case of conflicts.

I don't see any problem with vendors figuring out what works best.
Concurrent transactions are fairly worthless if the minute you start
using them, first writer wins and everything else is rejected.

+1


--Xiang


_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/
--------------000709070900010403050002-- From andy@yumaworks.com Tue May 14 07:22: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 2E9ED21F85C9 for ; Tue, 14 May 2013 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 iQvSq2Uaywyw for ; Tue, 14 May 2013 07:22:23 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9D721F852A for ; Tue, 14 May 2013 07:22:23 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so1137525ief.12 for ; Tue, 14 May 2013 07:22:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=9DZTUf3uonsq/2CgnlihiKgWTZG6vfp/tstYxtg45W0=; b=p3UJS3rATiXT3w06D1LNl2mKWQP35qBwkddDxaOnHuFZvo+FgeufzR/q6Dy0ItP1eo JB2pQm4BPUtWy3fUOBMuqgBuOrFnLbkX13WLvuTR7SMmUuInXSMSTe9Zt5wVt9i3dxS2 C6F2GgdDDt7+zCLzal6vTDela6hshd1vYd5TuHuJz91Wmg9WVVA29VDZxrAl8En0rq3c RER2b8AhvAcggNAR8M1zfPOYCI/LBJlgjZxbaIAjaZiMrbEiZYnV41k2vGpJR4YkCQhb ODZ6hi7HFP730P8kP0gHO2stUehjCbiJ4LwSIU3xKLWVFCWyJZ2wGKIji3UrJbc4+U1a ysPg== MIME-Version: 1.0 X-Received: by 10.42.30.8 with SMTP id t8mr17130130icc.43.1368541342756; Tue, 14 May 2013 07:22:22 -0700 (PDT) Received: by 10.231.206.71 with HTTP; Tue, 14 May 2013 07:22:22 -0700 (PDT) In-Reply-To: <51924601.2090504@seguesoft.com> References: <0l38tpu1xg.fsf@wjh.hardakers.net> <51924601.2090504@seguesoft.com> Date: Tue, 14 May 2013 07:22:22 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: multipart/alternative; boundary=20cf30426cae988ba504dcae5cb2 X-Gm-Message-State: ALoCoQmXs2fTc1daw6bClGBuYwT+Dgv7g1c2kehqvdCcxqPSF2TjJyVQc6gszDZojKQ9j1TiB21T Cc: netconf@ietf.org Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 14:22:24 -0000 --20cf30426cae988ba504dcae5cb2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 14, 2013 at 7:11 AM, Xiang Li wrote: > > On 5/14/2013 8:48 AM, Andy Bierman wrote: > > > > On Tue, May 14, 2013 at 6:27 AM, Wes Hardaker wrote: > >> Kent Watsen writes: >> >> > Exactly, the from the 2nd client could return an >> > indicating that a conflict was detected, so the 2nd client can retry >> after >> > resynchronizing itself to the device's new configuration. >> >> But that's not something that is standardized. And it throws into >> question whether operator1 actually wanted to revert operator2's changes >> in the first place. >> > > > If operator1 wants to delete /foo, then an explicit edit > within their transaction is required. The reason shared candidate > is useless for multiple writers is that there are implicit actions > all over the place. > - a missing node is an implicit delete > - an unchanged user-ordered list becomes an implicit > request to re-order the list > - a commit operation implicitly acts as the confirming commit > for another operator's changes > > Collision detection works better if you compare only explicit changes. > > > I could not find any texts in RFC6241 that require a server to do > collision > detection. > > We are talking about proprietary features, so not surprising that there is no text in RFC 6241 about it. It works like any other proprietary NETCONF extension. If the client understands the advertised capability and knows how to use it, then what's the problem? We sure can make NETCONF server to do version control like CVS/SVN/Git but > that's not how the current NETCONF is define , and whether we need that is > IMO debatable. > > These are implementation details. > >> Yes, there are many hacks you can (and maybe some do) put in place to >> detect, track, etc these changes. But how is a management station >> framework supposed to be written based on the protocol itself? Is it >> supposed to detect that this device is a FooBar version 2, which does >> conflict detection? I sure hope those features are advertised in the >> hello exchange. >> > > If a request fails, the client gets an back. > It's not as if the handful of standard operations and data > in NETCONF somehow eliminated the need for vendor-specific features. > > >> This just smells like a need for standardization before it gets out of >> hand if different companies are taking different approaches about what >> to do in the case of conflicts. >> > > I don't see any problem with vendors figuring out what works best. > Concurrent transactions are fairly worthless if the minute you start > using them, first writer wins and everything else is rejected. > > > +1 > > > --Xiang > > Andy --20cf30426cae988ba504dcae5cb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2013 at 7:11 AM, Xiang L= i <xiangli@seguesoft.com> wrote:
=20 =20 =20

On 5/14/2013 8:48 AM, Andy Bierman wrote:


On Tue, May 14, 2013 at 6:27 AM, Wes Hardaker <wjhns1@hardakers.net> wrote:
Kent Watsen <kwatsen@juniper.net> writes:

> Exactly, the <commit> from the 2nd client could return an <rpc-error>
> indicating that a conflict was detected, so the 2nd client can retry after
> resynchronizing itself to the device's new configuration= .

But that's not something that is standardized. =A0And it thro= ws into
question whether operator1 actually wanted to revert operator2's changes
in the first place.


If operator1 wants to delete /foo, then an explicit edit
within their transaction is required. =A0The reason shared candidate
is useless for multiple writers is that there are implicit actions
all over the place.
=A0 - a missing node is an implicit delete
=A0 - an unchanged user-ordered list becomes an implicit
=A0 =A0 request to re-order the list
=A0 - a commit operation implicitly acts as the confirming commit
=A0 =A0 for another operator's changes

Collision detection works better if you compare only explicit changes.

I could not=A0 find any texts in RFC6241 that require a server to do collision
detection.=A0


We are talking about proprie= tary features, so not surprising that
there is no text in RFC 624= 1 about it.=A0

It works like any other proprietary= NETCONF extension.
If the client understands the advertised capability and knows
how to use it, then what's the problem?


=
We sure can make NETCONF server to do version control like CVS/SVN/Git but
that's not how the current NETCONF is define , and whether we need that is
IMO debatable.


These are implementation det= ails.



Yes, there are many hacks you can (and maybe some do) put in place to
detect, track, etc these changes. =A0But how is a management station
framework supposed to be written based on the protocol itself? =A0Is it
supposed to detect that this device is a FooBar version 2, which does
conflict detection? =A0I sure hope those features are advertised in the
hello exchange.

If a request fails, the client gets an <rpc-error> back.
It's not as if the handful of standard operations and data=
in NETCONF somehow eliminated the need for vendor-specific features.


This just smells like a need for standardization before it gets out of
hand if different companies are taking different approaches about what
to do in the case of conflicts.

I don't see any problem with vendors figuring out what works best.
Concurrent transactions are fairly worthless if the minute you start
using them, first writer wins and everything else is rejected.

+1


--Xiang


Andy

--20cf30426cae988ba504dcae5cb2-- From kwatsen@juniper.net Tue May 14 10:30: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 AF74821F84A6 for ; Tue, 14 May 2013 10:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.167 X-Spam-Level: X-Spam-Status: No, score=-3.167 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 mIS58OLux493 for ; Tue, 14 May 2013 10:30:47 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8521F8442 for ; Tue, 14 May 2013 10:30:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKUZJ0xXrbnX/CusT318hrvaf4i29Jjqud@postini.com; Tue, 14 May 2013 10:30:46 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 14 May 2013 10:24:40 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 14 May 2013 10:24:40 -0700 Received: from CO9EHSOBE013.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 14 May 2013 10:35:34 -0700 Received: from mail152-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 May 2013 17:24:39 +0000 Received: from mail152-co9 (localhost [127.0.0.1]) by mail152-co9-R.bigfish.com (Postfix) with ESMTP id A11C5180368 for ; Tue, 14 May 2013 17:24:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zzc85eh4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz18c673h8275bhz2dh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1bceh1d0ch1d2eh1d3fh1155h) Received: from mail152-co9 (localhost.localdomain [127.0.0.1]) by mail152-co9 (MessageSwitch) id 136855227877993_13557; Tue, 14 May 2013 17:24:38 +0000 (UTC) Received: from CO9EHSMHS007.bigfish.com (unknown [10.236.132.246]) by mail152-co9.bigfish.com (Postfix) with ESMTP id 054D0200059; Tue, 14 May 2013 17:24:38 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS007.bigfish.com (10.236.130.17) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 May 2013 17:24:37 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.64]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0305.001; Tue, 14 May 2013 17:24:32 +0000 From: Kent Watsen To: Andy Bierman , Xiang Li Thread-Topic: [Netconf] Candidate config for big multiuser nodes - is it usable? Thread-Index: AQHOUMflMxQiWAHYTEuf+jVXJfz1sA== Date: Tue, 14 May 2013 17:24:32 +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.2.130206 x-originating-ip: [10.255.159.4] Content-Type: multipart/alternative; boundary="_000_CDB7E92D306F5kwatsenjunipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%YUMAWORKS.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%SEGUESOFT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 14 May 2013 17:30:57 -0000 --_000_CDB7E92D306F5kwatsenjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As Andy notes, this is a proprietary extension in Juniper's implementation = to get around some of the issues in NETCONF's shared candidate model. Ther= e is no standard yet, but I'm willing to submit an I-D and see if there is = any WG interest=85 Thanks, Kent --_000_CDB7E92D306F5kwatsenjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <668A5AB643ABD24B98D928204AD5868E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

As Andy notes, this is a proprietary extension in Juniper's implementation = to get around some of the issues in NETCONF's shared candidate model.  = ;There is no standard yet, but I'm willing to submit an I-D and see if ther= e is any WG interest=85

Thanks,
Kent



--_000_CDB7E92D306F5kwatsenjunipernet_-- From ietfc@btconnect.com Thu May 16 06:00: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 77B5421F9104 for ; Thu, 16 May 2013 06:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 ZdW1SLprbMzK for ; Thu, 16 May 2013 06:00:20 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D602C21F90C1 for ; Thu, 16 May 2013 06:00:19 -0700 (PDT) Received: from mail181-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 13:00:19 +0000 Received: from mail181-ch1 (localhost [127.0.0.1]) by mail181-ch1-R.bigfish.com (Postfix) with ESMTP id 250D5400E7 for ; Thu, 16 May 2013 13:00:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I1b0bI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail181-ch1 (localhost.localdomain [127.0.0.1]) by mail181-ch1 (MessageSwitch) id 1368709170108197_9054; Thu, 16 May 2013 12:59:30 +0000 (UTC) Received: from CH1EHSMHS024.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail181-ch1.bigfish.com (Postfix) with ESMTP id 18C20400289 for ; Thu, 16 May 2013 12:59:30 +0000 (UTC) Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by CH1EHSMHS024.bigfish.com (10.43.70.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 12:59:27 +0000 Received: from AMXPRD0111HT003.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 12:59:15 +0000 Message-ID: <006d01ce5234$6b0093a0$4001a8c0@gateway.2wire.net> From: t.petch To: Date: Thu, 16 May 2013 13:53:40 +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 Subject: [Netconf] Fw: [netmod] datastore persistence was Re: Last Call: 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, 16 May 2013 13:00:25 -0000 FYI This was triggered by the IETF Last Call on draft-ietf-netmod-interfaces-cfg-10.txt hence its appearance on the netmod list. Not sure where the discussion should be. Sometimes the split between Netconf and Netmod does not seem very technical. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Juergen Schoenwaelder" Cc: "t.petch" ; Sent: Thursday, May 16, 2013 1:43 PM Subject: Re: [netmod] datastore persistence was Re: Last Call: On May 16, 2013, at 2:18 PM, Juergen Schoenwaelder wrote: > On Thu, May 16, 2013 at 02:08:23PM +0200, Ladislav Lhotka wrote: >> >> On May 16, 2013, at 1:00 PM, t.petch wrote: >> >>> I see this as important to clarify but fear it will fade away only to be >>> resurrected some months later, not the first such occurrence on this >>> list:-( >>> >>> I see Martin's position as very reasonable, >>> >>>> I would say: >>>> >>>> The startup datastore MUST be persistent. >>>> >>>> If startup is implemented, running MUST NOT be persistent. >>>> If startup is not implemented, running MUST be persitent. >>>> >>>> The candidate datastore MUST be persitent. >>>> >>>> /martin >>> >>> just that it is not what the RFC say. Rather, I see >>> >>> :running not writable >>> not very interesting >>> >>> :running :writable-running >>> edits can be made to :running [8.2.1] >>> how the rest of it got there is undefined >>> what happens when the device shuts down is undefined >>> >>> :startup :running :writable-running >>> edits can be made to :running these will be lost on shutdown [8.7.1] >>> the initial state of :running is taken from :startup [8.7.1] >>> :startup cannot be edited but can be replaced by a copy from >>> :running[8.7.1] >>> >>> :candidate :startup :running :writable-running >>> edits can be made to :running these will be lost on shutdown [8.7.1] >>> the initial state of :running is taken from :startup [8.7.1] >>> :startup cannot be edited but can be replaced by a copy from >>> :running[8.7.1] >>> edits can be made to :candidate [8.3.5.1] >>> :candidate can be committed to :running [8.3.4.1] >>> :candidate can be copied to :startup [8.3.5.1] >>> :startup can be copied to :candidate [8.7.5.1] >>> :candidate persistence across shutdowns is undefined >>> >>> I believe that this should be resolved, agreed and documented, as it >>> affects interoperability. >> >> I agree. >> >> Also, the idea of sharing some persistent data between NETCONF and SNMP leads to the question whether the server is allowed to write to any config datastore and, if yes, under what circumstances and rules. It should certainly observe locks, but there can be other problems. For instance, if the server modifies candidate on its own, it could happen that a low-privileged client won't be able to perform a commit. >> > > With 'server' you mean 'SNMP agent'? If so, I would assume that the I mean general rules for changes in any configuration datastore that take place outside a client's session. > SNMP agent simply acts like any other NETCONF client. Implementations > may use short-cuts as long as they lead to the same behaviour. Sure, if this was the rule and no other changes were allowed, then it would be fine. It could still expose the known problems with shared candidate though. > > That said, I think this whole discussion belongs to the NETCONF > working group more than the NETMOD working group. Oh yes, I didn't notice it was in NETCONF. 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 j.schoenwaelder@jacobs-university.de Thu May 16 06:11: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 4A29D21F8F69 for ; Thu, 16 May 2013 06:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.874 X-Spam-Level: X-Spam-Status: No, score=-102.874 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 AoizEdNYw0JQ for ; Thu, 16 May 2013 06:11:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 16A9121F8EDA for ; Thu, 16 May 2013 06:11:08 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73DB420C03; Thu, 16 May 2013 15:11:07 +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 nOa6piv2G3Ld; Thu, 16 May 2013 15:11:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B93320BCD; Thu, 16 May 2013 15:11:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24545264FB4C; Thu, 16 May 2013 15:11:04 +0200 (CEST) Date: Thu, 16 May 2013 15:11:04 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20130516131104.GA28057@elstar.local> Mail-Followup-To: "t.petch" , netconf@ietf.org References: <006d01ce5234$6b0093a0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006d01ce5234$6b0093a0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] Fw: [netmod] datastore persistence was Re: Last Call: 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, 16 May 2013 13:11:13 -0000 On Thu, May 16, 2013 at 01:53:40PM +0100, t.petch wrote: > FYI > > This was triggered by the IETF Last Call on > draft-ietf-netmod-interfaces-cfg-10.txt > hence its appearance on the netmod list. > > Not sure where the discussion should be. Sometimes the split between > Netconf and Netmod does not seem very technical. > The persistence of NETCONF data stores is a NETCONF protocol issue and not a YANG or a data model specific issue. Yes, the issue got raised in the context of NETMOD but any clarification (if it is needed) concerning NETCONF datastore persistens is related to the NETCONF specification, hence I think this discussion technically belongs to the NETCONF working group. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Fri May 17 14:06: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 86C5421F969F for ; Fri, 17 May 2013 14:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.317 X-Spam-Level: X-Spam-Status: No, score=-3.317 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 rPltsFeYVlxp for ; Fri, 17 May 2013 14:06:26 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 8821921F96A4 for ; Fri, 17 May 2013 14:06:26 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUZab0jK+QrRa4jeGh8hxkGYZl/PGFrev@postini.com; Fri, 17 May 2013 14:06:26 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 May 2013 13:59:21 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 17 May 2013 13:59:20 -0700 Received: from CO9EHSOBE006.bigfish.com (207.46.163.28) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 17 May 2013 14:02:11 -0700 Received: from mail173-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.23; Fri, 17 May 2013 20:59:20 +0000 Received: from mail173-co9 (localhost [127.0.0.1]) by mail173-co9-R.bigfish.com (Postfix) with ESMTP id 13CF718040E for ; Fri, 17 May 2013 20:59:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -35 X-BigFish: PS-35(zzbb2dI98dI9371I1432I4015I616Rzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail173-co9 (localhost.localdomain [127.0.0.1]) by mail173-co9 (MessageSwitch) id 1368824358815934_17497; Fri, 17 May 2013 20:59:18 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.232]) by mail173-co9.bigfish.com (Postfix) with ESMTP id BB1E434005A; Fri, 17 May 2013 20:59:18 +0000 (UTC) Received: from CH1PRD0511HT002.namprd05.prod.outlook.com (157.56.245.197) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 17 May 2013 20:59:18 +0000 Received: from CH1PRD0511MB407.namprd05.prod.outlook.com ([169.254.5.114]) by CH1PRD0511HT002.namprd05.prod.outlook.com ([10.255.159.37]) with mapi id 14.16.0305.001; Fri, 17 May 2013 20:59:17 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "netconf@ietf.org" Thread-Topic: [Netconf] draft-ietf-netconf-rfc5539bis-03.txt Thread-Index: AQHOTcEsiShtw0xLnUy3VRPKTvK5upkJpDaA Date: Fri, 17 May 2013 20:59:16 +0000 Message-ID: In-Reply-To: <20130510204343.GB73304@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.159.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E04B7EA34DB3C4EB4E74DE95F513CE1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%JACOBS-UNIVERSITY.DE$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [Netconf] draft-ietf-netconf-rfc5539bis-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 21:06:45 -0000 A number of issues with section 2.4.1 (Server Identity) 1. "hostname" text may be outdated -03 says: "Particularly, the NETCONF client MUST check its understanding of the NETCONF server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks." I know this text was in RFC 5539, but RFC 6125 doesn't use this language in it's "Verifying Service Identity" section, likely because it was realized that checking "hostname" isn't actually what's needed. Interestingly, RFC 6125 has a "Prior Art" section (Appendix B), where it quotes other RFC's statements and, in fact, has NETCONF-TLS listed in B7. This suggests that our text should to be updated to match RFC 6125. 2. NETCONF client/server --> TLS client/server These crypto rules regard the TLS layer and, as such, I think the client/server qualifications need to be TLS (not NETCONF) There is a caveat to this, though, as there is another way to envision the Call Home reversal happening. What is defined now, in section 2.1.2 (Call Home) is this: NETCONF Server <-------- NETCONF Client TLS Client --------> TLS Server TCP Server --------> TCP Server Alternatively, we might envision: NETCONF Server <-------- NETCONF Client TLS Server <-------- TLS Client TCP Server --------> TCP Server That is, the NETCONF server still initiates the connection, but then immediately takes on the role of the TLS server. If this were the case, then the existing text is OK because the NETCONF/TLS client/server identities would always be aligned. Still, to be safe, it might be better to s/NETCONF/TLS/g 3. The NETCONF client SHOULD be the TLS client (not server) Actually, we actually want the NETCONF client to be the TLS client (not server), so that it's clear that it is the side sending the client certificate, from which the NETCONF username is derived. Further evidence is found in draft-agl-tls-encryptedclientcerts-00 and draft-badra-tls-identity-protection-02.txt. Both these drafts attempt to address privacy issues with sending client certificates in the clear, as is currently the case. While neither draft has reached RFC status, it is clearly an identified problem and we'd want whatever solution is ultimately defined to seamlessly apply to NETCONF-TLS Call Home cases as well. 4: RFC 6125-based matching is invalid for Call Home behind NAT case -03 says: "Matching is performed according to the rules and guidelines defined in [RFC6125]." In the Call Home case, the only thing the NETCONF client receives besides the certificate is the NETCONF server's src-addr. But, this src-addr is meaningless in cases where the NETCONF server's address is NAT-ed, and thus cannot be used to compare the identity presented in the certificate. The only thing an NETCONF client could do would be to compare the identity in the certificate to some expected value(s). Thus, for NAT-ed call home cases, this text becomes critical: "If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted." Thanks, Kent On 5/10/13 4:43 PM, "Juergen Schoenwaelder" wrote: >Hi, > >I have posted a new revision - here is the summary of the changes: > >A.1. draft-ietf-netconf-rfc5539bis-03 > > o Added support for call home (allocation of a new port number, > rewrote text to allow a NETCONF client to be a TLS server and a > NETCONF server to be a TLS client). > > o Merged sections 2 and 3 into a new section 2 and restructured the > text. > > o Extended the IANA considerations section. > > o Using the cert-to-name mapping grouping from the SNMP > configuration data model and updated the examples. > > o Creating an extensible set of YANG (sub)modules for NETCONF > following the (sub)module structure of the SNMP configuration > model. > >The call home support is still somewhat incomplete and we continue >working on that (e.g., we may want to configure where to call home, >which credentials to use, and the policy used to call home). > >/js > >--=20 >Juergen Schoenwaelder Jacobs University Bremen gGmbH >Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >Fax: +49 421 200 3103 >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From bclaise@cisco.com Tue May 21 04:23: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 73B6521F961C for ; Tue, 21 May 2013 04:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, 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 SGXeYODviNXW for ; Tue, 21 May 2013 04:23:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF521F852D for ; Tue, 21 May 2013 04:23:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4LBNMsL026288; Tue, 21 May 2013 13:23:22 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4LBMuWu001605; Tue, 21 May 2013 13:23:12 +0200 (CEST) Message-ID: <519B5910.3000202@cisco.com> Date: Tue, 21 May 2013 13:22:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010505080908080200020302" Cc: "netconf@ietf.org" Subject: Re: [Netconf] Proposed Netconf Charter for Approval 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, 21 May 2013 11:23:30 -0000 This is a multi-part message in MIME format. --------------010505080908080200020302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Mehmet, This is on the IESG telechat for internal review on May 30th. The milestones are impressive, but you are all long time IETF'ers. So I'll trust that you know what you're doing. Regards, Benoit > Hi Benoit, > below is the charter proposal we would like to provide for approval. > After a call for comments on the Netconf maillist there was no > substantial argument against it. Especially, we think the TLS draft > should developed further. > A discussion on the prioritization of topics in the queue has been > started but there is no result yet. We will restart the discussion on > the priorities and hint the WG to prepare themselves to have an answer > at the latest in Berlin. For IETF #87 we asked for a Netconf session > on Thursday to enable the WG members to have side discussions, which > hopefully will help to weight the priorities and to consolidate the > views on particular topics like operational state. > However, we think that we shouldn't wait on the results of this > discussion hence should start now the work on the work items decided > in IETF #86. > Thank you for support. > Bert & Mehmet > === Proposed Charter text === > Network Configuration (netconf) > ------------------------------- > Charter > Current Status: Active > Chairs: > Bert Wijnen <_bertietf@bwijnen.net_ > > Mehmet Ersue <_mehmet.ersue@nsn.com_ > > Operations and Management Area Directors: > Benoit Claise <_bclaise@cisco.com_ > > Joel Jaeggli <_joelja@bogus.com_ > > Operations and Management Area Advisor: > Benoit Claise <_bclaise@cisco.com_ > > Mailing Lists: > General Discussion: _netconf@ietf.org_ > To Subscribe: _https://www.ietf.org/mailman/listinfo/netconf_ > Archive: _http://www.ietf.org/mail-archive/web/netconf/_ > Description of Working Group: > Configuration of networks of devices has become a critical requirement > for operators in today's highly interconnected networks. Large and small > operators alike have developed their own mechanisms or have used vendor > specific mechanisms to transfer configuration data to and from a device > and to examine device state information which may impact the > configuration. Each of these mechanisms may be different in various > aspects, such as session establishment, user authentication, > configuration data exchange, and error responses. > The NETCONF protocol has the following characteristics: > - Provides retrieval mechanisms which can differentiate between > configuration data and non-configuration data > - Is extensible enough so that vendors can provide access to all > configuration data on the device using a single protocol > - Has a programmatic interface (avoids screen scraping and formatting- > related changes between releases) > - Uses an XML-based data representation, that can be easily manipulated > using non-specialized XML manipulation tools. > - Supports integration with existing user authentication methods > - Supports integration with existing configuration database systems > - Supports multiple (e.g. candidate and running) data-stores to optimize > configuration preparation and activation > - Supports network wide configuration transactions (with features such > as locking and rollback capability) > - Runs over a secure transport; SSH is mandatory to implement while TLS, > BEEP, and SOAP are optional transports. > - Provides support for asynchronous notifications. > - Supports an Access Control Model and a YANG module for configuring the > Access Control parameters. > - Supports a YANG module for System Notifications > The NETCONF protocol is data modeling language independent, but YANG is > the recommended NETCONF modeling language, which introduces advanced > language features for configuration management. > Based on the implementation, deployment experience and interoperability > testing, the WG aims to produce a NETCONF status report in a later > stage. > The result may be clarifications for RFC6241 and RFC6242 and addressing > any reported errata. > In the current phase of NETCONF's incremental development the workgroup > will focus on following items: > 1. Add call home mechanism for the mandatory SSH binding providing a > server-initiated session establishment. > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update > RFC 5539) and add the call home mechanism to provide a server-initiated > session establishment. > Goals and Milestones: > Done - WG Last Call on rfc4741bis > Done - Send with-defaults to IESG for consideration as Proposed > Standard > Done - first WG draft (rev 00) on NACM posted > Done - rfc4741bis to IESG for consideration as Proposed Standard > Done - Send rfc4742bis to IESG for consideration as proposed > Standard > Done - first WG draft (rev 00) on NETCONF specific YANG modules > posted > Done - WGLC for NACM document > Done - WGLC for NETCONF specific notifications document > Done - submit NACM document to IESG for consideration as > Proposed Standard > Done - submit NETCONF specific notifications document to IESG > for consideration as Proposed Standard > May 2013 - Submit initial WG document on Reverse SSH > Jul 2013 - WGLC for rfc5539bis > Jul 2013 - WGLC for Reverse SSH > Aug 2013 - submit rfc5539bis to AD/IESG for consideration as > Proposed Standard > Aug 2013 - submit SSH binding to AD/IESG for consideration as > Proposed Standard > === End-of proposed charter text === > > -----Original Message----- > > From:_netconf-bounces@ietf.org_ > [_mailto:netconf-bounces@ietf.org_] On Behalf Of ext > > Ersue, Mehmet (NSN - DE/Munich) > > Sent: Monday, May 06, 2013 5:27 PM > > To:_netconf@ietf.org_ > > Subject: [Netconf] FW: Developing Call-Home for the SSH and TLS transport bindings - > > New Charter text > > > > Dear Netconf WG, > > > > the co-chairs proposed a draft charter text to realize the call-home mechanism for the > > SSH and TLS bindings, as concluded in the IETF #86 meeting. We did not get any > > substantial arguments against. Also, an attempt to discuss on the priority of other > > issues in the queue did not bring any new perspective. > > > > Based on this the co-chairs think that the WG should proceed, following the discussion > > in the IETF #86, with the development of the call-home mechanism for the SSH and > > TLS bindings. We now will do slight changes to the milestones and give the proposed > > charter to our AD to initiate the approval. > > > > Concerning the Netconf RFC advancement, we did not get volunteers to co-author a > > deployment report and the number of deployment reports received so far seems very > > thin to ask for advancement based on "wide deployment" at this point in time. We > > therefore suggest to exclude this point from the charter for the time being. It can be > > revived if things change hopefully soon. > > > > Bert & Mehmet > > > > > > > -----Original Message----- > > > From:netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of > > ext > > > Ersue, Mehmet (NSN - DE/Munich) > > > Sent: Friday, April 12, 2013 3:30 PM > > > To:netconf@ietf.org > > > Subject: [Netconf] Developing Call-Home for the SSH and TLS transport bindings - > > New > > > Charter text > > > > > > Dear NETCONF WG, > > > > > > we discussed in the IETF #86 Netconf session on resurrecting and developing the call > > > home mechanism, i.e. initiation of session establishment by the server. The session > > > attendees supported the development of call home for both, the SSH and TLS > > > transport bindings. > > > > > > For the SSH binding, Kent Watsen volunteered to update his draft on Reverse SSH. > > > Concerning the TLS binding, the authors of the rfc5539bis draft agreed to add the > > > necessary text for call home. Based on the session agreement, the co-chairs > > promised > > > to verify the WG support on the mailing list and add call-home for the ssh and tls > > > drafts to the charter. > > > > > > If there are no substantial arguments against developing call home as planned by > > April > > > 26, 2013 EOB, the co-chairs will add following addition to the charter and provide our > > > AD to review and initiate the IESG approval. > > > > > > Whether point 3. on the list below remains in the charter depends on the response > > we > > > get to the call on RFC advancement until May 1st. > > > > > > Please send your comments to the Netconf maillist by April 26, 2013. > > > > > > Draft authors: Please confirm or comment the deadlines listed in the charter text > > > below with a short note to the co-chairs. > > > > > > Bert & Mehmet > > > > > > > > > === modified charter text === > > > > > > In the current phase of NETCONF's incremental development the workgroup > > > will focus on following items: > > > > > > 1. Add call home mechanism for the mandatory SSH binding providing a > > > server-initiated session establishment. > > > > > > 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update > > > RFC 5539) and add the call home mechanism to provide a server-initiated > > > session establishment. > > > > > > 3. Based on the implementation, deployment experience and > > > interoperability testing, the WG will produce a NETCONF status report. > > > The result may be clarifications for RFC6241 and RFC6242 and addressing > > > any reported errata. > > > > > > Goals and Milestones: > > > Done - WG Last Call on rfc4741bis > > > Done - Send with-defaults to IESG for consideration as Proposed Standard > > > Done - first WG draft (rev 00) on NACM posted > > > Done - rfc4741bis to IESG for consideration as Proposed Standard > > > Done - Send rfc4742bis to IESG for consideration as proposed Standard > > > Done - first WG draft (rev 00) on NETCONF specific YANG modules posted > > > Done - WGLC for NACM document > > > Done - WGLC for NETCONF specific notifications document > > > Done - submit NACM document to IESG for consideration as Proposed Standard > > > Done - submit NETCONF specific notifications document to IESG for > > consideration > > > as Proposed Standard > > > May 2013 - Submit initial WG document on Reverse SSH > > > May 2013 - Collect Implementation/Deployment reports for RFC6241 and 6242 > > > May 2013 - IETF wiki page and/or initial I-D for RFC6241/6242 > > > implementation/deployment experience > > > Jun 2013 - WGLC for rfc5539bis > > > Jul 2013 - WGLC for Reverse SSH > > > Jul 2013 - WGLC on RFC6241/6242 implementation/deployment experience > > > Jul 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > > > Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed Standard > > > Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment experience > > doc > > > to IESG for publication as Informational RFC > > > > > > === end-of modified charter text === > > > > > > > > > _______________________________________________ > > > 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 --------------010505080908080200020302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Mehmet,

This is on the IESG telechat for internal review on May 30th.
The milestones are impressive, but you are all long time IETF'ers. So I'll trust that you know what you're doing.

Regards, Benoit
Hi Benoit,
 
below is the charter proposal we would like to provide for approval.
 
After a call for comments on the Netconf maillist there was no substantial argument against it. Especially, we think the TLS draft should developed further.
 
A discussion on the prioritization of topics in the queue has been started but there is no result yet. We will restart the discussion on the priorities and hint the WG to prepare themselves to have an answer at the latest in Berlin. For IETF #87 we asked for a Netconf session on Thursday to enable the WG members to have side discussions, which hopefully will help to weight the priorities and to consolidate the views on particular topics like operational state.
 
However, we think that we shouldn't wait on the results of this discussion hence should start now the work on the work items decided in IETF #86.
 
Thank you for support.
 
Bert & Mehmet
 
 
=== Proposed Charter text ===
 
Network Configuration (netconf)
-------------------------------
 
Charter
 
Current Status: Active
 
Chairs:
     Bert Wijnen <bertietf@bwijnen.net>
     Mehmet Ersue <mehmet.ersue@nsn.com>
 
Operations and Management Area Directors:
     Benoit Claise <bclaise@cisco.com>
     Joel Jaeggli <joelja@bogus.com>
 
Operations and Management Area Advisor:
     Benoit Claise <bclaise@cisco.com>
 
Mailing Lists:
     General Discussion: netconf@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/netconf
     Archive:            http://www.ietf.org/mail-archive/web/netconf/
 
Description of Working Group:
 
  Configuration of networks of devices has become a critical requirement
  for operators in today's highly interconnected networks. Large and small
  operators alike have developed their own mechanisms or have used vendor
  specific mechanisms to transfer configuration data to and from a device
  and to examine device state information which may impact the
  configuration. Each of these mechanisms may be different in various
  aspects, such as session establishment, user authentication,
  configuration data exchange, and error responses.
 
  The NETCONF protocol has the following characteristics:
 
  - Provides retrieval mechanisms which can differentiate between
  configuration data and non-configuration data
  - Is extensible enough so that vendors can provide access to all
  configuration data on the device using a single protocol
  - Has a programmatic interface (avoids screen scraping and formatting-
  related changes between releases)
  - Uses an XML-based data representation, that can be easily manipulated
  using non-specialized XML manipulation tools.
  - Supports integration with existing user authentication methods
  - Supports integration with existing configuration database systems
  - Supports multiple (e.g. candidate and running) data-stores to optimize
  configuration preparation and activation
  - Supports network wide configuration transactions (with features such
  as locking and rollback capability)
  - Runs over a secure transport; SSH is mandatory to implement while TLS,
  BEEP, and SOAP are optional transports.
  - Provides support for asynchronous notifications.
  - Supports an Access Control Model and a YANG module for configuring the
  Access Control parameters.
  - Supports a YANG module for System Notifications
 
  The NETCONF protocol is data modeling language independent, but YANG is
  the recommended NETCONF modeling language, which introduces advanced
  language features for configuration management.
 
  Based on the implementation, deployment experience and interoperability
  testing, the WG aims to produce a NETCONF status report in a later stage.
  The result may be clarifications for RFC6241 and RFC6242 and addressing
  any reported errata.
 
  In the current phase of NETCONF's incremental development the workgroup
  will focus on following items:
 
  1. Add call home mechanism for the mandatory SSH binding providing a
  server-initiated session establishment.
 
  2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
  RFC 5539) and add the call home mechanism to provide a server-initiated
  session establishment.
 
Goals and Milestones:
  Done     - WG Last Call on rfc4741bis
  Done     - Send with-defaults to IESG for consideration as Proposed Standard
  Done     - first WG draft (rev 00) on NACM posted
  Done     - rfc4741bis to IESG for consideration as Proposed Standard
  Done     - Send rfc4742bis to IESG for consideration as proposed Standard
  Done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
  Done     - WGLC for NACM document
  Done     - WGLC for NETCONF specific notifications document
  Done     - submit NACM document to IESG for consideration as Proposed Standard
  Done     - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard
  May 2013 - Submit initial WG document on Reverse SSH
  Jul 2013 - WGLC for rfc5539bis
  Jul 2013 - WGLC for Reverse SSH
  Aug 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
  Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed Standard
 
=== End-of proposed charter text ===
 
 
> -----Original Message-----
> Ersue, Mehmet (NSN - DE/Munich)
> Sent: Monday, May 06, 2013 5:27 PM
> Subject: [Netconf] FW: Developing Call-Home for the SSH and TLS transport bindings -
> New Charter text
>
> Dear Netconf WG,
>
> the co-chairs proposed a draft charter text to realize the call-home mechanism for the
> SSH and TLS bindings, as concluded in the IETF #86 meeting. We did not get any
> substantial arguments against. Also, an attempt to discuss on the priority of other
> issues in the queue did not bring any new perspective.
>
> Based on this the co-chairs think that the WG should proceed, following the discussion
> in the IETF #86, with the development of the call-home mechanism for the SSH and
> TLS bindings. We now will do slight changes to the milestones and give the proposed
> charter to our AD to initiate the approval.
>
> Concerning the Netconf RFC advancement, we did not get volunteers to co-author a
> deployment report and the number of deployment reports received so far seems very
> thin to ask for advancement based on "wide deployment" at this point in time. We
> therefore suggest to exclude this point from the charter for the time being. It can be
> revived if things change hopefully soon.
>
> Bert & Mehmet
>
>
> > -----Original Message-----
> ext
> > Ersue, Mehmet (NSN - DE/Munich)
> > Sent: Friday, April 12, 2013 3:30 PM
> > Subject: [Netconf] Developing Call-Home for the SSH and TLS transport bindings -
> New
> > Charter text
> >
> > Dear NETCONF WG,
> >
> > we discussed in the IETF #86 Netconf session on resurrecting and developing the call
> > home mechanism, i.e. initiation of session establishment by the server. The session
> > attendees supported the development of call home for both, the SSH and TLS
> > transport bindings.
> >
> > For the SSH binding, Kent Watsen volunteered to update his draft on Reverse SSH.
> > Concerning the TLS binding, the authors of the rfc5539bis draft agreed to add the
> > necessary text for call home. Based on the session agreement, the co-chairs
> promised
> > to verify the WG support on the mailing list and add call-home for the ssh and tls
> > drafts to the charter.
> >
> > If there are no substantial arguments against developing call home as planned by
> April
> > 26, 2013 EOB, the co-chairs will add following addition to the charter and provide our
> > AD to review and initiate the IESG approval.
> >
> > Whether point 3. on the list below remains in the charter depends on the response
> we
> > get to the call on RFC advancement until May 1st.
> >
> > Please send your comments to the Netconf maillist by April 26, 2013.
> >
> > Draft authors: Please confirm or comment the deadlines listed in the charter text
> > below with a short note to the co-chairs.
> >
> > Bert & Mehmet
> >
> >
> > === modified charter text ===
> >
> >   In the current phase of NETCONF's incremental development the workgroup
> >   will focus on following items:
> >
> >   1. Add call home mechanism for the mandatory SSH binding providing a
> >   server-initiated session establishment.
> >
> >   2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update
> >   RFC 5539) and add the call home mechanism to provide a server-initiated
> >   session establishment.
> >
> >   3. Based on the implementation, deployment experience and
> >   interoperability testing, the WG will produce a NETCONF status report.
> >   The result may be clarifications for RFC6241 and RFC6242 and addressing
> >   any reported errata.
> >
> > Goals and Milestones:
> >   Done     - WG Last Call on rfc4741bis
> >   Done     - Send with-defaults to IESG for consideration as Proposed Standard
> >   Done     - first WG draft (rev 00) on NACM posted
> >   Done     - rfc4741bis to IESG for consideration as Proposed Standard
> >   Done     - Send rfc4742bis to IESG for consideration as proposed Standard
> >   Done     - first WG draft (rev 00) on NETCONF specific YANG modules posted
> >   Done     - WGLC for NACM document
> >   Done     - WGLC for NETCONF specific notifications document
> >   Done     - submit NACM document to IESG for consideration as Proposed Standard
> >   Done     - submit NETCONF specific notifications document to IESG for
> consideration
> > as Proposed Standard
> >   May 2013 - Submit initial WG document on Reverse SSH
> >   May 2013 - Collect Implementation/Deployment reports for RFC6241 and 6242
> >   May 2013 - IETF wiki page and/or initial I-D for RFC6241/6242
> > implementation/deployment experience
> >   Jun 2013 - WGLC for rfc5539bis
> >   Jul 2013 - WGLC for Reverse SSH
> >   Jul 2013 - WGLC on RFC6241/6242 implementation/deployment experience
> >   Jul 2013 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard
> >   Aug 2013 - submit SSH binding to AD/IESG for consideration as Proposed Standard
> >   Aug 2013 - Possibly submit RFC6241/6242 implementation/deployment experience
> doc
> > to IESG for publication as Informational RFC
> >
> > === end-of modified charter text ===
> >
> >
> > _______________________________________________
> > Netconf mailing list
> _______________________________________________
> Netconf mailing list
 
 

--------------010505080908080200020302-- From mbj@tail-f.com Wed May 22 20:28: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 8F42711E8145 for ; Wed, 22 May 2013 20:28:08 -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 7Tzboph3CiGm for ; Wed, 22 May 2013 20:28:02 -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 AB07111E812C for ; Wed, 22 May 2013 20:28:02 -0700 (PDT) Received: from localhost (adsl-69-108-218-178.dsl.pltn13.pacbell.net [69.108.218.178]) by mail.tail-f.com (Postfix) with ESMTPSA id 5C60B1200A35 for ; Thu, 23 May 2013 05:28:00 +0200 (CEST) Date: Wed, 22 May 2013 20:27:58 -0700 (PDT) Message-Id: <20130522.202758.526103716.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund 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 Subject: [Netconf] review of draft-ietf-netconf-rfc5539bis-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 03:28:08 -0000 Hi, I have reviewed this document and have some (mostly minor) comments: o 2.4.1 First paragraph says: "Particularly, the NETCONF client MUST check its understanding of the NETCONF server hostname" And last paragraph says: "If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted." First of all, it is not sure what "the hostname check" refers to? Second, if it refers to the first paragraph, it seems to be a contradiction. o 2.4.2.1 s/cert-map list/cert-to-name list/ o 3 s/This organizations/This organization/ o leaf psk-identity This leaf says how a PSK identity MAY be encoded in UTF-8. How will a NETCONF client know how a server will encode a certain PSK identity, so that the NETCONF client can create a matching entry in the list? o leaf not-valid-after s/not valid before/not valid after/ o 5.1 & 5.2 The prefix x509c2n is not defined, should be: xmlns:x509c2n= "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name" e.g. in the element. /martin From j.schoenwaelder@jacobs-university.de Wed May 22 23:04: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 11C5821F95D7 for ; Wed, 22 May 2013 23:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=0.083, 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 Qirvlxa19cov for ; Wed, 22 May 2013 23:04: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 D909D21F93A5 for ; Wed, 22 May 2013 23:04:53 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 848D620BEE; Thu, 23 May 2013 08:04:52 +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 gLjHXa55vxzE; Thu, 23 May 2013 08:04:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB61720BDD; Thu, 23 May 2013 08:04:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D40A4266E4D1; Thu, 23 May 2013 08:04:49 +0200 (CEST) Date: Thu, 23 May 2013 08:04:49 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130523060449.GA31965@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20130522.202758.526103716.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130522.202758.526103716.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-rfc5539bis-03.txt 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, 23 May 2013 06:04:59 -0000 On Wed, May 22, 2013 at 08:27:58PM -0700, Martin Bjorklund wrote: > Hi, > > I have reviewed this document and have some (mostly minor) comments: > > > o 2.4.1 > > First paragraph says: > > "Particularly, the NETCONF client MUST check its understanding of the > NETCONF server hostname" > > And last paragraph says: > > "If the NETCONF client has external information as to the expected > identity of the NETCONF server, the hostname check MAY be > omitted." > > First of all, it is not sure what "the hostname check" refers to? > > Second, if it refers to the first paragraph, it seems to be a > contradiction. Yes. Note that this contradiction is copied from RFC 5539. I have written down a TODO item on this since we might have to work on this text anyway for call-home. > o 2.4.2.1 > > s/cert-map list/cert-to-name list/ fixed > o 3 > > s/This organizations/This organization/ fixed > o leaf psk-identity > > This leaf says how a PSK identity MAY be encoded in UTF-8. > > How will a NETCONF client know how a server will encode a certain > PSK identity, so that the NETCONF client can create a matching > entry in the list? What about this: "The PSK identity encoded as a UTF-8 string. For details how certain common PSK identity formats can be encoded in UTF-8, see section 5.1. of RFC 4279."; RFC 4279 is not very detailed, covering only two trivial cases and the DNS name case somewhat superficially. > o leaf not-valid-after > > s/not valid before/not valid after/ fixed > o 5.1 & 5.2 > > The prefix x509c2n is not defined, should be: > > xmlns:x509c2n= > "urn:ietf:params:xml:ns:yang:ietf-x509-cert-to-name" > > e.g. in the element. fixed in 5.1, section 5.2 does not use the x509c2n prefix /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From prvs=3863cd0512=balazs.lengyel@ericsson.com Fri May 31 06:42:46 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 0CCE021F915B for ; Fri, 31 May 2013 06:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.791 X-Spam-Level: X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 lUjUDq4TX1CY for ; Fri, 31 May 2013 06:42:37 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CDB7921F8717 for ; Fri, 31 May 2013 06:42:36 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-c2-51a8a8cb4262 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9D.A1.15700.BC8A8A15; Fri, 31 May 2013 15:42:35 +0200 (CEST) Received: from [159.107.197.81] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 31 May 2013 15:42:35 +0200 Message-ID: <51A8A8CA.3040102@ericsson.com> Date: Fri, 31 May 2013 15:42:34 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvre7pFSsCDQ6cMLJ4cGQWu8WBOewW UzfdZrX4tukPswOLx5IlP5k8rjddZfd4uKSDxaOl/yJLAEsUt01SYklZcGZ6nr5dAnfGnI9x BX2iFbcnfmJuYPzG38XIySEhYCLxYcNxdghbTOLCvfVsXYxcHEICpxgllq6/xAThrGGU+Ph5 JStIFa+AtsT3XZ/AbBYBVYmZM+6AdbMJGElM7T/PAmKLCkRJzFn3gA2iXlDi5MwnYHERoPq1 hw4zgtjMAoUSd68/ApsjLOAvsetPH1iNkICBxL63EDM5BQwlHnRtY4Go15W48H8KlC0vsf3t HGaIeg2Jhxf+sk5gFJyFZN0sJC2zkLQsYGRexciem5iZk15uuIkRGLoHt/zW3cF46pzIIUZp DhYlcV493sWBQgLpiSWp2ampBalF8UWlOanFhxiZODhBBJdUA2P51YVeUv4x5Y3CqioTl/Dv lTr5++99v9Me8xad9couaQ1e/7ckKu2erHpSRk+w7YZee7H2gP8NtppKSpWvjngXOj1Jvzp7 dtzWm716Rm/+HLCrkijNkXqxui5RTUD9m6Cv5ZmpMRPW+Ylp71Btqon6eli0dcW0E8+Z4jRZ tcwrbCeGXGRRVWIpzkg01GIuKk4EAEW+IKswAgAA Cc: "netconf@ietf.org" Subject: Re: [Netconf] Candidate config for big multiuser nodes - is it usable? 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, 31 May 2013 13:42:46 -0000 Hello kent,
Sorry for droping ut for so long.
I Ericsson we are interested in this problem. As I know Tailf also has some kind of solution for concurent editing my multiple parties.
regards Balazs

On 2013-05-14 19:24, Kent Watsen wrote:

As Andy notes, this is a proprietary extension in Juniper's implementation to get around some of the issues in NETCONF's shared candidate model.  There is no standard yet, but I'm willing to submit an I-D and see if there is any WG interest…

Thanks,
Kent





_______________________________________________
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 iesg-secretary@ietf.org Fri May 31 09:06:53 2013 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD0F21F8624; Fri, 31 May 2013 09:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.042, 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 vqaZKdx2dGZ9; Fri, 31 May 2013 09:06:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE39121F96F5; Fri, 31 May 2013 09:06:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130531160646.29335.19837.idtracker@ietfa.amsl.com> Date: Fri, 31 May 2013 09:06:46 -0700 Cc: netconf WG Subject: [Netconf] WG Action: Rechartered Network Configuration (netconf) 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, 31 May 2013 16:06:53 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Network Configuration (netconf) ------------------------------------------------ Current Status: Active WG Chairs: Bert Wijnen Mehmet Ersue Assigned Area Director: Benoit Claise Mailing list Address: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Charter: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol has the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough so that vendors can provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting- related changes between releases) - Uses an XML-based data representation, that can be easily manipulated using non-specialized XML manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports multiple (e.g. candidate and running) data-stores to optimize configuration preparation and activation - Supports network wide configuration transactions (with features such as locking and rollback capability) - Runs over a secure transport; SSH is mandatory to implement while TLS is an optional transport. - Provides support for asynchronous notifications. - Supports an Access Control Model and a YANG module for configuring the Access Control parameters. - Supports a YANG module for System Notifications The NETCONF protocol is data modeling language independent, but YANG is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Add call home mechanism for the mandatory SSH binding providing a server-initiated session establishment. 2. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. Milestones: May 2013 - Submit initial WG document on Reverse SSH Jun 2013 - WGLC for rfc5539bis Jul 2013 - WGLC for Reverse SSH Aug 2013 - Submit rfc5539bis to AD/IESG for consideration as Proposed Standard Aug 2013 - Submit SSH binding to AD/IESG for consideration as Proposed Standard