From mbj@tail-f.com Wed Aug 1 09:42:02 2012 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 3AB1E11E8194 for ; Wed, 1 Aug 2012 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.208, 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 5uEBS3yGypIX for ; Wed, 1 Aug 2012 09:42:01 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDA611E816E for ; Wed, 1 Aug 2012 09:42:01 -0700 (PDT) Received: from localhost (dhcp-410a.meeting.ietf.org [130.129.65.10]) by mail.tail-f.com (Postfix) with ESMTPSA id 78EB71200D65 for ; Wed, 1 Aug 2012 18:41:59 +0200 (CEST) Date: Wed, 01 Aug 2012 09:41:55 -0700 (PDT) Message-Id: <20120801.094155.441181990.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] review of draft-badra-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 16:42:02 -0000 Hi, Here are my comments on draft-badra-netconf-rfc5539bis-02. Almost all of them are the same as my review of -01, but I never saw any reply to them - except for a few that Juergen replied to and fixed. o 3.2 OLD: The server MUST verify the identity of the client to ensure that the incoming client request is legitimate before any configuration or state data is sent to or received from the client. NEW: The server MUST verify the identity of the client to ensure that the incoming client request is legitimate before the NETCONF session is started. o 3.2.1 The NETCONF server MUST implement the algorithms for deriving NETCONF usernames from presented certificates that are documented in the ietf-netconf-tls YANG module. Add a forward reference, like: ietf-netconf-tls YANG module, defined in Section ??. o 3.2.1 The NETCONF server MAY use any of the following algorithms to produce the NETCONF username from the certificate presented by the NETCONF client: This sounds as the server also may use some other algorithm? Is this intentional? o 3.2.1.1 A client certificate has an identity: the certificate. The TLS and corresponding protocols provide an identity. Did you mean "The TLS and corresponding protocols provides this identity"? If not, please clarify. o 3.2.1.1 If a locally held copy of a trusted CA certificate is configured in the transformation container, What is "the transformation container"? and that CA certificate was used to validate the path to the presented certificate, then the NETCONF server SHOULD use that list entry in the transformation container. What should the server use that list entry for? And since this is a SHOULD, it seems it doesn't have to use it? During which circumstances can it choose not to use it? o 3.2.1.2 On the server side, this PSK identity is used to look up the key Where? I think this section needs to mention the data model nodes defined in the YANG module. o 3.2.1.2 If the selected pre-shared keys match and the key is valid, then the client is authenticated and the NETCONF username associated with the PSK identity. Bad sentence. o 3.2.1.2 For details on how the PSK identity MAY be encoded in UTF-8, see section 5.1. of RFC [RFC6241]. Wrong reference. o YANG module The YANG module is not valid: ietf-netconf-tls.yang:389: error: unexpected keyword "pattern" (pattern should be a substatement to string) o feature map-certificates "The :map-certificates capability implements mapping X.509 certificates to NETCONF user names."; This is not a capability, and the ":" notation is confusing. NEW: "The map-certificates feature indicates that the server implements mapping X.509 certificates to NETCONF user names."; (ditto for map-pre-shared-keys) o container cert-mappings OLD: On an incoming TLS connection, the client's presented certificate MUST either be validated based on an established trust anchor, or it MUST directly match a fingerprint in this container. This container does not provide any mechanisms for configuring the trust anchors; NEW: On an incoming TLS connection, the client's presented certificate MUST either be validated based on an established trust anchor, or it MUST directly match a fingerprint in the 'cert-map' list. This module does not provide any mechanisms for configuring the trust anchors; The term "this container" is used several times in this text where the list 'cert-map' is meant. Please check the text and rephrase. However, this container is flexible to allow for situations where existing deployed certificate infrastructures do not provide adequate subjectAltName values for use as NETCONF usernames." How is this flexibility done? This needs to be clarified. o list cert-map Instead of using an integer key, I suggest you use an ordered-by user list with an arbitratry string as key. This use case is why ordered-by user lists exist. o leaf map-type { Instead of enumerating all different combinations, I suggest you use an ordered-by user leaf-list. Also, I think the following structure would be more natural: choice map-type { leaf specified { type nacm:user-name-type; // note the new type // replaces your "data" leaf } leaf-list from-certificate { type enumeration { enum rfc822Name; enum dNSName; enum ipAddress; } ordered-by user; } } Then you can use for example: bob or dnsName rfc822Name /martin From bwijnen@ripe.net Wed Aug 1 14:37:17 2012 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 E7CA011E8105 for ; Wed, 1 Aug 2012 14:37:17 -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.000, 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 r8WINzY+She8 for ; Wed, 1 Aug 2012 14:37:17 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C4BEC11E80F1 for ; Wed, 1 Aug 2012 14:37:16 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwgbR-0001Sr-7Z for netconf@ietf.org; Wed, 01 Aug 2012 23:37:15 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SwgbQ-0006ie-Ix for netconf@ietf.org; Wed, 01 Aug 2012 23:37:13 +0200 Message-ID: <5019A186.2030808@ripe.net> Date: Wed, 01 Aug 2012 14:37:10 -0700 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> In-Reply-To: <501973A2.4020900@ripe.net> X-Forwarded-Message-Id: <501973A2.4020900@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120801 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e2569ff9cce36a67deeae257fbc0280cc Subject: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:37:18 -0000 WG participants, based on our discussions at IETF84, we (WG chairs) propose the following new charter text. Pls comment and let us know your opinion no later than August 15th (any timezone). Bert and Mehmet ------ proposed charter as of Augist 1st) --------- Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: 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 interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining 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 Working Group has produced a protocol suitable for network configuration, with 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 has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. To enable an implementation with a reduced code-size, there seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. in constrained devices or for an incremental deployment. The WG will create a document defining the minimal base of features for such a standard. The exact title of Netconf-Lite can be determined by the WG. 3. Based on the implementation and deployment experience, the WG will document the status of NETCONF in order to advance the base documents (at least RFC6241 and RFC6242) on the standards track. 4. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis 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 NACM posted 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 aug 2012 - submit initial WG draft for rfc5539bis aug 2012 - submit initial WG draft for Netconf Lite aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. sep 2012 - WGLC for rfc5539bis sep 2012 - WGLC for RFC4743 and 4743 to historic okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 nov 2012 - WGLC for Netconf Lite nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience jan 2013 - second WGLC for Netconf Lite (if needed) jan 2013 - WGLC on RFC6241/6242 document to advance on standards track feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed Standard feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards Track From mehmet.ersue@nsn.com Wed Aug 1 14:43:03 2012 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 274DF11E8155 for ; Wed, 1 Aug 2012 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 1StAdvhiI8rq for ; Wed, 1 Aug 2012 14:43:02 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E3FC611E8124 for ; Wed, 1 Aug 2012 14:43:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q71Lgw4k005818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Aug 2012 23:42:58 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q71LgtV7024297; Wed, 1 Aug 2012 23:42:56 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 1 Aug 2012 23:42:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2012 23:42:13 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404136A4D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary of the NETCONF WG Session and Action Items in IETF #84 Thread-Index: Ac1wK7DzdUrOIfNWSBKJO1FiLx+UdAAAnCNQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Benoit Claise" , X-OriginalArrivalTime: 01 Aug 2012 21:42:16.0700 (UTC) FILETIME=[85127BC0:01CD702E] 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: 3649 X-purgate-ID: 151667::1343857379-000055D8-786D8F3B/0-0/0-0 Subject: [Netconf] Summary of the NETCONF WG Session and Action Items in IETF #84 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, 01 Aug 2012 21:43:03 -0000 Hi Benoit, All, below is a summary and action items from the discussion in the NETCONF WG session on Monday, July 30, 2012 in the IETF 84 meeting. PS: Draft authors please act as noted below. - We had approx. 50 participants in the 1,5 hour NETCONF session.=20 - We reviewed the status of the WG - We went through the documents which are proposed to become WG items and had a good discussion. - We also discussed documents which are not planned as WG documents. WG status: The WG had long discussions on the Netconf-Lite document without much progress. At the end there seemed to be an agreement that Netconf 1.1 should be advanced to the next level and the so called Netconf-Lite should be a separate document. A draft charter proposal is available for discussion. NETCONF Over TLS update - RFC 5539bis: - The participants were in favor of adopting the document as WG item: 12 in favor, none opposed - The action items are: - announce on maillist that we accept it as a WG doc (done with this email) - AI: Badra submits a draft-ietf-netconf-5539bis-00 - There will 2 weeks for comments - The co-chairs will start then a WGLC. Netconf Lite: - The participants were in favor of adopting the document as WG item: 14 in favor 1 opposed - Use of DTLS as a transport for Netconf-Lite would require the development of a new transport binding. This is not part of our work now. - Another document name has been suggested: netconf-core (the document title can be decided later), - The co-chairs asked for showing hands concerning the intended status of the document:=20 5 persons are in favor of developing an Experimental document 8 persons are in favor of having a standard track document - So the co-chairs assume we have rough consensus for STDS track. - Charter can say develop a modular netconf-lite - The current document with agreed changes can be used as a starting WG document.=20 AI: The authors are asked to submit draft-ietf-netconf-lite-00. - The sentence about Coman activity in the charter text will be removed. - Yangyfying rfc5277 (notifications) - Nobody in the session was in favor of yangyfying the RFC 5277 only. People rather would like to open an 5277bis and solved different issues. - However, the WG is not eager to do it now. - This document will be removed from the WG charter proposal. Making BEEP and SOAP transports historic: - 12 persons are in favor, opposed 0 - This will be made part of the charter. - Juergen brought in the request for a "get state" mechanism. - The WG agrees that a discussion is needed first. Describing the issue and a problem statement with an individual I-D would be good. We can discuss the problem statement and potential solutions. Report on implementation/deployment of Netconf + SSH transport - 8 persons are in favor, none opposed Advancing Netconf 1.1 and SSH transport: - 7 persons are in favor, none opposed - The co-chairs will add this as a charter item to advance the RFC 6241 and 6242. - Question whether people are in favor of the charter in concept as presented: 12 in favor, none opposed Netconf over Websocket: - WG chairs believe that after many presentations and individual I-Ds there is insufficient support in the WG to work on this (2 in favor, 2 opposed, 3 abstains). - The author is advised to submit as individual document if he wants it published as an RFC. - We had some discussion on YANG API, but not enough time and not mature enough. - Did not have time to discuss YANG conformance issues. Bert & Mehmet From pgili@cisco.com Wed Aug 1 14:49:20 2012 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 9E53311E829B for ; Wed, 1 Aug 2012 14:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZwZJYO5Ye9O for ; Wed, 1 Aug 2012 14:49:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 25F4111E82C5 for ; Wed, 1 Aug 2012 14:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=6993; q=dns/txt; s=iport; t=1343857758; x=1345067358; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Nza+4RmvuCT9ERA8zvTM5JMktmsK77cNKSxSnsuR76Y=; b=dEAeMtfod5s67w5iIpdcTPvzZOaNrY+Wgq7PFdbmb29Al5XEF3CeoyiP kmhc/PoctuoE9McJ5k+0QEH4+owz3dKdyFjPF52uCMHFDJNyv1X5q0q6V 9dvIPxqhF5itvh958dStSBHjDGlkDq9cS9FA/uxHw8TjrOWRN5IfNwbfk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAK6jGVCtJXG9/2dsb2JhbABFuRGBB4IgAQEBBAEBAQ8BJzQXBAIBCA4DAQMBAQsCEgkHJwsUAwYIAgQBCQkIARIHhW+BfAuccaBAi0kahg9gA6NugWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,696,1336348800"; d="scan'208";a="107652135" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2012 21:49:17 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71LnFBS017774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 21:49:15 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.145]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 16:49:14 -0500 From: "Patrick Gili (pgili)" To: Bert Wijnen , netconf Thread-Topic: [Netconf] new draft charter - Action before Aug 15th Thread-Index: AQHNcC3WST6P3FzqtUi1wArtY4rot5dFe9/Q Date: Wed, 1 Aug 2012 21:49:13 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB029878@xmb-aln-x14.cisco.com> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> In-Reply-To: <5019A186.2030808@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.245.76] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--41.784500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:49:20 -0000 Hi Bert, We'd like to see something in the charter regarding work on additional mess= age models. Most importantly, we'd like to see an effort to standardize a N= ETCONF-like interface that uses REST, such as that proposed by Andy Bierman= in draft-bierman-netconf-yang-api-00. However, we would also like to explo= re the possibility of using XMPP/JSON as a message model. This also raises the question whether the NETCONF WG should explore partiti= oning the NETCONF architecture in a manner similar to the architecture intr= oduced with SNMPv3, separating the message processor, access control, RPC p= rocessors, and notification processor, increasing the modularity of NETCONF= . Cheers, Patrick Gili -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Bert Wijnen Sent: Wednesday, August 01, 2012 5:37 PM To: netconf Subject: [Netconf] new draft charter - Action before Aug 15th WG participants, based on our discussions at IETF84, we (WG chairs) propos= e the following new charter text. Pls comment and let us know your opinion no later than August 15th (any tim= ezone). Bert and Mehmet ------ proposed charter as of Augist 1st) --------- Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Ronald Bonica Benoit Claise Operations and Management Area Advisor: Benoit Claise Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org or: 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 interoperable networks. Operators from large to small have developed their own mechanisms or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining 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 Working Group has produced a protocol suitable for network configuration, with 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 has been designed independent of the data modeling language. The IETF recommends to use YANG as the NETCONF modeling language, which introduces advanced language features for configuration management. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. To enable an implementation with a reduced code-size, there seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. in constrained devices or for an incremental deployment. The WG will create a document defining the minimal base of features for such a standard. The exact title of Netconf-Lite can be determined by the WG. 3. Based on the implementation and deployment experience, the WG will document the status of NETCONF in order to advance the base documents (at least RFC6241 and RFC6242) on the standards track. 4. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Stan= dard done - WG Last Call on rfc4741bis done - rfc4741bis to IESG for consideration as Proposed Standard done - Send rfc4742bis to IESG for consideration as proposed Standar= d. done - first WG draft (rev 00) on NACM posted done - first WG draft (rev 00) on NETCONF specific YANG modules post= ed done - WGLC for NACM document done - WGLC for NETCONF specific notifications document done - submit NACM document to IESG for consideration as Proposed St= andard done - submit NETCONF specific notifications document to IESG for c= onsideration as Proposed Standard aug 2012 - submit initial WG draft for rfc5539bis aug 2012 - submit initial WG draft for Netconf Lite aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 histor= ic. sep 2012 - WGLC for rfc5539bis sep 2012 - WGLC for RFC4743 and 4743 to historic okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed St= andard okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 624= 2 nov 2012 - WGLC for Netconf Lite nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experi= ence jan 2013 - second WGLC for Netconf Lite (if needed) jan 2013 - WGLC on RFC6241/6242 document to advance on standards track feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed = Standard feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standard= s Track _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Aug 1 14:51:54 2012 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 740A511E829B for ; Wed, 1 Aug 2012 14:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.193, 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 DPfJo4wcL0d0 for ; Wed, 1 Aug 2012 14:51:53 -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 6DFA911E8235 for ; Wed, 1 Aug 2012 14:51:53 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 187D21200D65; Wed, 1 Aug 2012 23:51:50 +0200 (CEST) Date: Wed, 01 Aug 2012 14:51:48 -0700 (PDT) Message-Id: <20120801.145148.292400217.mbj@tail-f.com> To: bwijnen@ripe.net From: Martin Bjorklund In-Reply-To: <5019A186.2030808@ripe.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:51:54 -0000 Bert Wijnen wrote: > 2. To enable an implementation with a reduced code-size, > there seems to be a need for a modular NETCONF solution > (Netconf-Lite), which can be used e.g. in constrained > devices or for an incremental deployment. > The WG will create a document defining the minimal base > of features for such a standard. The exact title of > Netconf-Lite can be determined by the WG. A couple of comments. 1. Doing this as a standards track document will be confusing. Why do we have two standards doing almost the same thing? If we really believe this is a useful standard, why not change base:1.1? 2. The motivation for this work as stated is to be suitable for constrained devices. AFAIK there is one implementation of this, and the implementor was not sure that this is the right solution for constrained devices. I wasn't supporting or opposing this work in the meeting, but after giving it some more thought, I am opposed to doing this. /martin From bwijnen@ripe.net Wed Aug 1 14:56:10 2012 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 E069A11E817E for ; Wed, 1 Aug 2012 14:56:10 -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 BDzeLJDAUXqi for ; Wed, 1 Aug 2012 14:56:10 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 47A3111E813A for ; Wed, 1 Aug 2012 14:56:10 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swgtk-0001kj-4R; Wed, 01 Aug 2012 23:56:09 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Swgtj-0000Sl-Mk; Wed, 01 Aug 2012 23:56:08 +0200 Message-ID: <5019A5F6.3060201@ripe.net> Date: Wed, 01 Aug 2012 14:56:06 -0700 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Bjorklund References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801.145148.292400217.mbj@tail-f.com> In-Reply-To: <20120801.145148.292400217.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120801 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e8b5311fecba3c206ff5ce903ac774204 Cc: netconf@ietf.org Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:56:11 -0000 On 8/1/12 2:51 PM, Martin Bjorklund wrote: > 2. The motivation for this work as stated is to be suitable for > constrained devices. AFAIK there is one implementation of this, > and the implementor was not sure that this is the right solution > for constrained devices. So maybe we should change which can be used e.g. in constrained devices or for an incremental deployment. into which MIGHT be used e.g. in constrained devices or for an incremental deployment. might in lowercase of course, used capitals to show the change. Bert From j.schoenwaelder@jacobs-university.de Wed Aug 1 14:56:14 2012 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 5961D11E832A for ; Wed, 1 Aug 2012 14:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 nJ5mV4efPbb3 for ; Wed, 1 Aug 2012 14:56:13 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14F11E831E for ; Wed, 1 Aug 2012 14:56:13 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B67A20BDE; Wed, 1 Aug 2012 23:56:12 +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 NIrzPRLDY0TO; Wed, 1 Aug 2012 23:56:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A61420BDB; Wed, 1 Aug 2012 23:56:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D71962100178; Wed, 1 Aug 2012 23:56:09 +0200 (CEST) Date: Wed, 1 Aug 2012 23:56:09 +0200 From: Juergen Schoenwaelder To: Bert Wijnen Message-ID: <20120801215609.GA84384@elstar.local> Mail-Followup-To: Bert Wijnen , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5019A186.2030808@ripe.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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: Wed, 01 Aug 2012 21:56:14 -0000 On Wed, Aug 01, 2012 at 02:37:10PM -0700, Bert Wijnen wrote: > WG participants, based on our discussions at IETF84, > we (WG chairs) propose the following new charter text. > > Pls comment and let us know your opinion no later than > August 15th (any timezone). Do we have to respin RFC 6241 to advance it? I think there is an open errata. (And if we do more interoperability testing, there might even be more errata coming along.) I am concerned that we might leave a confusing impression if we do all of the below more or less at the same time: - publish a revision of RFC 6241 to advance it - publish a competitor to RFC 6241(bis) called NC Lite - publish an extension (to both?) solving the get operational state issue Perhaps we need to rethink the isolated decision and look at the overall direction we want to go. And perhaps bundling all the above into a single revision of RFC 6241 (which later might advance without a further revision) is overall simpler and less confusing. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bwijnen@ripe.net Wed Aug 1 14:57:32 2012 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 B67DC11E831E for ; Wed, 1 Aug 2012 14:57:32 -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 d1BAcC-qUplc for ; Wed, 1 Aug 2012 14:57:31 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4F011E831B for ; Wed, 1 Aug 2012 14:57:31 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swgv2-0000Jp-9u; Wed, 01 Aug 2012 23:57:30 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Swgv1-0000ZP-PK; Wed, 01 Aug 2012 23:57:28 +0200 Message-ID: <5019A646.5060603@ripe.net> Date: Wed, 01 Aug 2012 14:57:26 -0700 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Patrick Gili (pgili)" References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <50E64ADF99EAEE4CACEC18958F0FC0AB029878@xmb-aln-x14.cisco.com> In-Reply-To: <50E64ADF99EAEE4CACEC18958F0FC0AB029878@xmb-aln-x14.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120801 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e6f46113cc99a6f7f53a29235c199b1f9 Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:57:32 -0000 Understood. But see thesummary of our meeting posted by Mehmet. We do not have a base document yet that is mature enough to start our work in this space. Bert On 8/1/12 2:49 PM, Patrick Gili (pgili) wrote: > Hi Bert, > > We'd like to see something in the charter regarding work on additional message models. Most importantly, we'd like to see an effort to standardize a NETCONF-like interface that uses REST, such as that proposed by Andy Bierman in draft-bierman-netconf-yang-api-00. However, we would also like to explore the possibility of using XMPP/JSON as a message model. > > This also raises the question whether the NETCONF WG should explore partitioning the NETCONF architecture in a manner similar to the architecture introduced with SNMPv3, separating the message processor, access control, RPC processors, and notification processor, increasing the modularity of NETCONF. > > Cheers, > Patrick Gili > > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen > Sent: Wednesday, August 01, 2012 5:37 PM > To: netconf > Subject: [Netconf] new draft charter - Action before Aug 15th > > WG participants, based on our discussions at IETF84, we (WG chairs) propose the following new charter text. > > Pls comment and let us know your opinion no later than August 15th (any timezone). > > Bert and Mehmet > > ------ proposed charter as of Augist 1st) --------- > > Network Configuration (netconf) > ------------------------------- > > Charter > > Current Status: Active > > Chairs: > Bert Wijnen > Mehmet Ersue > > Operations and Management Area Directors: > Ronald Bonica > Benoit Claise > > Operations and Management Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: netconf@ietf.org > To Subscribe: netconf-request@ietf.org > or: 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 interoperable networks. Operators from > large to small have developed their own mechanisms or used vendor > specific mechanisms to transfer configuration data to and from a > device, and for examining 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 Working Group has produced a protocol suitable for > network configuration, with 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 has been designed independent of the data modeling > language. The IETF recommends to use YANG as the NETCONF modeling > language, which introduces advanced language features for configuration > management. > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. To enable an implementation with a reduced code-size, > there seems to be a need for a modular NETCONF solution > (Netconf-Lite), which can be used e.g. in constrained > devices or for an incremental deployment. > The WG will create a document defining the minimal base > of features for such a standard. The exact title of > Netconf-Lite can be determined by the WG. > > 3. Based on the implementation and deployment experience, the WG > will document the status of NETCONF in order to advance the > base documents (at least RFC6241 and RFC6242) on the standards > track. > > 4. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > aug 2012 - submit initial WG draft for rfc5539bis > aug 2012 - submit initial WG draft for Netconf Lite > aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > sep 2012 - WGLC for rfc5539bis > sep 2012 - WGLC for RFC4743 and 4743 to historic > okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > nov 2012 - WGLC for Netconf Lite > nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > jan 2013 - second WGLC for Netconf Lite (if needed) > jan 2013 - WGLC on RFC6241/6242 document to advance on standards track > feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed Standard > feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards Track > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Aug 1 14:59:28 2012 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 B639E11E831B for ; Wed, 1 Aug 2012 14:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgy4yR0DVyyA for ; Wed, 1 Aug 2012 14:59:27 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91F7811E830D for ; Wed, 1 Aug 2012 14:59:27 -0700 (PDT) Received: by qadz3 with SMTP id z3so2899825qad.10 for ; Wed, 01 Aug 2012 14:59:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PkWCVKfWd/x+PWBXAdzsGBFcOEUNKg8g1BQtpHcMZFI=; b=YyqBox7SrGUCHwxMdDMktyfGBxCKl3kXhGz4JWkutgwwGdxpN1wZ/ygN1iP7nbxZuT nMbDSGGdMF6g3sCwNg7hshYQ8uylVG4Of24EepAv9kyw1v2R/hs4zlaHofPZ/JT8rpph IWV4H2UOFVZjUml6qDZz0m1iAhB48qBWLgOtaZN9HoFjd+uoUbi9/KQzynQ+tTbQ0x+N th88wgW0ZQ0Qzz7Uxx3eNrm7M9Gz3T6cikw3TNOZV7mxUPYeKN+ThrSfaDFcNVxlBHMM ZtCj1+E/Xuiq1Zx7WLE7mvoH/qG3uC5ssdOUCLfPtvBMhESGnHzh5YKO58e3v5F6A7Io xpXA== MIME-Version: 1.0 Received: by 10.224.213.74 with SMTP id gv10mr38371491qab.25.1343858366920; Wed, 01 Aug 2012 14:59:26 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 14:59:26 -0700 (PDT) X-Originating-IP: [130.129.69.38] In-Reply-To: <5019A186.2030808@ripe.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> Date: Wed, 1 Aug 2012 14:59:26 -0700 Message-ID: From: Andy Bierman To: Bert Wijnen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl8Rqw8aHHQQ4Atdd7J5wsXertc0LOZ/uwvxSKryWew6BtS7EGKDNV/LqM7Sj62cfniYC6C Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:59:28 -0000 Hi, I am not objecting to NETCONF Light, but I have some concerns about this work. - the lack of coordination with COMAN If this work is for management of constrained devices (as it claims) then I do not understand how COMAN can possibly be left out of the equation - the assumption that a pure subset of NETCONF base:1.1 is the correct solution for constrained devices. The only implementor of NETCONF Light says this might not be the best solution. I would like to know more about this implementation experience. - the new client/old server problem: A client supporting all 3 versions of NETCONF needs to be able to connect to a server using the "correct" version, using just 1 session attempt. I don't think base:1.1 can just be ignored in this new work. - wrt/ protocol mechanics there is no difference between calling it NETCONF light or base:1.2. That is pure politics. If we really need to cycle at proposed standard to make the protocol work correctly, then this is more important than advancing 6241/6242 at this time Andy On Wed, Aug 1, 2012 at 2:37 PM, Bert Wijnen wrote: > WG participants, based on our discussions at IETF84, > we (WG chairs) propose the following new charter text. > > Pls comment and let us know your opinion no later than > August 15th (any timezone). > > Bert and Mehmet > > ------ proposed charter as of Augist 1st) --------- > > Network Configuration (netconf) > ------------------------------- > > Charter > > Current Status: Active > > Chairs: > Bert Wijnen > Mehmet Ersue > > Operations and Management Area Directors: > Ronald Bonica > Benoit Claise > > Operations and Management Area Advisor: > Benoit Claise > > Mailing Lists: > General Discussion: netconf@ietf.org > To Subscribe: netconf-request@ietf.org > or: 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 interoperable networks. Operators from > large to small have developed their own mechanisms or used vendor > specific mechanisms to transfer configuration data to and from a > device, and for examining 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 Working Group has produced a protocol suitable for > network configuration, with 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 has been designed independent of the data modeling > language. The IETF recommends to use YANG as the NETCONF modeling > language, which introduces advanced language features for configuration > management. > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. To enable an implementation with a reduced code-size, > there seems to be a need for a modular NETCONF solution > (Netconf-Lite), which can be used e.g. in constrained > devices or for an incremental deployment. > The WG will create a document defining the minimal base > of features for such a standard. The exact title of > Netconf-Lite can be determined by the WG. > > 3. Based on the implementation and deployment experience, the WG > will document the status of NETCONF in order to advance the > base documents (at least RFC6241 and RFC6242) on the standards > track. > > 4. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed > Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > aug 2012 - submit initial WG draft for rfc5539bis > aug 2012 - submit initial WG draft for Netconf Lite > aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > sep 2012 - WGLC for rfc5539bis > sep 2012 - WGLC for RFC4743 and 4743 to historic > okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed > Standard > okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > nov 2012 - WGLC for Netconf Lite > nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > jan 2013 - second WGLC for Netconf Lite (if needed) > jan 2013 - WGLC on RFC6241/6242 document to advance on standards track > feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed > Standard > feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards > Track > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bwijnen@ripe.net Wed Aug 1 14:59:38 2012 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 91C3C11E837F for ; Wed, 1 Aug 2012 14:59:38 -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.000, 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 OtIxA5-fddV8 for ; Wed, 1 Aug 2012 14:59:38 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6311E8376 for ; Wed, 1 Aug 2012 14:59:37 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swgx6-0001ok-94 for netconf@ietf.org; Wed, 01 Aug 2012 23:59:37 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-53c6.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Swgx5-0000ho-Rt for netconf@ietf.org; Wed, 01 Aug 2012 23:59:36 +0200 Message-ID: <5019A6C6.3070606@ripe.net> Date: Wed, 01 Aug 2012 14:59:34 -0700 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> In-Reply-To: <20120801215609.GA84384@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120801 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885eaf377429e7fb3936947e6fb033d53762 Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 21:59:38 -0000 On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: > Perhaps we need to rethink the isolated decision and look at the > overall direction we want to go. And perhaps bundling all the above > into a single revision of RFC 6241 (which later might advance without > a further revision) is overall simpler and less confusing. I believe we did indeed discuss this in our session, and the outcome was that the majority of people want to advance 6241/42. People who were not present and want to state an opinion, by all means, please do so. Bert From j.schoenwaelder@jacobs-university.de Wed Aug 1 15:06:10 2012 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 A258E11E830D for ; Wed, 1 Aug 2012 15:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.2 X-Spam-Level: X-Spam-Status: No, score=-103.2 tagged_above=-999 required=5 tests=[AWL=0.049, 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 o10hJlEZ-pag for ; Wed, 1 Aug 2012 15:06:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C145511E817E for ; Wed, 1 Aug 2012 15:06:09 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 144DA20BEE; Thu, 2 Aug 2012 00:06:09 +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 DDtogadmYTKx; Thu, 2 Aug 2012 00:06:08 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C93A420BDE; Thu, 2 Aug 2012 00:06:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B43121002F6; Thu, 2 Aug 2012 00:06:07 +0200 (CEST) Date: Thu, 2 Aug 2012 00:06:07 +0200 From: Juergen Schoenwaelder To: Bert Wijnen Message-ID: <20120801220607.GC84384@elstar.local> Mail-Followup-To: Bert Wijnen , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <5019A6C6.3070606@ripe.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5019A6C6.3070606@ripe.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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: Wed, 01 Aug 2012 22:06:10 -0000 On Wed, Aug 01, 2012 at 02:59:34PM -0700, Bert Wijnen wrote: > On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: > >Perhaps we need to rethink the isolated decision and look at the > >overall direction we want to go. And perhaps bundling all the above > >into a single revision of RFC 6241 (which later might advance without > >a further revision) is overall simpler and less confusing. > > I believe we did indeed discuss this in our session, and the outcome > was that the majority of people want to advance 6241/42. We took polls on isolated questions and the result in combination looks, well, to some contributors somewhat surprising or not like a well thought out plan or whatever your preferred wording is. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Wed Aug 1 15:20:41 2012 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 8258711E8305 for ; Wed, 1 Aug 2012 15:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 JMaFjBKTM37V for ; Wed, 1 Aug 2012 15:20:40 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EF74311E82FF for ; Wed, 1 Aug 2012 15:20:39 -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 q71MKb7G031219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 00:20:38 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q71MKVYG019640; Thu, 2 Aug 2012 00:20:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 00:20:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Aug 2012 00:19:56 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404136A4F@DEMUEXC006.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] new draft charter - Action before Aug 15th Thread-Index: Ac1wMO6NuA+iWjRHT6+qArUAayY3/gAAWyQw References: <501973A2.4020900@ripe.net><5019A186.2030808@ripe.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Bert Wijnen" X-OriginalArrivalTime: 01 Aug 2012 22:20:02.0749 (UTC) FILETIME=[CBBE1ED0:01CD7033] 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: 8659 X-purgate-ID: 151667::1343859638-00002E58-7A77CB4E/0-0/0-0 Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 22:20:41 -0000 We by no means aim to address the management needs of constrained devices in the Netconf WG. Netconf-Lite (or whatever you call it) is just for one single purpose, namely reducing the code size with modular implementations. We assume that this _could_ be useful for small devices _or_ for incremental deployment. That said I don't think Netconf-Lite is a competition to base 1.1. If advancing Netconf 1.1 is not an urgent issue my personal suggestion would be to do it as 1.2. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Andy Bierman > Sent: Wednesday, August 01, 2012 2:59 PM > To: Bert Wijnen > Cc: netconf > Subject: Re: [Netconf] new draft charter - Action before Aug 15th >=20 > Hi, >=20 > I am not objecting to NETCONF Light, but I have some concerns > about this work. > - the lack of coordination with COMAN > If this work is for management of constrained devices (as it claims) > then I do not understand how COMAN can possibly be left out > of the equation >=20 > - the assumption that a pure subset of NETCONF base:1.1 is the > correct solution for constrained devices. The only implementor > of NETCONF Light says this might not be the best solution. > I would like to know more about this implementation experience. >=20 > - the new client/old server problem: A client supporting all 3 versions > of NETCONF needs to be able to connect to a server using the > "correct" version, using just 1 session attempt. I don't think base:1.1 > can just be ignored in this new work. >=20 > - wrt/ protocol mechanics there is no difference between calling it > NETCONF light or base:1.2. That is pure politics. If we really need > to cycle at proposed standard to make the protocol work correctly, then this > is more important than advancing 6241/6242 at this time >=20 > Andy >=20 >=20 >=20 >=20 > On Wed, Aug 1, 2012 at 2:37 PM, Bert Wijnen wrote: > > WG participants, based on our discussions at IETF84, > > we (WG chairs) propose the following new charter text. > > > > Pls comment and let us know your opinion no later than > > August 15th (any timezone). > > > > Bert and Mehmet > > > > ------ proposed charter as of Augist 1st) --------- > > > > Network Configuration (netconf) > > ------------------------------- > > > > Charter > > > > Current Status: Active > > > > Chairs: > > Bert Wijnen > > Mehmet Ersue > > > > Operations and Management Area Directors: > > Ronald Bonica > > Benoit Claise > > > > Operations and Management Area Advisor: > > Benoit Claise > > > > Mailing Lists: > > General Discussion: netconf@ietf.org > > To Subscribe: netconf-request@ietf.org > > or: 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 interoperable networks. Operators from > > large to small have developed their own mechanisms or used vendor > > specific mechanisms to transfer configuration data to and from a > > device, and for examining 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 Working Group has produced a protocol suitable for > > network configuration, with 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 has been designed independent of the data modeling > > language. The IETF recommends to use YANG as the NETCONF modeling > > language, which introduces advanced language features for configuration > > management. > > > > In the current phase of the incremental development of NETCONF the > > workgroup will focus on following items: > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > This means that RFC5593 needs to be updated. > > > > 2. To enable an implementation with a reduced code-size, > > there seems to be a need for a modular NETCONF solution > > (Netconf-Lite), which can be used e.g. in constrained > > devices or for an incremental deployment. > > The WG will create a document defining the minimal base > > of features for such a standard. The exact title of > > Netconf-Lite can be determined by the WG. > > > > 3. Based on the implementation and deployment experience, the WG > > will document the status of NETCONF in order to advance the > > base documents (at least RFC6241 and RFC6242) on the standards > > track. > > > > 4. Since Netconf over BEEP and over SOAP seem not being deployed > > the WG will write a document that makes those 2 protocols > > (RFC4743 and RFC4744) HISTORIC. > > > > Goals and Milestones: > > done - Send with-defaults to IESG for consideration as Proposed > > Standard > > done - WG Last Call on rfc4741bis > > 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 NACM posted > > 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 > > aug 2012 - submit initial WG draft for rfc5539bis > > aug 2012 - submit initial WG draft for Netconf Lite > > aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > > historic. > > sep 2012 - WGLC for rfc5539bis > > sep 2012 - WGLC for RFC4743 and 4743 to historic > > okt 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed > > Standard > > okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > > okt 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > > nov 2012 - WGLC for Netconf Lite > > nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment > > experience > > jan 2013 - second WGLC for Netconf Lite (if needed) > > jan 2013 - WGLC on RFC6241/6242 document to advance on standards track > > feb 2013 - submit Netconf Lite to AD/IESG for consideration as Proposed > > Standard > > feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on Standards > > Track > > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Wed Aug 1 15:29:07 2012 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 A829C11E82FF for ; Wed, 1 Aug 2012 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvTNstOZnQOd for ; Wed, 1 Aug 2012 15:29:06 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8E111E8351 for ; Wed, 1 Aug 2012 15:29:06 -0700 (PDT) Received: by qcac10 with SMTP id c10so5363070qca.31 for ; Wed, 01 Aug 2012 15:29:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=R/uTzrwzWHi363pjgHMI27fFuwoCqb98W9KxXvC4hHo=; b=IDR2hJhJGsSXkW+zpiBGM8QysJJhbksn+T/vAX35ENIsfMSxtUh2P/FcR1zDzrbGk1 FT8W25YEitKwRP8MKcEw5DTplKdDx/rX7LqIMIdK/EE8ZVkoyFLIlkzIyoPgs/IEwOqG /HEBJ7vhsTLa2BbDcBRAsUmIv751iocD1R48G4rke4R6PYlK3Bt68ZbQXYJvUhNufizV 2O/mimmRcbVRH8soVNHGdiPxQ77aT9U613cE3EDgaHRtcx+4mpFKIGolB1B93NrLPx6Z EnNFSMPrRD060q0yO8MjDby0e9chiZmrN5tWZW16xu/7a0L8F6Fg46XN3n3q3XL4Hc8p wZNQ== MIME-Version: 1.0 Received: by 10.224.105.193 with SMTP id u1mr38585995qao.85.1343860145664; Wed, 01 Aug 2012 15:29:05 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 15:29:05 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:6914:a467:4542:31fb] In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A6404136A4F@DEMUEXC006.nsn-intra.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <80A0822C5E9A4440A5117C2F4CD36A6404136A4F@DEMUEXC006.nsn-intra.net> Date: Wed, 1 Aug 2012 15:29:05 -0700 Message-ID: From: Andy Bierman To: "Ersue, Mehmet (NSN - DE/Munich)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlYF9qyyjtvVbTXASQzq7cATfQLUWVO/GVMNcmqvIJzJxOMFZqAo0D2ZHvoWEhgozLgVJcD Cc: Bert Wijnen , netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 01 Aug 2012 22:29:07 -0000 On Wed, Aug 1, 2012 at 3:19 PM, Ersue, Mehmet (NSN - DE/Munich) wrote: > We by no means aim to address the management needs of constrained > devices in the Netconf WG. > Netconf-Lite (or whatever you call it) is just for one single purpose, > namely reducing the code size with modular implementations. > We assume that this _could_ be useful for small devices _or_ for > incremental deployment. I find the premise that you can reduce the code size be refactoring the protocol to be somewhat absurd. You can take out functionality and the protocol does less useful things. Whether this is progress or not is a subjective matter. > > That said I don't think Netconf-Lite is a competition to base 1.1. > If advancing Netconf 1.1 is not an urgent issue my personal suggestion > would be to do it as 1.2. > > Mehmet Andy > >> -----Original Message----- >> From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext >> Andy Bierman >> Sent: Wednesday, August 01, 2012 2:59 PM >> To: Bert Wijnen >> Cc: netconf >> Subject: Re: [Netconf] new draft charter - Action before Aug 15th >> >> Hi, >> >> I am not objecting to NETCONF Light, but I have some concerns >> about this work. >> - the lack of coordination with COMAN >> If this work is for management of constrained devices (as it > claims) >> then I do not understand how COMAN can possibly be left out >> of the equation >> >> - the assumption that a pure subset of NETCONF base:1.1 is the >> correct solution for constrained devices. The only implementor >> of NETCONF Light says this might not be the best solution. >> I would like to know more about this implementation experience. >> >> - the new client/old server problem: A client supporting all 3 > versions >> of NETCONF needs to be able to connect to a server using the >> "correct" version, using just 1 session attempt. I don't think > base:1.1 >> can just be ignored in this new work. >> >> - wrt/ protocol mechanics there is no difference between calling it >> NETCONF light or base:1.2. That is pure politics. If we really > need >> to cycle at proposed standard to make the protocol work correctly, > then this >> is more important than advancing 6241/6242 at this time >> >> Andy >> >> >> >> >> On Wed, Aug 1, 2012 at 2:37 PM, Bert Wijnen wrote: >> > WG participants, based on our discussions at IETF84, >> > we (WG chairs) propose the following new charter text. >> > >> > Pls comment and let us know your opinion no later than >> > August 15th (any timezone). >> > >> > Bert and Mehmet >> > >> > ------ proposed charter as of Augist 1st) --------- >> > >> > Network Configuration (netconf) >> > ------------------------------- >> > >> > Charter >> > >> > Current Status: Active >> > >> > Chairs: >> > Bert Wijnen >> > Mehmet Ersue >> > >> > Operations and Management Area Directors: >> > Ronald Bonica >> > Benoit Claise >> > >> > Operations and Management Area Advisor: >> > Benoit Claise >> > >> > Mailing Lists: >> > General Discussion: netconf@ietf.org >> > To Subscribe: netconf-request@ietf.org >> > or: > 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 interoperable networks. Operators > from >> > large to small have developed their own mechanisms or used vendor >> > specific mechanisms to transfer configuration data to and from a >> > device, and for examining 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 Working Group has produced a protocol suitable for >> > network configuration, with 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 has been designed independent of the data > modeling >> > language. The IETF recommends to use YANG as the NETCONF > modeling >> > language, which introduces advanced language features for > configuration >> > management. >> > >> > In the current phase of the incremental development of NETCONF the >> > workgroup will focus on following items: >> > >> > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >> > This means that RFC5593 needs to be updated. >> > >> > 2. To enable an implementation with a reduced code-size, >> > there seems to be a need for a modular NETCONF solution >> > (Netconf-Lite), which can be used e.g. in constrained >> > devices or for an incremental deployment. >> > The WG will create a document defining the minimal base >> > of features for such a standard. The exact title of >> > Netconf-Lite can be determined by the WG. >> > >> > 3. Based on the implementation and deployment experience, the WG >> > will document the status of NETCONF in order to advance the >> > base documents (at least RFC6241 and RFC6242) on the standards >> > track. >> > >> > 4. Since Netconf over BEEP and over SOAP seem not being deployed >> > the WG will write a document that makes those 2 protocols >> > (RFC4743 and RFC4744) HISTORIC. >> > >> > Goals and Milestones: >> > done - Send with-defaults to IESG for consideration as > Proposed >> > Standard >> > done - WG Last Call on rfc4741bis >> > 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 NACM posted >> > 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 >> > aug 2012 - submit initial WG draft for rfc5539bis >> > aug 2012 - submit initial WG draft for Netconf Lite >> > aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >> > historic. >> > sep 2012 - WGLC for rfc5539bis >> > sep 2012 - WGLC for RFC4743 and 4743 to historic >> > okt 2012 - submit rfc5539bis to AD/IESG for consideration as > Proposed >> > Standard >> > okt 2012 - submit request to AD/IESG to make RFC4743 and 4744 > historic >> > okt 2012 - Collect Implementation/Deployment reports for RFC6241 > and 6242 >> > nov 2012 - WGLC for Netconf Lite >> > nov 2012 - Initial I-D for RFC6241/6242 implementation/deployment >> > experience >> > jan 2013 - second WGLC for Netconf Lite (if needed) >> > jan 2013 - WGLC on RFC6241/6242 document to advance on standards > track >> > feb 2013 - submit Netconf Lite to AD/IESG for consideration as > Proposed >> > Standard >> > feb 2013 - submit request to AD/IESG to advance RFC6241/6242 on > Standards >> > Track >> > >> > >> > >> > >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Wed Aug 1 21:41:16 2012 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 42F8821F8853 for ; Wed, 1 Aug 2012 21:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sjaKJd2hes5 for ; Wed, 1 Aug 2012 21:41:15 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id CCAA321F8857 for ; Wed, 1 Aug 2012 21:41:12 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwnDi-0007rw-Cw for netconf@ietf.org; Thu, 02 Aug 2012 06:41:11 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-4451.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SwnDh-0002SL-ON for netconf@ietf.org; Thu, 02 Aug 2012 06:41:10 +0200 Message-ID: <501A04E4.9080008@bwijnen.net> Date: Wed, 01 Aug 2012 21:41:08 -0700 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> In-Reply-To: <20120801215609.GA84384@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120802 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b15628c6d062e107240dbaa3bdac7068 Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 04:41:16 -0000 Inline On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: > On Wed, Aug 01, 2012 at 02:37:10PM -0700, Bert Wijnen wrote: >> WG participants, based on our discussions at IETF84, >> we (WG chairs) propose the following new charter text. >> >> Pls comment and let us know your opinion no later than >> August 15th (any timezone). > > Do we have to respin RFC 6241 to advance it? I think there is an open > errata. (And if we do more interoperability testing, there might even > be more errata coming along.) > Yep we MUST fix any reported/open errata. But that is allowed as far as I understand the process. > I am concerned that we might leave a confusing impression if we do all > of the below more or less at the same time: > > - publish a revision of RFC 6241 to advance it > - publish a competitor to RFC 6241(bis) called NC Lite That was sort of the rough consensus during the meeting. That is why we propose in the charter text stds-track. But we (WG) can at any time decide that we rather see it published as Experimental as well > - publish an extension (to both?) solving the get operational > state issue > I thought we had tabled that one and are waiting for individual submission so we can start discussion. > Perhaps we need to rethink the isolated decision and look at the > overall direction we want to go. And perhaps bundling all the above > into a single revision of RFC 6241 (which later might advance without > a further revision) is overall simpler and less confusing. > I have no skin in this. If (as a result of this poll for comments on the proposed charter text) we see consensus forming on doing your suggestion... that is fine by me too. People just need to speak up and express their opinions. > /js > From bertietf@bwijnen.net Wed Aug 1 21:46:34 2012 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 3D82F11E80BA for ; Wed, 1 Aug 2012 21:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6iiB2XS7gsh for ; Wed, 1 Aug 2012 21:46:31 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C534121F8A40 for ; Wed, 1 Aug 2012 21:46:25 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwnIh-000842-Bm; Thu, 02 Aug 2012 06:46:21 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-4451.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SwnIg-0008WA-Ox; Thu, 02 Aug 2012 06:46:19 +0200 Message-ID: <501A0618.2000501@bwijnen.net> Date: Wed, 01 Aug 2012 21:46:16 -0700 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Bierman References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120802 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd402b76a196c2a24e86f9bbfc295763b43 Cc: Bert Wijnen , netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 04:46:34 -0000 Inline On 8/1/12 2:59 PM, Andy Bierman wrote: > Hi, > > I am not objecting to NETCONF Light, but I have some concerns > about this work. > - the lack of coordination with COMAN > If this work is for management of constrained devices (as it claims) > then I do not understand how COMAN can possibly be left out > of the equation > It does NOT claim that it will solve all COMAN problems. It states: 2. To enable an implementation with a reduced code-size, there seems to be a need for a modular NETCONF solution (Netconf-Lite), which can be used e.g. in constrained devices or for an incremental deployment. The WG will create a document defining the minimal base of features for such a standard. The exact title of Netconf-Lite can be determined by the WG. So "which can be used e.g. in constrained devices..." I have already offered to do s/can/might/ My understanding was that in our session we came to consensus that it is not our primary goal to address all COMAN requirements. > - the assumption that a pure subset of NETCONF base:1.1 is the > correct solution for constrained devices. The only implementor > of NETCONF Light says this might not be the best solution. > I would like to know more about this implementation experience. > Yep, see above > - the new client/old server problem: A client supporting all 3 versions > of NETCONF needs to be able to connect to a server using the > "correct" version, using just 1 session attempt. I don't think base:1.1 > can just be ignored in this new work. > You mentioned that in the NETCONF session. I thought we agreed that we can work out the details for that once we start the work in the WG. > - wrt/ protocol mechanics there is no difference between calling it > NETCONF light or base:1.2. That is pure politics. If we really need > to cycle at proposed standard to make the protocol work correctly, then this > is more important than advancing 6241/6242 at this time > So you switched your opinion too? Bert > Andy > From bertietf@bwijnen.net Wed Aug 1 21:48:26 2012 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 DF95C21F8A4E for ; Wed, 1 Aug 2012 21:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MsUSEao+oqe for ; Wed, 1 Aug 2012 21:48:25 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE4321F8A65 for ; Wed, 1 Aug 2012 21:48:22 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SwnKd-0002ZQ-Oo for netconf@ietf.org; Thu, 02 Aug 2012 06:48:20 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-4451.meeting.ietf.org) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SwnKd-0000Ba-9h for netconf@ietf.org; Thu, 02 Aug 2012 06:48:19 +0200 Message-ID: <501A0692.8040405@bwijnen.net> Date: Wed, 01 Aug 2012 21:48:18 -0700 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <5019A6C6.3070606@ripe.net> <20120801220607.GC84384@elstar.local> In-Reply-To: <20120801220607.GC84384@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120802 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd433c484931e60871054a910a37da315b6 Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 04:48:26 -0000 Inline On 8/1/12 3:06 PM, Juergen Schoenwaelder wrote: > On Wed, Aug 01, 2012 at 02:59:34PM -0700, Bert Wijnen wrote: >> On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: >>> Perhaps we need to rethink the isolated decision and look at the >>> overall direction we want to go. And perhaps bundling all the above >>> into a single revision of RFC 6241 (which later might advance without >>> a further revision) is overall simpler and less confusing. >> >> I believe we did indeed discuss this in our session, and the outcome >> was that the majority of people want to advance 6241/42. > > We took polls on isolated questions and the result in combination > looks, well, to some contributors somewhat surprising or not like a > well thought out plan or whatever your preferred wording is. > We showed the overall concept of the new charter text and conceptually I believe everyone supported that. But if people want to change their position, then pls do speak up. Bert > /js > From andy@yumaworks.com Wed Aug 1 23:07:42 2012 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 7705221F8B67 for ; Wed, 1 Aug 2012 23:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smgaQIekBk36 for ; Wed, 1 Aug 2012 23:07:41 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5E21F8B66 for ; Wed, 1 Aug 2012 23:07:41 -0700 (PDT) Received: by qcac10 with SMTP id c10so5527934qca.31 for ; Wed, 01 Aug 2012 23:07:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=R1KKmgHpdcbyUo1DZx07GdBX+7+ocxyPVzCjaaMisYI=; b=Kdd4jVKiH0bqBnVx1VH6X32cA0nknAieLdQfPeTSZGHNxo71eXgGHR4LZGNAZmqsxi eQ+qEMCYI3rRhu0hmdmv354CT1Q79Uj7CbvP3ono2mxEVsPCS5HIFzmq13LpTfSXSEgn T2/F8nf9hGb4j3fDutYoXwRk9GnYZU4mdAK6Ek7+c/D2GfhSdxiYZIad+b4t2PS9TF7d d1qMPNGlm8NU2scaLdZt7TikrVRxdqBgm4ph5el4ex7qPmreRhAkLBpou2xEW9eHvtSu DlI24kSIJ8c5vig+CNBKMiXok9XZIcgoajGjo7J4zrebQcOiRsOnotq/trU6yWGRiyU6 huOA== MIME-Version: 1.0 Received: by 10.224.213.74 with SMTP id gv10mr39936442qab.25.1343887660694; Wed, 01 Aug 2012 23:07:40 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 1 Aug 2012 23:07:40 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4559:c044:ab0b:ad52] In-Reply-To: <501A0618.2000501@bwijnen.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <501A0618.2000501@bwijnen.net> Date: Wed, 1 Aug 2012 23:07:40 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQniAA8x3sP9e133MgA5n4hyaZJGOYi02NqBD2aPsecRzK/CikoRyvqnKZB9lahA5Ok/3ctg Cc: Bert Wijnen , netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 06:07:42 -0000 On Wed, Aug 1, 2012 at 9:46 PM, Bert Wijnen (IETF) wrote: > Inline > > On 8/1/12 2:59 PM, Andy Bierman wrote: >> >> Hi, >> >> I am not objecting to NETCONF Light, but I have some concerns >> about this work. >> - the lack of coordination with COMAN >> If this work is for management of constrained devices (as it >> claims) >> then I do not understand how COMAN can possibly be left out >> of the equation >> > > It does NOT claim that it will solve all COMAN problems. > It states: > 2. To enable an implementation with a reduced code-size, > there seems to be a need for a modular NETCONF solution > (Netconf-Lite), which can be used e.g. in constrained > devices or for an incremental deployment. > The WG will create a document defining the minimal base > of features for such a standard. The exact title of > Netconf-Lite can be determined by the WG. > > So "which can be used e.g. in constrained devices..." > I have already offered to do s/can/might/ > My understanding was that in our session we came to consensus > that it is not our primary goal to address all COMAN requirements. > >> - the assumption that a pure subset of NETCONF base:1.1 is the >> correct solution for constrained devices. The only implementor >> of NETCONF Light says this might not be the best solution. >> I would like to know more about this implementation experience. >> > Yep, see above > >> - the new client/old server problem: A client supporting all 3 versions >> of NETCONF needs to be able to connect to a server using the >> "correct" version, using just 1 session attempt. I don't think >> base:1.1 >> can just be ignored in this new work. >> > You mentioned that in the NETCONF session. I thought we agreed that > we can work out the details for that once we start the work in the WG. > >> - wrt/ protocol mechanics there is no difference between calling it >> NETCONF light or base:1.2. That is pure politics. If we really need >> to cycle at proposed standard to make the protocol work correctly, >> then this >> is more important than advancing 6241/6242 at this time >> > > So you switched your opinion too? Not really. I want to advance 6241 but it is not as important as a workable solution for customers. I need to support tools that implement NETCONF. IMO the premises supporting NL are seriously flawed. Customers are not going to care about refactoring the protocol spec. They will care that the client is way slower now (because copy-config requires the entire config be retrieved, edited and replaced, or since there is no filtering the entire config always has to be retrieved and filtered on the client instead). The changes proposed for NL will have a huge negative impact on protocol performance. > > Bert > >> Andy >> > Andy From ietfc@btconnect.com Thu Aug 2 02:39:02 2012 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 2CE5D21F8E63 for ; Thu, 2 Aug 2012 02:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.693 X-Spam-Level: X-Spam-Status: No, score=-3.693 tagged_above=-999 required=5 tests=[AWL=-0.094, 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 ektAhPxWDomf for ; Thu, 2 Aug 2012 02:39:01 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8B97A21F8E61 for ; Thu, 2 Aug 2012 02:39:01 -0700 (PDT) Received: from mail200-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE014.bigfish.com (10.7.40.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 09:39:00 +0000 Received: from mail200-va3 (localhost [127.0.0.1]) by mail200-va3-R.bigfish.com (Postfix) with ESMTP id 5050560023D; Thu, 2 Aug 2012 09:39:00 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: PS-23(zz9371I542M1432Izz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail200-va3 (localhost.localdomain [127.0.0.1]) by mail200-va3 (MessageSwitch) id 1343900338768175_30909; Thu, 2 Aug 2012 09:38:58 +0000 (UTC) Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.251]) by mail200-va3.bigfish.com (Postfix) with ESMTP id B0218120225; Thu, 2 Aug 2012 09:38:58 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 09:38:58 +0000 Received: from AMXPRD0410HT003.eurprd04.prod.outlook.com (157.56.248.165) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.86.1; Thu, 2 Aug 2012 09:38:47 +0000 Message-ID: <01ef01cd7092$02c4cb00$4001a8c0@gateway.2wire.net> From: t.petch To: Mohamad Badra , References: Date: Thu, 2 Aug 2012 10:34:08 +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.248.165] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] Netconf over TLS (rfc5539bis) 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, 02 Aug 2012 09:39:02 -0000 Badra Your description of RFC822 names makes reference to a host part. This is incorrect - it should be a domain part, as per RFC822. Tom Petch ----- Original Message ----- From: "Mohamad Badra" To: Sent: Saturday, April 28, 2012 1:43 PM > Dear All, > > I just posted a revised version of the > document draft-badra-netconf-rfc5539bis > > http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-02.txt > > Your comments are highly appreciated. > > Best regards, > Badra > ------------------------------------------------------------------------ -------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From ietfc@btconnect.com Thu Aug 2 07:22:37 2012 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 4B9F721F868A for ; Thu, 2 Aug 2012 07:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, 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 tdZZQb2ZYcc4 for ; Thu, 2 Aug 2012 07:22:36 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 97F7021F8688 for ; Thu, 2 Aug 2012 07:22:36 -0700 (PDT) Received: from mail139-co1-R.bigfish.com (10.243.78.241) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 14:22:36 +0000 Received: from mail139-co1 (localhost [127.0.0.1]) by mail139-co1-R.bigfish.com (Postfix) with ESMTP id B959148032E; Thu, 2 Aug 2012 14:22:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT008.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432Izz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah304l) Received: from mail139-co1 (localhost.localdomain [127.0.0.1]) by mail139-co1 (MessageSwitch) id 1343917332918868_23369; Thu, 2 Aug 2012 14:22:12 +0000 (UTC) Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.228]) by mail139-co1.bigfish.com (Postfix) with ESMTP id 5D3D4DC00E8; Thu, 2 Aug 2012 14:22:01 +0000 (UTC) Received: from DB3PRD0702HT008.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 14:21:59 +0000 Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by pod51017.outlook.com (10.3.4.173) with Microsoft SMTP Server (TLS) id 14.15.86.1; Thu, 2 Aug 2012 14:21:46 +0000 Message-ID: <00c901cd70b9$8b8014a0$4001a8c0@gateway.2wire.net> From: t.petch To: Bert Wijnen , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net><20120801215609.GA84384@elstar.local> <5019A6C6.3070606@ripe.net> Date: Thu, 2 Aug 2012 15:17:13 +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.240.21] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 14:22:37 -0000 ----- Original Message ----- From: "Bert Wijnen" To: "netconf" Sent: Wednesday, August 01, 2012 10:59 PM > On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: > > Perhaps we need to rethink the isolated decision and look at the > > overall direction we want to go. And perhaps bundling all the above > > into a single revision of RFC 6241 (which later might advance without > > a further revision) is overall simpler and less confusing. > > I believe we did indeed discuss this in our session, and the outcome > was that the majority of people want to advance 6241/42. I believe that advancement of this, or of most protocols, is an irrelevant distraction, like changing the number of steps of advancement. Most people in this world have no awareness of the status, quite a few equate I-D to a standard. Yes, I have heard on IETF lists of a few organisations which do treat the change in status as material but to me it seems to be more about the status of those involved:-( So, an academic issue (unlike producing a better 'base and towers' model, where the base is suitable for devices that are not multicore, multiGHz workstations:-) Tom Petch > People who were not present and want to state an opinion, by all > means, please do so. > > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Thu Aug 2 07:47:10 2012 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 D2AEA11E80A6 for ; Thu, 2 Aug 2012 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=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 m7D0Kzul02Wi for ; Thu, 2 Aug 2012 07:47:10 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E053A11E8072 for ; Thu, 2 Aug 2012 07:47:09 -0700 (PDT) Received: by qaea16 with SMTP id a16so1243101qae.10 for ; Thu, 02 Aug 2012 07:47:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/tmCVL+nI+xdZ32nHIqeAC029YA4nDhIf+PKB06Nxoc=; b=Z4JWJ86LtVCF7f4jl/12i2fyRwNBkeBnyp4EiAl2ri0IUJOv43wELAfU07Y8oV5S8S xjtmOl4hIlsAnNtGMaVJszCyuoogD2c02MZoB2TAuDVr/QhUtTUxcg9xfbRlUdAvt9rA jmHLly6KJOsyQm/Q9r3QQYLAeuLcFMHfvSuECxWfUfvdxRqEh9yE8NsuAkeeIj/A0LjE lGWKT4jrmYwbH0RONc5eb5777PwTt8mX1gdvh8bnljCS26pxNNKNCdhKFSGOCZt+7LMl WZskZZ+xqLn3mUh9N5GTIi8kHxRK+BLRYqR24z5A6PJUO8F7w5juJciA3aQu/OvTNdWe 0/OA== MIME-Version: 1.0 Received: by 10.224.175.6 with SMTP id v6mr19166233qaz.36.1343918829298; Thu, 02 Aug 2012 07:47:09 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 07:47:09 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:4559:c044:ab0b:ad52] In-Reply-To: <00c901cd70b9$8b8014a0$4001a8c0@gateway.2wire.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <5019A6C6.3070606@ripe.net> <00c901cd70b9$8b8014a0$4001a8c0@gateway.2wire.net> Date: Thu, 2 Aug 2012 07:47:09 -0700 Message-ID: From: Andy Bierman To: "t.petch" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlanF3QfhIvObPHfpU/Rsft1Q/1ADUXeUSYh4LrXuaLoBfCO3IhUg/a/k85RgRnmYir6ZDp Cc: Bert Wijnen , netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 14:47:11 -0000 On Thu, Aug 2, 2012 at 7:17 AM, t.petch wrote: > ----- Original Message ----- > From: "Bert Wijnen" > To: "netconf" > Sent: Wednesday, August 01, 2012 10:59 PM > >> On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: >> > Perhaps we need to rethink the isolated decision and look at the >> > overall direction we want to go. And perhaps bundling all the above >> > into a single revision of RFC 6241 (which later might advance > without >> > a further revision) is overall simpler and less confusing. >> >> I believe we did indeed discuss this in our session, and the outcome >> was that the majority of people want to advance 6241/42. > > I believe that advancement of this, or of most protocols, is an > irrelevant distraction, like changing the number of steps of > advancement. > > Most people in this world have no awareness of the status, quite a few > equate I-D to a standard. Yes, I have heard on IETF lists of a few > organisations which do treat the change in status as material but to me > it seems to be more about the status of those involved:-( > > So, an academic issue (unlike producing a better 'base and towers' > model, where the base is suitable for devices that are not multicore, > multiGHz workstations:-) > You know what is not academic? Interoperability. IMO, most NETCONF server implementations are somewhat broken. The WG can ignore artificial standards classifications if it wants, but advancement requires that interoperability testing be done -- something the WG has completely ignored from the start. We have a core + towers approach now. Some people think locking and filtering are much too complicated to implement so we are going to work on making the core smaller. Since the general implementation quality is so poor, I am forced to consider the possibility that we over-reached with NETCONF and need to lower our expectations (and reduce the mandatory feature set). > Tom Petch Andy > >> People who were not present and want to state an opinion, by all >> means, please do so. >> >> Bert >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From ietfc@btconnect.com Thu Aug 2 10:36:44 2012 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 BD66D21E810F for ; Thu, 2 Aug 2012 10:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_15=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 Fm6tx-qx4GGK for ; Thu, 2 Aug 2012 10:36:44 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0519121E8104 for ; Thu, 2 Aug 2012 10:36:43 -0700 (PDT) Received: from mail94-co1-R.bigfish.com (10.243.78.232) by CO1EHSOBE004.bigfish.com (10.243.66.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 2 Aug 2012 17:36:43 +0000 Received: from mail94-co1 (localhost [127.0.0.1]) by mail94-co1-R.bigfish.com (Postfix) with ESMTP id 094C93C02F6; Thu, 2 Aug 2012 17:36:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M1432Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839h93fhd24hf0ah107ah304l) Received: from mail94-co1 (localhost.localdomain [127.0.0.1]) by mail94-co1 (MessageSwitch) id 1343929000892957_8866; Thu, 2 Aug 2012 17:36:40 +0000 (UTC) Received: from CO1EHSMHS021.bigfish.com (unknown [10.243.78.232]) by mail94-co1.bigfish.com (Postfix) with ESMTP id CC1244E0049; Thu, 2 Aug 2012 17:36:40 +0000 (UTC) Received: from DB3PRD0702HT005.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS021.bigfish.com (10.243.66.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 2 Aug 2012 17:36:38 +0000 Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by pod51017.outlook.com (10.3.4.160) with Microsoft SMTP Server (TLS) id 14.15.108.4; Thu, 2 Aug 2012 17:36:25 +0000 Message-ID: <023001cd70d4$bc7b7e80$4001a8c0@gateway.2wire.net> From: t.petch To: Andy Bierman References: <501973A2.4020900@ripe.net><5019A186.2030808@ripe.net><20120801215609.GA84384@elstar.local><5019A6C6.3070606@ripe.net><00c901cd70b9$8b8014a0$4001a8c0@gateway.2wire.net> Date: Thu, 2 Aug 2012 18:31:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.21] X-OriginatorOrg: btconnect.com Cc: Bert Wijnen , netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 17:36:44 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" Cc: "Bert Wijnen" ; "netconf" Sent: Thursday, August 02, 2012 3:47 PM > On Thu, Aug 2, 2012 at 7:17 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Bert Wijnen" > > To: "netconf" > > Sent: Wednesday, August 01, 2012 10:59 PM > > > >> On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: > >> > Perhaps we need to rethink the isolated decision and look at the > >> > overall direction we want to go. And perhaps bundling all the above > >> > into a single revision of RFC 6241 (which later might advance > > without > >> > a further revision) is overall simpler and less confusing. > >> > >> I believe we did indeed discuss this in our session, and the outcome > >> was that the majority of people want to advance 6241/42. > > > > I believe that advancement of this, or of most protocols, is an > > irrelevant distraction, like changing the number of steps of > > advancement. > > > > Most people in this world have no awareness of the status, quite a few > > equate I-D to a standard. Yes, I have heard on IETF lists of a few > > organisations which do treat the change in status as material but to me > > it seems to be more about the status of those involved:-( > > > > So, an academic issue (unlike producing a better 'base and towers' > > model, where the base is suitable for devices that are not multicore, > > multiGHz workstations:-) > > > > You know what is not academic? Interoperability. > IMO, most NETCONF server implementations are > somewhat broken. The WG can ignore artificial standards > classifications if it wants, but advancement requires that > interoperability testing be done -- something the WG has > completely ignored from the start. Yes, interoperability is paramount, else we have nothing, but I am less sure that advancement achieves that, based on the reports I have seen produced. Some are good, but many seem weak. And, ironically, I seem to recall, early in the days of Netconf, at Paris, being impressed by how quickly Netconf had got into interoperability testing:-) Tom Petch > > We have a core + towers approach now. Some people think > locking and filtering are much too complicated to implement > so we are going to work on making the core smaller. > Since the general implementation quality is so poor, I am forced > to consider the possibility that we over-reached with NETCONF > and need to lower our expectations (and reduce the mandatory > feature set). > > > Tom Petch > > Andy > > > > >> People who were not present and want to state an opinion, by all > >> means, please do so. > >> > >> Bert > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > From mehmet.ersue@nsn.com Thu Aug 2 10:56:07 2012 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 2C17A11E816B for ; Thu, 2 Aug 2012 10:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 1uMYO12YYfyN for ; Thu, 2 Aug 2012 10:56:06 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 15BF611E8072 for ; Thu, 2 Aug 2012 10:56:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q72Hu4XG011400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 19:56:04 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q72Hu4uA004343; Thu, 2 Aug 2012 19:56:04 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 19:56:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Aug 2012 19:55:55 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120801215609.GA84384@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromise solution avoiding confusion WAS:RE: [Netconf] new draft charter - Action before Aug 15th Thread-Index: Ac1wMHpkyoqS5PqLTZW0Z0Df5mx3+AApd7FQ References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Bert Wijnen" X-OriginalArrivalTime: 02 Aug 2012 17:56:00.0473 (UTC) FILETIME=[136C6490:01CD70D8] 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: 1979 X-purgate-ID: 151667::1343930164-00002E58-2D8E6289/0-0/0-0 Cc: netconf Subject: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 17:56:07 -0000 Is it the compromise solution to publish N-L and get-oper together in a 6241bis leading to a 1.2? Sounds a doable way forward to me. I would appreciate if we can close the very long discussion with such a solution. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Juergen Schoenwaelder > Sent: Wednesday, August 01, 2012 2:56 PM > To: Bert Wijnen > Cc: netconf > Subject: Re: [Netconf] new draft charter - Action before Aug 15th >=20 > On Wed, Aug 01, 2012 at 02:37:10PM -0700, Bert Wijnen wrote: > > WG participants, based on our discussions at IETF84, > > we (WG chairs) propose the following new charter text. > > > > Pls comment and let us know your opinion no later than > > August 15th (any timezone). >=20 > Do we have to respin RFC 6241 to advance it? I think there is an open > errata. (And if we do more interoperability testing, there might even > be more errata coming along.) >=20 > I am concerned that we might leave a confusing impression if we do all > of the below more or less at the same time: >=20 > - publish a revision of RFC 6241 to advance it > - publish a competitor to RFC 6241(bis) called NC Lite > - publish an extension (to both?) solving the get operational > state issue >=20 > Perhaps we need to rethink the isolated decision and look at the > overall direction we want to go. And perhaps bundling all the above > into a single revision of RFC 6241 (which later might advance without > a further revision) is overall simpler and less confusing. >=20 > /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 j.schoenwaelder@jacobs-university.de Thu Aug 2 11:03:02 2012 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 D6C0311E818F for ; Thu, 2 Aug 2012 11:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.204 X-Spam-Level: X-Spam-Status: No, score=-103.204 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoMjZbZacA2x for ; Thu, 2 Aug 2012 11:03:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 20A5911E818C for ; Thu, 2 Aug 2012 11:03:02 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6851120C14; Thu, 2 Aug 2012 20:03:01 +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 Sjh8B-xZIb6V; Thu, 2 Aug 2012 20:03:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EDCA220C15; Thu, 2 Aug 2012 20:03:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8A6E0210261F; Thu, 2 Aug 2012 20:03:00 +0200 (CEST) Date: Thu, 2 Aug 2012 20:03:00 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20120802180300.GB86840@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , Bert Wijnen , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Bert Wijnen , netconf Subject: Re: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 18:03:03 -0000 On Thu, Aug 02, 2012 at 07:55:55PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Is it the compromise solution to publish N-L and get-oper together in a > 6241bis leading to a 1.2? > Sounds a doable way forward to me. > > I would appreciate if we can close the very long discussion with such a > solution. It might also be useful to do some interoperability testing so that any needed fixes or clarifications can be included in a 1.2 version. This may increase the likelihood that we get a 1.2 specification that is good enough for advancement without another revision. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Thu Aug 2 11:09:54 2012 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 5ECD421F86A2 for ; Thu, 2 Aug 2012 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 3tQY5zB4uBTH for ; Thu, 2 Aug 2012 11:09:52 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE5121F8698 for ; Thu, 2 Aug 2012 11:09:52 -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 q72I9pJ2016713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Aug 2012 20:09:51 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q72I9owd007279; Thu, 2 Aug 2012 20:09:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Aug 2012 20:09:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Aug 2012 20:09:10 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404183572@DEMUEXC006.nsn-intra.net> In-Reply-To: <20120802180300.GB86840@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compromise solution avoiding confusion WAS:RE: [Netconf] new draft charter - Action before Aug 15th Thread-Index: Ac1w2REVUn3SN0DrSCuOji4RmsxG7QAAMjtg References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 02 Aug 2012 18:09:12.0198 (UTC) FILETIME=[EB540A60:01CD70D9] 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: 569 X-purgate-ID: 151667::1343930991-000055D8-BE81CB61/0-0/0-0 Cc: Bert Wijnen , netconf Subject: Re: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 18:09:54 -0000 > > Is it the compromise solution to publish N-L and get-oper together in a > > 6241bis leading to a 1.2? > > Sounds a doable way forward to me. > > > > I would appreciate if we can close the very long discussion with such a > > solution. >=20 > It might also be useful to do some interoperability testing so that > any needed fixes or clarifications can be included in a 1.2 > version. This may increase the likelihood that we get a 1.2 > specification that is good enough for advancement without another > revision. Sounds perfect to me. Mehmet From bertietf@bwijnen.net Thu Aug 2 11:13:52 2012 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 2C1CF11E8209 for ; Thu, 2 Aug 2012 11:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UvJ+PDdaP4d for ; Thu, 2 Aug 2012 11:13:50 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 13EB811E8200 for ; Thu, 2 Aug 2012 11:13:50 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Swzu8-00056I-7z for netconf@ietf.org; Thu, 02 Aug 2012 20:13:49 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=dhcp-1698.meeting.ietf.org) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1Swzu7-0005S9-Un for netconf@ietf.org; Thu, 02 Aug 2012 20:13:48 +0200 Message-ID: <501AC35A.4060107@bwijnen.net> Date: Thu, 02 Aug 2012 11:13:46 -0700 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> In-Reply-To: <20120802180300.GB86840@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120802 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45406ab80b5cbfef77af593d11e211a34 Subject: Re: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 18:13:52 -0000 On 8/2/12 11:03 AM, Juergen Schoenwaelder wrote: > It might also be useful to do some interoperability testing so that > any needed fixes or clarifications can be included in a 1.2 > version. This may increase the likelihood that we get a 1.2 > specification that is good enough for advancement without another > revision. Interoperability testing can certainly be part of the "advancement" process as input for the Implementation/Deployment/Interoperability report that we must provide. But interoperability testing is not necessarily a WG chartered activity or obligation. Of course if we as WG chairs can help to get such an event going, we will do so as much as we can. Do we want to do this ASAP or at or around the next IETF? If ASAP, is anyone offering to arrange it at their site/location? If needed, I think I can arrange space at the RIPE-NCC in Amsterdam. Let me know if I should investigate. Bert From andy@yumaworks.com Thu Aug 2 11:32:26 2012 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 17FFD11E822A for ; Thu, 2 Aug 2012 11:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hflCZqDiDl6t for ; Thu, 2 Aug 2012 11:32:25 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8EF11E8229 for ; Thu, 2 Aug 2012 11:32:25 -0700 (PDT) Received: by qadz3 with SMTP id z3so3589633qad.10 for ; Thu, 02 Aug 2012 11:32:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Hj4aK4X+2yRY8nGtdGYYkR4j21rpWKzLAwOIZpel3WU=; b=fdvn7jtqRE9F2esGz5xV+iphZFUYvaosXjGTbEcor5S2nZUxaG+zYrovuveCTMMJ8H xVSuwVu0xlOcpKiLgkdg5nXXCvJhD0O+vU0aACSs4rBxluPMZpzS56tKLahM7mitzm4h rfJ5eYvv2qhtPxAlU8bkccO3r+090YDUeiU2zYIUat76VDteCmK3/oxj9ik7nx+13ZE4 cQT8ioSEbNgFNrpp/O8ZYE1CplaeYlBgaa7sG6JrhMiarJLUNq2bu6/6q8NtapamnpTC 6k4g73hdhqaVCLGt6+6OnnuYgmJ6zJvI96FJC403zeaZwj2XPirVvTP4NN6qMyu0hsIq YCbA== MIME-Version: 1.0 Received: by 10.224.105.193 with SMTP id u1mr43512036qao.85.1343932344806; Thu, 02 Aug 2012 11:32:24 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Thu, 2 Aug 2012 11:32:24 -0700 (PDT) X-Originating-IP: [2001:df8:0:64:e55b:8747:ab19:155b] In-Reply-To: <501AC35A.4060107@bwijnen.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> Date: Thu, 2 Aug 2012 11:32:24 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQm7xrkEzZNUeBGLxoNXkafS15x7Mvr3aAad7xPypmayLPpRitk1AiSCdtD7iuLiSQo+rm/f Cc: netconf Subject: Re: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 18:32:26 -0000 On Thu, Aug 2, 2012 at 11:13 AM, Bert Wijnen (IETF) wrote: > On 8/2/12 11:03 AM, Juergen Schoenwaelder wrote: >> >> It might also be useful to do some interoperability testing so that >> any needed fixes or clarifications can be included in a 1.2 >> version. This may increase the likelihood that we get a 1.2 >> specification that is good enough for advancement without another >> revision. > > > Interoperability testing can certainly be part of the "advancement" process > as input for the Implementation/Deployment/Interoperability report that > we must provide. > > But interoperability testing is not necessarily a WG chartered > activity or obligation. Of course if we as WG chairs can help > to get such an event going, we will do so as much as we can. > > Do we want to do this ASAP or at or around the next IETF? > If ASAP, is anyone offering to arrange it at their site/location? > If needed, I think I can arrange space at the RIPE-NCC in > Amsterdam. Let me know if I should investigate. I would be interested in attending. It might lead to an Implementation Guidelines document. It seems obvious, but the more complicated and arbitrary the client request, the less likely the server will implement it correctly. (e.g., alter 1 resource at a time works OK but altering N resources at once is not handled correctly.) I now think base:1.2 is our least-worst option, especially if we start working on operational data. Martin and Juergen have some good ideas for operational data and it should be worked on ASAP. > > Bert Andy From lhotka@nic.cz Thu Aug 2 15:02:00 2012 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 13CB621E80B6 for ; Thu, 2 Aug 2012 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUFB53URXQuf for ; Thu, 2 Aug 2012 15:01:59 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F01C511E8102 for ; Thu, 2 Aug 2012 15:01:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0D94D540436; Fri, 3 Aug 2012 00:01:53 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1opMLntVmegq; Fri, 3 Aug 2012 00:01:49 +0200 (CEST) Received: from localhost (dhcp-16a6.meeting.ietf.org [130.129.22.166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6987D54005A; Fri, 3 Aug 2012 00:01:43 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Bert Wijnen In-Reply-To: <20120801215609.GA84384@elstar.local> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Thu, 02 Aug 2012 15:01:39 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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, 02 Aug 2012 22:02:00 -0000 Juergen Schoenwaelder writes: > On Wed, Aug 01, 2012 at 02:37:10PM -0700, Bert Wijnen wrote: >> WG participants, based on our discussions at IETF84, >> we (WG chairs) propose the following new charter text. >> >> Pls comment and let us know your opinion no later than >> August 15th (any timezone). > > Do we have to respin RFC 6241 to advance it? I think there is an open > errata. (And if we do more interoperability testing, there might even > be more errata coming along.) > > I am concerned that we might leave a confusing impression if we do all > of the below more or less at the same time: > > - publish a revision of RFC 6241 to advance it > - publish a competitor to RFC 6241(bis) called NC Lite > - publish an extension (to both?) solving the get operational > state issue > > Perhaps we need to rethink the isolated decision and look at the > overall direction we want to go. And perhaps bundling all the above > into a single revision of RFC 6241 (which later might advance without > a further revision) is overall simpler and less confusing. I support the idea of integrating all the above ideas into a revision of 6241. I believe that with a little care it can be done so that existing implementations of 1.1 will have very few problems in adapting to the new version. Having two standard track protocols where protocol A has the same functionality as protocol B + several optional capabilities is IMO hardly defensible, to say the least. Lada > > /js > > -- > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 2 15:37:02 2012 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 9C88E21F8B93 for ; Thu, 2 Aug 2012 15:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.159, 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 B8cujBEspNio for ; Thu, 2 Aug 2012 15:37: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 0464121F8B7D for ; Thu, 2 Aug 2012 15:37:01 -0700 (PDT) Received: from localhost (dhcp-133c.meeting.ietf.org [130.129.19.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 204B21200D72; Fri, 3 Aug 2012 00:36:58 +0200 (CEST) Date: Thu, 02 Aug 2012 15:36:56 -0700 (PDT) Message-Id: <20120802.153656.217970804.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Compromise solution avoiding confusion WAS:RE: new draft charter - Action before Aug 15th 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, 02 Aug 2012 22:37:02 -0000 Andy Bierman wrote: > On Thu, Aug 2, 2012 at 11:13 AM, Bert Wijnen (IETF) > wrote: > > On 8/2/12 11:03 AM, Juergen Schoenwaelder wrote: > >> > >> It might also be useful to do some interoperability testing so that > >> any needed fixes or clarifications can be included in a 1.2 > >> version. This may increase the likelihood that we get a 1.2 > >> specification that is good enough for advancement without another > >> revision. > > > > > > Interoperability testing can certainly be part of the "advancement" process > > as input for the Implementation/Deployment/Interoperability report that > > we must provide. > > > > But interoperability testing is not necessarily a WG chartered > > activity or obligation. Of course if we as WG chairs can help > > to get such an event going, we will do so as much as we can. > > > > Do we want to do this ASAP or at or around the next IETF? > > If ASAP, is anyone offering to arrange it at their site/location? > > If needed, I think I can arrange space at the RIPE-NCC in > > Amsterdam. Let me know if I should investigate. > > I would be interested in attending. +1 /martin From mbadra@gmail.com Fri Aug 3 14:21:15 2012 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 8943821E805D for ; Fri, 3 Aug 2012 14:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=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 WT1Eh85NqCnd for ; Fri, 3 Aug 2012 14:21:11 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C95011E8091 for ; Fri, 3 Aug 2012 14:21:11 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so1282672vcb.31 for ; Fri, 03 Aug 2012 14:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sPUslYWjvtzS2BVgMekXdeB+0gZTSB0nW9ZAlrnUJTw=; b=CPYHXu47vr0rUGVbToqDUYmViLA5+r1E8L0m/nvIeXmLb/9BfyfgxbhYnpz7F7zylf ylXxw19Lc0AIZDWzxvStM0MS9LAbzUIJizrlrBQAyntgPS3q+PH8Cz1om9udHgUTQM3n axbQfOnAW1uuSFDrqAsO6Yqg3aHWtIPELdu4mwse5Pda450tgi71oqc0fGLpFZSbTljt RjDCRx7AEovMvaKu7f/iWvpDHx4L4yVtDMrYABclpFcuTm22gkqHHr/Q4Rqnene3hZDb 8rO4sGKAXbJ0qvvptt7fgoHJpAXQeS34TjVu25Dc88HX+rQ3DnMdmdldDaV+p0NBxWqb yehA== MIME-Version: 1.0 Received: by 10.52.100.165 with SMTP id ez5mr2093667vdb.108.1344028870673; Fri, 03 Aug 2012 14:21:10 -0700 (PDT) Received: by 10.220.168.138 with HTTP; Fri, 3 Aug 2012 14:21:10 -0700 (PDT) In-Reply-To: <01ef01cd7092$02c4cb00$4001a8c0@gateway.2wire.net> References: <01ef01cd7092$02c4cb00$4001a8c0@gateway.2wire.net> Date: Sat, 4 Aug 2012 00:21:10 +0300 Message-ID: From: Mohamad Badra To: "t.petch" Content-Type: multipart/alternative; boundary=20cf3063dc0367856c04c6631bcb Cc: netconf@ietf.org Subject: Re: [Netconf] Netconf over TLS (rfc5539bis) 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, 03 Aug 2012 21:21:15 -0000 --20cf3063dc0367856c04c6631bcb Content-Type: text/plain; charset=ISO-8859-1 Dear Tom I will take it into account in the updated version. Thanks Best regards Badra On Thu, Aug 2, 2012 at 12:34 PM, t.petch wrote: > Badra > > Your description of RFC822 names makes reference to a host part. > > This is incorrect - it should be a domain part, as per RFC822. > > Tom Petch > > > ----- Original Message ----- > From: "Mohamad Badra" > To: > Sent: Saturday, April 28, 2012 1:43 PM > > > Dear All, > > > > I just posted a revised version of the > > document draft-badra-netconf-rfc5539bis > > > > http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-02.txt > > > > Your comments are highly appreciated. > > > > Best regards, > > Badra > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > --20cf3063dc0367856c04c6631bcb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Tom

I will take it into account in= the updated version. Thanks
Best regards
Badra

=
On Thu, Aug 2, 2012 at 12:34 PM, t.petch <iet= fc@btconnect.com> wrote:
Badra

Your description of RFC822 names makes reference to a host part.

This is incorrect - it should be a domain part, as per RFC822.

Tom Petch


----- Original Message -----
From: "Mohamad Badra" <mba= dra@gmail.com>
To: <netconf@ietf.org>
Sent: Saturday, April 28, 2012 1:43 PM

> Dear All,
>
> I just posted a revised version of the
> document draft-badra-netconf-rfc5539bis
>
> http://www.ietf.org/id/draft-badra-netconf-rfc5539bis-= 02.txt
>
> Your comments are highly appreciated.
>
> Best regards,
> Badra
>


---------------------------------------------------------------= ---------
--------


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



--20cf3063dc0367856c04c6631bcb-- From mbadra@gmail.com Fri Aug 3 14:21:53 2012 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 84FF611E80A6 for ; Fri, 3 Aug 2012 14:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 P6Z3cxvMLyTk for ; Fri, 3 Aug 2012 14:21:50 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4642A11E8091 for ; Fri, 3 Aug 2012 14:21:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1312560vbb.31 for ; Fri, 03 Aug 2012 14:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DSR+2W+4qJPNgr4GIDm4qq+ShcsVmalPZgzRmi/FduI=; b=MF3bKR60s5GRgop48LZSZIqk+eReUsiTyA92wjg61JqtMHKfggDMkjZuIhPotJ70sO zMTnUZ8g9ReTk9IQ3MAmbkOtGsA720h5zuqPAvtU0CsMtMctW9BVRBSm2DardEV4PMvA dotDkJgzj8RzkMs3ixZyweNYB6QGyFiB29nM6sSCjuX54lQDmRA/SgYqF7QIrfuLQQ29 ixMWR/HuGcfXXIKEIo8EZAwK6p+LINbXZ3VFb25ytczISRxHtYxD+iAaSk7JEnedPzDB hCEmAfLGBYaY6t5cALDHMcN5C28vqACXbMmiYKl2eca6KwXtXQPU2sziUNV2AqPNfbrC 4qCQ== MIME-Version: 1.0 Received: by 10.220.218.133 with SMTP id hq5mr2403119vcb.60.1344028909629; Fri, 03 Aug 2012 14:21:49 -0700 (PDT) Received: by 10.220.168.138 with HTTP; Fri, 3 Aug 2012 14:21:49 -0700 (PDT) In-Reply-To: <50185770.3060806@bwijnen.net> References: <50185770.3060806@bwijnen.net> Date: Sat, 4 Aug 2012 00:21:49 +0300 Message-ID: From: Mohamad Badra To: "Bert Wijnen (IETF)" Content-Type: multipart/alternative; boundary=14dae9cfc770b9ef7404c6631d27 Cc: "netconf@ietf.org" Subject: Re: [Netconf] regarding draft-badra-netconf-rfc5539bis-02 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:21:53 -0000 --14dae9cfc770b9ef7404c6631d27 Content-Type: text/plain; charset=ISO-8859-1 OK Best regards Badra On Wed, Aug 1, 2012 at 1:08 AM, Bert Wijnen (IETF) wrote: > At least, it is best to NOT have them as normative > references. Informative might be OK. > But could indeed also remove them. > > Bert > > > > On 7/31/12 1:46 PM, Kent Watsen wrote: > >> >> Hi Badra, >> >> As noted in yesterday's meeting, per the intent of the new charter to >> deprecate BEEP, the "Security Considerations" section of this draft should >> probably remove it's reference BEEP as an active transport. >> >> Thanks, >> Kent >> >> >> >> ______________________________**_________________ >> 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 > --14dae9cfc770b9ef7404c6631d27 Content-Type: text/html; charset=ISO-8859-1
OK
Best regards
Badra

On Wed, Aug 1, 2012 at 1:08 AM, Bert Wijnen (IETF) <bertietf@bwijnen.net> wrote:
At least, it is best to NOT have them as normative
references. Informative might be OK.
But could indeed also remove them.

Bert



On 7/31/12 1:46 PM, Kent Watsen wrote:

Hi Badra,

As noted in yesterday's meeting, per the intent of the new charter to
deprecate BEEP, the "Security Considerations" section of this draft should
probably remove it's reference BEEP as an active transport.

Thanks,
Kent



_______________________________________________
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

--14dae9cfc770b9ef7404c6631d27-- From bertietf@bwijnen.net Tue Aug 7 04:23:17 2012 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 78BAF21F8672 for ; Tue, 7 Aug 2012 04:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w17V1C+SJA4F for ; Tue, 7 Aug 2012 04:23:16 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 26DA621F8671 for ; Tue, 7 Aug 2012 04:23:15 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SyhsW-0007ZF-0Z for netconf@ietf.org; Tue, 07 Aug 2012 13:23:13 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1SyhsV-00064q-F2 for netconf@ietf.org; Tue, 07 Aug 2012 13:23:11 +0200 Message-ID: <5020FA9F.9000200@bwijnen.net> Date: Tue, 07 Aug 2012 13:23:11 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> In-Reply-To: <501AC35A.4060107@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120807 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd404005ebcc081fc8f9b1636170eb0535f Subject: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 11:23:17 -0000 So, to my offer: On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: > But interoperability testing is not necessarily a WG chartered > activity or obligation. Of course if we as WG chairs can help > to get such an event going, we will do so as much as we can. > > Do we want to do this ASAP or at or around the next IETF? > If ASAP, is anyone offering to arrange it at their site/location? > If needed, I think I can arrange space at the RIPE-NCC in > Amsterdam. Let me know if I should investigate. I have hear a "yes I am interested" from Andy and from Martin. Are there any others? I don't think that organizing ot for just 2 implementations makes sense... well, they could then visit each other instead of me organizing it in Amsterdam. So pls express your potential interest before Aug 15th. If there is enough interest, then I will investigate possible options in Amsterdam. Bert From andy@yumaworks.com Tue Aug 7 06:26:41 2012 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 6204E21F85A5 for ; Tue, 7 Aug 2012 06:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7EeBJHFtCWG for ; Tue, 7 Aug 2012 06:26:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 650FA21F859F for ; Tue, 7 Aug 2012 06:26:40 -0700 (PDT) Received: by qcac10 with SMTP id c10so2772756qca.31 for ; Tue, 07 Aug 2012 06:26:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=hh/jrE/EbNJt2aJYj3bZnysd12uKwjkFCv27OCCBvYw=; b=LubrbIlEfMYLUAdXL3q7V3gtSCcI2U9rZ5rx2AU9+w2l4XLuTAfq3CPE+pvvlrWWZY V7tgKrU9PFTSe9R/EvdUTqLqPtm6LmhIse8ukPBHjavqTHzFmEqTUfWaDM+IaATB0tpO 4EFeOik9+d6veLi5tKlQ2IKMgOROBD4N9QQrFFY81HzpcYrQjZGRZJzp82gTtNEi6FJs NyAezBlAcO5PVW28hViBoisLs20CE5u9STazMYNeNqmTWme64f+GWAEWgMkWPh6mQ5DI ANVVI+CRCP8IUxM6YNyxewppwz1xcXGXOY13ZmhkvcUJfFcmJ1jXUg2GIs5Zgt+E0Zcl Zstg== MIME-Version: 1.0 Received: by 10.229.136.129 with SMTP id r1mr7236110qct.21.1344345999863; Tue, 07 Aug 2012 06:26:39 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Tue, 7 Aug 2012 06:26:39 -0700 (PDT) In-Reply-To: <5020FA9F.9000200@bwijnen.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> Date: Tue, 7 Aug 2012 06:26:39 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmJt4NhhC11vrpqAUCBCo9/VJMcgyIMWvNuqlhH3eC1GsG94s5otcptkasXjYOiqpQ9Znmr Cc: netconf Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 13:26:41 -0000 Maybe we can set something up online instead of meeting for a few days in Amsterdam. Andy On Tue, Aug 7, 2012 at 4:23 AM, Bert Wijnen (IETF) wrote: > So, to my offer: > > On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >> >> But interoperability testing is not necessarily a WG chartered >> activity or obligation. Of course if we as WG chairs can help >> to get such an event going, we will do so as much as we can. >> >> Do we want to do this ASAP or at or around the next IETF? >> If ASAP, is anyone offering to arrange it at their site/location? >> If needed, I think I can arrange space at the RIPE-NCC in >> Amsterdam. Let me know if I should investigate. > > > I have hear a "yes I am interested" from Andy and from Martin. > Are there any others? > > I don't think that organizing ot for just 2 implementations > makes sense... well, they could then visit each other instead > of me organizing it in Amsterdam. > > So pls express your potential interest before Aug 15th. > If there is enough interest, then I will investigate possible > options in Amsterdam. > > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Tue Aug 7 07:20:47 2012 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 B5CEB21F8533 for ; Tue, 7 Aug 2012 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.207 X-Spam-Level: X-Spam-Status: No, score=-103.207 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-qh2loxboDy for ; Tue, 7 Aug 2012 07:20:47 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id D55A621F852C for ; Tue, 7 Aug 2012 07:20:46 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C255120BF6; Tue, 7 Aug 2012 16:20:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SLiSnrsCssuR; Tue, 7 Aug 2012 16:20:45 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3C95120825; Tue, 7 Aug 2012 16:20:45 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E6CE2107F20; Tue, 7 Aug 2012 16:20:45 +0200 (CEST) Date: Tue, 7 Aug 2012 16:20:45 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20120807142044.GC95033@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5020FA9F.9000200@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:20:47 -0000 On Tue, Aug 07, 2012 at 01:23:11PM +0200, Bert Wijnen (IETF) wrote: > So, to my offer: > > On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: > >But interoperability testing is not necessarily a WG chartered > >activity or obligation. Of course if we as WG chairs can help > >to get such an event going, we will do so as much as we can. > > > >Do we want to do this ASAP or at or around the next IETF? > >If ASAP, is anyone offering to arrange it at their site/location? > >If needed, I think I can arrange space at the RIPE-NCC in > >Amsterdam. Let me know if I should investigate. > > I have hear a "yes I am interested" from Andy and from Martin. > Are there any others? > > I don't think that organizing ot for just 2 implementations > makes sense... well, they could then visit each other instead > of me organizing it in Amsterdam. > > So pls express your potential interest before Aug 15th. > If there is enough interest, then I will investigate possible > options in Amsterdam. We might participate, depending on whether we find enough time to update our "old" test suite to cover NETCONF 1.1 and some newer data models. Jacobs University can also very easily host such an event. While Bremen is easily reachable from Stockholm and most European hubs, it might be a bit more inconvenient for people from other continents. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Tue Aug 7 07:57:57 2012 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 9BE4121F8736 for ; Tue, 7 Aug 2012 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfjWbUFGe69O for ; Tue, 7 Aug 2012 07:57:57 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id C632721F870B for ; Tue, 7 Aug 2012 07:57:56 -0700 (PDT) Received: by qadz3 with SMTP id z3so1749221qad.10 for ; Tue, 07 Aug 2012 07:57:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=N75MhLnnuDjIW+/Cg2RDVLsaaa3L/xBcOH3KRXgIXWQ=; b=nuAGp3Kkd+nsS6A0nh0IPzktzJIgOFPUDG/1AjbXDgiyaed6qrCgHYiXhmqLkfd9/E vqiEpF7mGnsNjd//t6EQJ36bR1AzWlPp5RoaGo2/RCPHUDNqmJlWoDCv5BK4nnCydOOz 7UaqzeZRUSGuLywytOK2yR3FttOkW49l+u8reZvAFqU0HNHSo3Oek/2UrxjPNj4uImvF qGTf2zSAmqpYDR8+/ENTkLmpgujWbsuRH8BWTaRjQqJR4nwwWdLA2ah8rNdMhmUZFMmC fmSxENvTKNx3L68VkjAe0fOWq2lPzfbU+n/MJfv943BbU8Z8PKFfRAUz5tJjzfGA9w3D J3ow== MIME-Version: 1.0 Received: by 10.224.105.193 with SMTP id u1mr24298030qao.85.1344351476162; Tue, 07 Aug 2012 07:57:56 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Tue, 7 Aug 2012 07:57:56 -0700 (PDT) In-Reply-To: <20120807142044.GC95033@elstar.local> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> <20120807142044.GC95033@elstar.local> Date: Tue, 7 Aug 2012 07:57:56 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Bert Wijnen (IETF)" , netconf Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmsTjSCksWMaagH+pgtWj+/P7OriCYGzm4vcXH+Qdq8cQ7B0IYakO/FZb0SISWpTYw7uk84 Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 14:57:57 -0000 I can not really allocate the travel and time expense for this, but I can participate online, assuming you will have Internet access at the test. You can also just download yuma at any time, (since Aug. 2010): http://sourceforge.net/projects/yuma/ Install and test all you want. Andy On Tue, Aug 7, 2012 at 7:20 AM, Juergen Schoenwaelder wrote: > On Tue, Aug 07, 2012 at 01:23:11PM +0200, Bert Wijnen (IETF) wrote: >> So, to my offer: >> >> On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >> >But interoperability testing is not necessarily a WG chartered >> >activity or obligation. Of course if we as WG chairs can help >> >to get such an event going, we will do so as much as we can. >> > >> >Do we want to do this ASAP or at or around the next IETF? >> >If ASAP, is anyone offering to arrange it at their site/location? >> >If needed, I think I can arrange space at the RIPE-NCC in >> >Amsterdam. Let me know if I should investigate. >> >> I have hear a "yes I am interested" from Andy and from Martin. >> Are there any others? >> >> I don't think that organizing ot for just 2 implementations >> makes sense... well, they could then visit each other instead >> of me organizing it in Amsterdam. >> >> So pls express your potential interest before Aug 15th. >> If there is enough interest, then I will investigate possible >> options in Amsterdam. > > We might participate, depending on whether we find enough time to > update our "old" test suite to cover NETCONF 1.1 and some newer data > models. Jacobs University can also very easily host such an > event. While Bremen is easily reachable from Stockholm and most > European hubs, it might be a bit more inconvenient for people from > other continents. > > /js > > -- > 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 kwatsen@juniper.net Tue Aug 7 09:28:14 2012 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 3BB0211E8072 for ; Tue, 7 Aug 2012 09:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 LC+ksn+u57Ei for ; Tue, 7 Aug 2012 09:28:12 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3FADF11E8087 for ; Tue, 7 Aug 2012 09:28:12 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUCFCFAQitKk3xYlQ9w36KgRUQ3IGrY6u@postini.com; Tue, 07 Aug 2012 09:28:12 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 7 Aug 2012 09:25:56 -0700 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , "Bert Wijnen (IETF)" , netconf Date: Tue, 7 Aug 2012 09:25:55 -0700 Thread-Topic: [Netconf] Interoperability Testing - Action before Aug 15th Thread-Index: Ac10uVHNazgLzRplS3i3RmjhaO3/Jg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 16:28:14 -0000 We also have a test suite to validate NETCONF implementations and, of course, we have a number of NETCONF implementations (JUNOS, IVE, VSE, BX, plus some device-adapters). Can we create a matrix of all the tests we'd like to run? Perhaps we can start by each of us enumerating our clients and servers, and with which base versions are supported. Should we also enumerate which optional capabilities are supported? Name Type Base Versions Comments -------------- ------ ------------- ----------------------------- DMI Test Suite client 1.0 only can test any NETCONF implementation Space client 1.0 only needs a data model defined via XSD NSM client 1.0 only needs a data model defined via XSD Junos server 1.0 only data model defined via XSD IVE server 1.0 only data model defined via XSD VSE server 1.0 only data model defined via XSD BX server 1.0 only data model defined via XSD VSE server 1.0 only data model defined via XSD ScreenOS adapter server 1.0 only data model defined via XSD Trapeze adapter server 1.0 only data model defined via XSD Like Andy, it would be difficult for me to travel for this (unless at IETF 85), but it seems that we should be able to do this online - especially with Skype video, screen-sharing, and what not... Thanks, Kent On 8/7/12 10:57 AM, "Andy Bierman" wrote: >I can not really allocate the travel and time expense for this, >but I can participate online, assuming you will have >Internet access at the test. > >You can also just download yuma at any time, (since Aug. 2010): >http://sourceforge.net/projects/yuma/ >Install and test all you want. > > >Andy > > >On Tue, Aug 7, 2012 at 7:20 AM, Juergen Schoenwaelder > wrote: >> On Tue, Aug 07, 2012 at 01:23:11PM +0200, Bert Wijnen (IETF) wrote: >>> So, to my offer: >>> >>> On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >>> >But interoperability testing is not necessarily a WG chartered >>> >activity or obligation. Of course if we as WG chairs can help >>> >to get such an event going, we will do so as much as we can. >>> > >>> >Do we want to do this ASAP or at or around the next IETF? >>> >If ASAP, is anyone offering to arrange it at their site/location? >>> >If needed, I think I can arrange space at the RIPE-NCC in >>> >Amsterdam. Let me know if I should investigate. >>> >>> I have hear a "yes I am interested" from Andy and from Martin. >>> Are there any others? >>> >>> I don't think that organizing ot for just 2 implementations >>> makes sense... well, they could then visit each other instead >>> of me organizing it in Amsterdam. >>> >>> So pls express your potential interest before Aug 15th. >>> If there is enough interest, then I will investigate possible >>> options in Amsterdam. >> >> We might participate, depending on whether we find enough time to >> update our "old" test suite to cover NETCONF 1.1 and some newer data >> models. Jacobs University can also very easily host such an >> event. While Bremen is easily reachable from Stockholm and most >> European hubs, it might be a bit more inconvenient for people from >> other continents. >> >> /js >> >> -- >> 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 >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From xiangli@seguesoft.com Wed Aug 8 07:40:16 2012 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 0837321F8668 for ; Wed, 8 Aug 2012 07:40:16 -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 EaJGmTrIVqDV for ; Wed, 8 Aug 2012 07:40:15 -0700 (PDT) Received: from p3plsmtpa07-06.prod.phx3.secureserver.net (p3plsmtpa07-06.prod.phx3.secureserver.net [173.201.192.235]) by ietfa.amsl.com (Postfix) with SMTP id E5AAD21F8628 for ; Wed, 8 Aug 2012 07:40:14 -0700 (PDT) Received: (qmail 19614 invoked from network); 8 Aug 2012 14:40:14 -0000 Received: from unknown (99.249.193.192) by p3plsmtpa07-06.prod.phx3.secureserver.net (173.201.192.235) with ESMTP; 08 Aug 2012 14:40:08 -0000 Message-ID: <50227A48.5040402@seguesoft.com> Date: Wed, 08 Aug 2012 09:40:08 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 14:40:16 -0000 Hi, On 8/7/2012 11:25 AM, Kent Watsen wrote: > > We also have a test suite to validate NETCONF implementations and, of > course, we have a number of NETCONF implementations (JUNOS, IVE, VSE, BX, > plus some device-adapters). > > Can we create a matrix of all the tests we'd like to run? Perhaps we can > start by each of us enumerating our clients and servers, and with which > base versions are supported. Should we also enumerate which optional > capabilities are supported? We have a relatively new NETCONF client implementation (NETCONFc) and is interested in such an event. But in my view, right now perhaps it's more important to focus on getting the initial set of IETF standard track YANG modules (ietf-system, ietf-interfaces, etc. ) out the door before such Interoperability testing event. Our NETCONFc client application implements NETCONF 1.1 and 1.0. --Xiang Li > Name Type Base Versions Comments > -------------- ------ ------------- > ----------------------------- > DMI Test Suite client 1.0 only can test any NETCONF > implementation > Space client 1.0 only needs a data model defined > via XSD > NSM client 1.0 only needs a data model defined > via XSD > Junos server 1.0 only data model defined via XSD > IVE server 1.0 only data model defined via XSD > VSE server 1.0 only data model defined via XSD > > BX server 1.0 only data model defined via XSD > > VSE server 1.0 only data model defined via XSD > > ScreenOS adapter server 1.0 only data model defined via XSD > Trapeze adapter server 1.0 only data model defined via XSD > > > > Like Andy, it would be difficult for me to travel for this (unless at IETF > 85), but it seems that we should be able to do this online - especially > with Skype video, screen-sharing, and what not... > > > Thanks, > Kent > > > > > > On 8/7/12 10:57 AM, "Andy Bierman" wrote: > >> I can not really allocate the travel and time expense for this, >> but I can participate online, assuming you will have >> Internet access at the test. >> >> You can also just download yuma at any time, (since Aug. 2010): >> http://sourceforge.net/projects/yuma/ >> Install and test all you want. >> >> >> Andy >> >> >> On Tue, Aug 7, 2012 at 7:20 AM, Juergen Schoenwaelder >> wrote: >>> On Tue, Aug 07, 2012 at 01:23:11PM +0200, Bert Wijnen (IETF) wrote: >>>> So, to my offer: >>>> >>>> On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >>>>> But interoperability testing is not necessarily a WG chartered >>>>> activity or obligation. Of course if we as WG chairs can help >>>>> to get such an event going, we will do so as much as we can. >>>>> >>>>> Do we want to do this ASAP or at or around the next IETF? >>>>> If ASAP, is anyone offering to arrange it at their site/location? >>>>> If needed, I think I can arrange space at the RIPE-NCC in >>>>> Amsterdam. Let me know if I should investigate. >>>> I have hear a "yes I am interested" from Andy and from Martin. >>>> Are there any others? >>>> >>>> I don't think that organizing ot for just 2 implementations >>>> makes sense... well, they could then visit each other instead >>>> of me organizing it in Amsterdam. >>>> >>>> So pls express your potential interest before Aug 15th. >>>> If there is enough interest, then I will investigate possible >>>> options in Amsterdam. >>> We might participate, depending on whether we find enough time to >>> update our "old" test suite to cover NETCONF 1.1 and some newer data >>> models. Jacobs University can also very easily host such an >>> event. While Bremen is easily reachable from Stockholm and most >>> European hubs, it might be a bit more inconvenient for people from >>> other continents. >>> >>> /js >>> >>> -- >>> 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 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Wed Aug 8 08:22:41 2012 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 5A4CA11E80ED for ; Wed, 8 Aug 2012 08:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.78 X-Spam-Level: X-Spam-Status: No, score=-2.78 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp87Jp1w4NzQ for ; Wed, 8 Aug 2012 08:22:40 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82E9D21F85A5 for ; Wed, 8 Aug 2012 08:22:39 -0700 (PDT) Received: by qcac10 with SMTP id c10so600337qca.31 for ; Wed, 08 Aug 2012 08:22:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ggQwI+wkG3UlVmgrowbIK5MMmotHZbj65ojcut26oB4=; b=hNxRsPeVdBmpc79uW4Zgx8/pnhXIQDwM+rQOzzjTLgNJEXSSDYt2I9hq6pc1pRwST5 dxrbxdyNNAXHTEemrprzUNNNE211eQuXon/xLjCsWrnpB8YoXMZg2PcgboUP9oICFnea +zweD+uREyuXgKaOIybWQp/MBJ8B4gBYJZBNBrVUd4fymt/njrRS6SH341dW9I9PDSX3 T3h2Wgrra5ba1oJ5R20v74BQNM5w+AvQFXKPuOoWRtvhWOCKcFbaJWVEfMsVGPQWj3pJ T4rF5vM23mqhDSO2eEnfjo/iyWYF+/L9oBT1HK9y/mP+dbX4ZST9UZ8DUb97aGq3M8aP Bzjw== MIME-Version: 1.0 Received: by 10.224.214.69 with SMTP id gz5mr21582093qab.21.1344439358987; Wed, 08 Aug 2012 08:22:38 -0700 (PDT) Received: by 10.49.26.168 with HTTP; Wed, 8 Aug 2012 08:22:38 -0700 (PDT) In-Reply-To: <50227A48.5040402@seguesoft.com> References: <50227A48.5040402@seguesoft.com> Date: Wed, 8 Aug 2012 08:22:38 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl6gzhpt5wwcOeNSOGraSWdDYEbbAzuekpH+enj3/3cLysT31aLODbb/oecRpAiZ9/0RNGD Cc: netconf@ietf.org Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 15:22:41 -0000 On Wed, Aug 8, 2012 at 7:40 AM, Xiang Li wrote: > Hi, > > On 8/7/2012 11:25 AM, Kent Watsen wrote: >> >> >> We also have a test suite to validate NETCONF implementations and, of >> course, we have a number of NETCONF implementations (JUNOS, IVE, VSE, BX, >> plus some device-adapters). >> >> Can we create a matrix of all the tests we'd like to run? Perhaps we can >> start by each of us enumerating our clients and servers, and with which >> base versions are supported. Should we also enumerate which optional >> capabilities are supported? > > > > We have a relatively new NETCONF client implementation (NETCONFc) and is > interested > in such an event. But in my view, right now perhaps it's more important to > focus on getting > the initial set of IETF standard track YANG modules (ietf-system, > ietf-interfaces, etc. ) out > the door before such Interoperability testing event. > It takes vendors awhile to get server implementations of standard modules done. We can test retrieval of ietf-netconf-monitoring, etc., but it may be awhile before all servers we want to test support the same configuration module. > Our NETCONFc client application implements NETCONF 1.1 and 1.0. > > --Xiang Li > > > Andy From matjaz@mg-soft.si Mon Aug 13 05:51:56 2012 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 5F81821F8742 for ; Mon, 13 Aug 2012 05:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 eVSyzOAGVPPS for ; Mon, 13 Aug 2012 05:51:55 -0700 (PDT) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62521F8744 for ; Mon, 13 Aug 2012 05:51:54 -0700 (PDT) Received: from [127.0.0.1] (mg-soft.si [10.0.0.15]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id q7DCpqPd015360; Mon, 13 Aug 2012 14:51:52 +0200 Message-ID: <5028F867.6010709@mg-soft.si> Date: Mon, 13 Aug 2012 14:51:51 +0200 From: Matjaz Vrecko Organization: MG-SOFT Corp. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , netconf References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A640418356D@DEMUEXC006.nsn-intra.net> <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> In-Reply-To: <5020FA9F.9000200@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Matjaz Vrecko List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 12:51:56 -0000 Hello Bert, In MG-SOFT we are also interested. We are more interested in an on-line interop testing, at least in the first step, which could also lead to a face-2-face meeting in Bremen, Amsterdam or someplace else. In MG-SOFT we have various NETCONF and YANG applications and our NETCONF protocol implementation supports both 1.0 and 1.1. Best regards for now, Matjaz On 07-Aug-2012 1:23 PM, Bert Wijnen (IETF) wrote: > So, to my offer: > > On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >> But interoperability testing is not necessarily a WG chartered >> activity or obligation. Of course if we as WG chairs can help >> to get such an event going, we will do so as much as we can. >> >> Do we want to do this ASAP or at or around the next IETF? >> If ASAP, is anyone offering to arrange it at their site/location? >> If needed, I think I can arrange space at the RIPE-NCC in >> Amsterdam. Let me know if I should investigate. > > I have hear a "yes I am interested" from Andy and from Martin. > Are there any others? > > I don't think that organizing ot for just 2 implementations > makes sense... well, they could then visit each other instead > of me organizing it in Amsterdam. > > So pls express your potential interest before Aug 15th. > If there is enough interest, then I will investigate possible > options in Amsterdam. > > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Matjaz Vrecko MG-SOFT Corporation, Strma ulica 8, SI-2000 Maribor, Slovenia Internet: http://www.mg-soft.si/ E-mail: Phone: +386 2 2506565, Fax: +386 2 2506566 From andy@yumaworks.com Mon Aug 13 08:13:27 2012 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 A7DD521F8731 for ; Mon, 13 Aug 2012 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH4Q64G-g3Nk for ; Mon, 13 Aug 2012 08:13:27 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9621F86D0 for ; Mon, 13 Aug 2012 08:13:26 -0700 (PDT) Received: by wgbfm10 with SMTP id fm10so3045700wgb.1 for ; Mon, 13 Aug 2012 08:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=l0dv//AjVAzhAVJV/mt6F5tIIfntgBNng/ULT8f55a4=; b=btYg5+J26JyiTFL7UmkuPSUDPXc5433MlN9/s6YijuAdRJTuqxGPPh6Ptpev8tSfOc umX2yqbrRL64FQmOvEOe7/iCp3+iu6ejNFvL20m9XIzBb9RZy4seK74CaFfKGkBlPagB /xqBUbzjobnBEx9M5bMhkAPYSmDcpoKhUjYreOVS818hRjELuV4WyMgISBaAK4Ij1JfI 9eVepSyPCuhu9srHA4OGIgOV7DSgRPKeGlvLfUWmAoLFGI8AyycUejjPRiBFjgWbbAUU 8+vO25z3Ppj5ncmdoDkFqydFy+sYv6KMc2ycf3Mpmra1g+/7Ad4O22i5kHJjE2BjoTuA J8VQ== MIME-Version: 1.0 Received: by 10.50.186.130 with SMTP id fk2mr5890844igc.60.1344870805222; Mon, 13 Aug 2012 08:13:25 -0700 (PDT) Received: by 10.50.23.2 with HTTP; Mon, 13 Aug 2012 08:13:24 -0700 (PDT) In-Reply-To: <501A0692.8040405@bwijnen.net> References: <501973A2.4020900@ripe.net> <5019A186.2030808@ripe.net> <20120801215609.GA84384@elstar.local> <5019A6C6.3070606@ripe.net> <20120801220607.GC84384@elstar.local> <501A0692.8040405@bwijnen.net> Date: Mon, 13 Aug 2012 08:13:24 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmo/NQAHkvGG9Wcxpw6JlGH+BMuWlM/YgiEJMBVcQiaKJRaU4z86k2x5ZX/ZKlpVMxCP3Al Cc: netconf Subject: Re: [Netconf] new draft charter - Action before Aug 15th 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 Aug 2012 15:13:27 -0000 On Wed, Aug 1, 2012 at 9:48 PM, Bert Wijnen (IETF) wrote: > Inline > > On 8/1/12 3:06 PM, Juergen Schoenwaelder wrote: >> >> On Wed, Aug 01, 2012 at 02:59:34PM -0700, Bert Wijnen wrote: >>> >>> On 8/1/12 2:56 PM, Juergen Schoenwaelder wrote: >>>> >>>> Perhaps we need to rethink the isolated decision and look at the >>>> overall direction we want to go. And perhaps bundling all the above >>>> into a single revision of RFC 6241 (which later might advance without >>>> a further revision) is overall simpler and less confusing. >>> >>> >>> I believe we did indeed discuss this in our session, and the outcome >>> was that the majority of people want to advance 6241/42. >> >> >> We took polls on isolated questions and the result in combination >> looks, well, to some contributors somewhat surprising or not like a >> well thought out plan or whatever your preferred wording is. >> > > We showed the overall concept of the new charter text and conceptually > I believe everyone supported that. > But if people want to change their position, then pls do speak up. > I was trying to be accommodating on NETCONF Lite, even though I don't agree that it will significantly reduce server code size. I would rather drop the whole thing than spend lots of time debating which features can be removed and how much server code will be removable. I think a tiny constrained device should avoid SSH, XML, and state-full protocols for configuration management. I think operational state could be interesting to work on, but I have not seen any solution proposals, so I don't support any sort of charter item for that work yet. The NETCONF over TLS maintenance work is minor and non-controversial. I do not object to that work. > Bert > >> /js Andy >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Mon Aug 13 11:16:38 2012 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 1939021F8647 for ; Mon, 13 Aug 2012 11:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zswZuqbL0WK for ; Mon, 13 Aug 2012 11:16:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6E43321F8513 for ; Mon, 13 Aug 2012 11:16:36 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.224.21]) by mail.nic.cz (Postfix) with ESMTPSA id 2BB0A13F807 for ; Mon, 13 Aug 2012 20:16:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1344881795; bh=kVLntacjDCA4UuST84u0PVzhnnD3UVNUg202VUMz0mQ=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: Message-Id:To:Mime-Version; b=goVX35TEMoMEBH7PaAelh3nIecMUJKfojD5KXCbHmNvgGsCqdKvWzWpuntuBc4+cN yTnXkbMbzeqmZU+YfOZKKvtv52wZnpnkSOUG7TDKG42QWpEx22TKcZiQZ2qlEnpB3b PuwIqhwgaXCWdsd88+B10o9ESMveoa5R4b0NvyFc= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Aug 2012 20:16:25 +0200 Message-Id: <43AC0670-F187-4AF4-8E7F-BE6EE01D5C26@nic.cz> To: Netconf Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [Netconf] way forward 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 Aug 2012 18:16:38 -0000 Hi, my position regarding the alternatives for future NETCONF work is: - The issues of operational state representation and modelling need to = be worked on. This will most likely require changes in both base NETCONF = and YANG. - If 6241bis is started as a result of previous item, it would be very = useful to make NETCONF more modular, and also address other things = (errata, conformance, better integration with YANG). - I therefore prefer to advance the base NETCONF spec, i.e. NETCONF 1.2. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Mon Aug 13 12:50:24 2012 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 4EC1621F84DD for ; Mon, 13 Aug 2012 12:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.040, 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 AH16WPtwuZwi for ; Mon, 13 Aug 2012 12:50:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88BDF21F8643 for ; Mon, 13 Aug 2012 12:50:22 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 427F320BCD; Mon, 13 Aug 2012 21:50:18 +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 67ml4Bndd-PV; Mon, 13 Aug 2012 21:50:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC36720AFE; Mon, 13 Aug 2012 21:50:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3FAAD211E500; Mon, 13 Aug 2012 21:50:17 +0200 (CEST) Date: Mon, 13 Aug 2012 21:50:16 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20120813195015.GA7839@elstar.local> Mail-Followup-To: Ladislav Lhotka , Netconf References: <43AC0670-F187-4AF4-8E7F-BE6EE01D5C26@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43AC0670-F187-4AF4-8E7F-BE6EE01D5C26@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] way forward X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 19:50:24 -0000 On Mon, Aug 13, 2012 at 08:16:25PM +0200, Ladislav Lhotka wrote: > Hi, > > my position regarding the alternatives for future NETCONF work is: > > - The issues of operational state representation and modelling need to be worked on. This will most likely require changes in both base NETCONF and YANG. > - If 6241bis is started as a result of previous item, it would be very useful to make NETCONF more modular, and also address other things (errata, conformance, better integration with YANG). > - I therefore prefer to advance the base NETCONF spec, i.e. NETCONF 1.2. > My position is as follows: a) We should finish the NETCONF over TLS update. b) The WG needs to define how to retrieve and perhaps edit operational state. This is crucial, without a solution for this, NETCONF remains incomplete. Since I find retrieval of operational state crucial, I would rather have the solution part of NETCONF 1.2 instead of a separate extension. My recommendation is that people (or groups of people) draft proposals (individual IDs) and the WG selects one by the next IETF to be incorporated into NETCONF 1.2. c) Implementors need to do interoperability testing. It is crucial to understand to what extend the specifications we have lead to interoperable implementations. I know that interoperability testing is not really a WG work item for a WG charter but it is crucial to undertake this activity since usually such tests also identify bugs in the specifications. d) Any errata and any interoperability test results identifying unclear aspects of the specification should be incorporated into NETCONF 1.2. Ideally, NETCONF 1.2. would prove to be bug free enough that it later can even advance without re-publication. e) I have no clear opinion concerning modularization. In my view, we should not do anything at this point in time to support NETCONF on very constrained devices. If we do some modularization, then we should look at interoperability issues with boxes that do not support NETCONF fully because they proxy for boxes that say can't do locking or they do not support structured data models. Some of the solutions such as lying about locks or pretending that the data model of the box is just a single element likely are worse than adding a few well selected features. Truth in advertising I believe is desirable and helpful for interoperability. My recommendation here would as well be that people (or groups of people) draft concrete modularization proposals (individual IDs) and the WG selects by the next IETF. And the selection might very well be an empty set. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Mon Aug 13 13:13:56 2012 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 4501021F85FF for ; Mon, 13 Aug 2012 13:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.814 X-Spam-Level: X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 580BDxHtKK1U for ; Mon, 13 Aug 2012 13:13:55 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 590E821F8602 for ; Mon, 13 Aug 2012 13:13:55 -0700 (PDT) Received: by qadz3 with SMTP id z3so1428871qad.10 for ; Mon, 13 Aug 2012 13:13:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=u/YpMyFoZIlnE1LERFvDsdsGCcV88bKXvg9q8iDJalg=; b=dEF43UW6xWsuWyZtCDVINexjyKamgPb9xlP7Sb0Bq2mwMIhZCAxllTACgnyOPN69Gx bNJhyOmpVuNec/3nBm1yrNsHErbf2PRxwgOHUdGKf5kr2wycd/OM/8SURScfouwdymfy F76CsNbuuttQAEtOqxX1XFzucg0H5doPHy4puJFwiCIvWmu4sKRM87QV/4pppPZXCPph s/fqfSBKqCT3LM22v3yfwEnbBKV6J2dNIEma5HbG4fC+Q1fTInt4EpmADV8WoLAbJGeW O6T2lNir9JzkLtzUPf2OxIxbp+qyHAaYDlWbk6ItYkU9xNQDPcvPHzCk4AZgS7+lWbZT DZaA== MIME-Version: 1.0 Received: by 10.224.175.6 with SMTP id v6mr28043270qaz.36.1344888834741; Mon, 13 Aug 2012 13:13:54 -0700 (PDT) Received: by 10.49.12.67 with HTTP; Mon, 13 Aug 2012 13:13:54 -0700 (PDT) In-Reply-To: <20120813195015.GA7839@elstar.local> References: <43AC0670-F187-4AF4-8E7F-BE6EE01D5C26@nic.cz> <20120813195015.GA7839@elstar.local> Date: Mon, 13 Aug 2012 13:13:54 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Netconf Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnp4+pnAINs6epR5KJJ9TSg23YdvzjnFq2MEh7PcrAmy02SJKbVlf/kZx4GKt9B4r2e6h78 Subject: Re: [Netconf] way forward 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 Aug 2012 20:13:56 -0000 Hi, I don't agree that protocol modularity is an important problem to solve. The protocol is already very modular, in that there MUST implement list for a server is already quite small, considering "read-only running" is the minimum requirement. I do not agree operational-state is critical to solve. I have not seen a clear problem statement yet. We can go looking for corner-cases to solve, with ever diminishing returns on WG effort and time. There are work-arounds to the operational state problems (define 2 leafs ala admin/operStatus for duplex=auto; define custom write-state RPC operation). I don't agree the operational state problem requires that the protocol version be updated and base:1.1 be made obsolete. I agree with Phil that we should not even send the signal that base:1.1 is going to be obsolete, and replaced by a base:1.2. We can continue to add nice-to-have operations and capabilities, without continuously spinning the base protocol. Andy On Mon, Aug 13, 2012 at 12:50 PM, Juergen Schoenwaelder wrote: > On Mon, Aug 13, 2012 at 08:16:25PM +0200, Ladislav Lhotka wrote: >> Hi, >> >> my position regarding the alternatives for future NETCONF work is: >> >> - The issues of operational state representation and modelling need to be worked on. This will most likely require changes in both base NETCONF and YANG. >> - If 6241bis is started as a result of previous item, it would be very useful to make NETCONF more modular, and also address other things (errata, conformance, better integration with YANG). >> - I therefore prefer to advance the base NETCONF spec, i.e. NETCONF 1.2. >> > > My position is as follows: > > a) We should finish the NETCONF over TLS update. > > b) The WG needs to define how to retrieve and perhaps edit operational > state. This is crucial, without a solution for this, NETCONF > remains incomplete. Since I find retrieval of operational state > crucial, I would rather have the solution part of NETCONF 1.2 > instead of a separate extension. > > My recommendation is that people (or groups of people) draft > proposals (individual IDs) and the WG selects one by the next IETF > to be incorporated into NETCONF 1.2. > > c) Implementors need to do interoperability testing. It is crucial to > understand to what extend the specifications we have lead to > interoperable implementations. I know that interoperability testing > is not really a WG work item for a WG charter but it is crucial to > undertake this activity since usually such tests also identify bugs > in the specifications. > > d) Any errata and any interoperability test results identifying > unclear aspects of the specification should be incorporated into > NETCONF 1.2. Ideally, NETCONF 1.2. would prove to be bug free > enough that it later can even advance without re-publication. > > e) I have no clear opinion concerning modularization. In my view, we > should not do anything at this point in time to support NETCONF on > very constrained devices. If we do some modularization, then we > should look at interoperability issues with boxes that do not > support NETCONF fully because they proxy for boxes that say can't > do locking or they do not support structured data models. Some of > the solutions such as lying about locks or pretending that the data > model of the box is just a single element likely are worse than > adding a few well selected features. Truth in advertising I believe > is desirable and helpful for interoperability. > > My recommendation here would as well be that people (or groups of > people) draft concrete modularization proposals (individual IDs) > and the WG selects by the next IETF. And the selection might very > well be an empty set. > > /js > > -- > 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 phil@juniper.net Mon Aug 13 14:44:34 2012 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 B9EC021F8606 for ; Mon, 13 Aug 2012 14:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, 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 i2GQ0Es8IUu3 for ; Mon, 13 Aug 2012 14:44:34 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 120B521F85DF for ; Mon, 13 Aug 2012 14:44:18 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUCl1MRkxuEZPcLzm+gFmP5S/6nunmlFQ@postini.com; Mon, 13 Aug 2012 14:44:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 13 Aug 2012 14:43:55 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7DLhrh16802; Mon, 13 Aug 2012 14:43:54 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7DLgqD4071870; Mon, 13 Aug 2012 17:43:17 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208132143.q7DLgqD4071870@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20120813195015.GA7839@elstar.local> Date: Mon, 13 Aug 2012 17:42:52 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: Netconf Subject: Re: [Netconf] way forward 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 Aug 2012 21:44:34 -0000 My position is: - NETCONF and YANG do not need further churn - Churn discourages adoption - The "1.2" effort should be avoided - The needs of NETCONF are already very low - Lowering them is pointless - I've no sympathy for the argument that implementing a single global lock is too expensive - Operational state is an unsolved problem - There is no single, simple way to represent this data - SDN, IRS, and other related projects are looking at data that is neither config, nor operational data and we need to investigate their needs and find suitable means of modeling this data - The above two items can be solved using extensions (no churn) Thanks, Phil From kwatsen@juniper.net Mon Aug 13 15:28:22 2012 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 B358421F86A5 for ; Mon, 13 Aug 2012 15:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Hb0gljJfD6Mc for ; Mon, 13 Aug 2012 15:28:22 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 1625921F84CE for ; Mon, 13 Aug 2012 15:28:22 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUCl/g6Z1ztKp0qJQQ4cAdxWGktnheup0@postini.com; Mon, 13 Aug 2012 15:28:22 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 13 Aug 2012 15:28:19 -0700 From: Kent Watsen To: Phil Shafer , Juergen Schoenwaelder Date: Mon, 13 Aug 2012 15:28:17 -0700 Thread-Topic: [Netconf] way forward Thread-Index: Ac15ovA4LHIgyW8LSt6j3onlq+5ktw== Message-ID: In-Reply-To: <201208132143.q7DLgqD4071870@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Netconf Subject: Re: [Netconf] way forward 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 Aug 2012 22:28:22 -0000 On 8/13/12 5:42 PM, "Phil Shafer" wrote: > - I've no sympathy for the argument that implementing > a single global lock is too expensive Again, it's not an issue of it being difficult for the device team to implement locking. Since we're developing an off-box device-adapter, the device-team doesn't even know there is a need. I don't know why they don't have a global lock, perhaps they think that only having writable-running makes it safe enough, but it doesn't matter, our device-adapter is *lying* about the device fully supporting NETCONF and blindly returns for lock/unlock. Kent From andy@yumaworks.com Mon Aug 13 16:28:20 2012 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 E76D121F8691 for ; Mon, 13 Aug 2012 16:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.817 X-Spam-Level: X-Spam-Status: No, score=-2.817 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfn7xT85FNfj for ; Mon, 13 Aug 2012 16:28:20 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC0F21F8690 for ; Mon, 13 Aug 2012 16:28:20 -0700 (PDT) Received: by qadz3 with SMTP id z3so1543098qad.10 for ; Mon, 13 Aug 2012 16:28:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EkNtSCjVS525GVZ4whcdMdszrJur1WxJ5LveGbyiHDs=; b=Veyjwj3LhUPX2dp9w1YJY2R/fOogKL/RX+NYCD+gVytctCQ+mH7uBor2SmYHllU0Kf KSxJAWV54JZ3HPrHm/YlS0l7e83Vu6PwXIj2p6r56zemLhA7/FUe1JC3DczynqgDewxv xKJu3h1X8Rc8lqM08TCU780HiF5ZckSXhQlZrnAI11KKboDHyu/U/BR6nYXtBrdP98iV oksZW9OHGBmj+zcb5hfEAPotKKvdnjk3C/XBprW8jq58OEkUSVRD+RWWRVm4c78JIpmT ukFv14eZlq16ltMpN0H39fSB6/PKL9hvlMPZUEHymLQUoQXQ6RI3lcmHfoAqYRXSv6dI 0tAg== MIME-Version: 1.0 Received: by 10.224.39.195 with SMTP id h3mr16810567qae.10.1344900499774; Mon, 13 Aug 2012 16:28:19 -0700 (PDT) Received: by 10.49.12.67 with HTTP; Mon, 13 Aug 2012 16:28:19 -0700 (PDT) In-Reply-To: References: <201208132143.q7DLgqD4071870@idle.juniper.net> Date: Mon, 13 Aug 2012 16:28:19 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQms5lm5pLxehhcTbeCx5EU/GwBawt8sId4HtNIRPw332Subl6lfG3yU4tXkw94/xwjsajsa Cc: Netconf Subject: Re: [Netconf] way forward 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 Aug 2012 23:28:21 -0000 On Mon, Aug 13, 2012 at 3:28 PM, Kent Watsen wrote: > > > On 8/13/12 5:42 PM, "Phil Shafer" wrote: >> - I've no sympathy for the argument that implementing >> a single global lock is too expensive > > > Again, it's not an issue of it being difficult for the device team to > implement locking. Since we're developing an off-box device-adapter, the > device-team doesn't even know there is a need. I don't know why they > don't have a global lock, perhaps they think that only having > writable-running makes it safe enough, but it doesn't matter, our > device-adapter is *lying* about the device fully supporting NETCONF and > blindly returns for lock/unlock. > Implementation costs will vary greatly for individual features. We really have to look at a feature and decide if the standard really needs it to be robust and interoperable. IMO, global locking meets this test. It cannot be removed. There are many known deadlock scenarios and other 'bad outcome' operation sequences that cannot occur if locking is properly used. Subtree filtering and edit-config may not meet this test, but the alternate solutions are extremely inefficient. These are the most popular features of NETCONF, not some obscure unused operations. > Kent > Andy From mehmet.ersue@nsn.com Wed Aug 15 04:58:44 2012 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 0D39221F8543 for ; Wed, 15 Aug 2012 04:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 OwQqNKUSU2gj for ; Wed, 15 Aug 2012 04:58:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 33B9C21F853C for ; Wed, 15 Aug 2012 04:58:40 -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 q7FBwX1U029572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 15 Aug 2012 13:58:33 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7FBwVpU032648 for ; Wed, 15 Aug 2012 13:58:33 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Aug 2012 13:58:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Aug 2012 13:58:24 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64041CE046@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes of the IETF 84 NETCONF Session Thread-Index: Ac0cedvqtQ/Bpi9rSxu49Taq9tOJHBeYn+nQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 15 Aug 2012 11:58:24.0880 (UTC) FILETIME=[46437700:01CD7ADD] 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: 288 X-purgate-ID: 151667::1345031913-00003184-1ADC6911/0-0/0-0 Subject: [Netconf] Draft minutes of the IETF 84 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 11:58:44 -0000 Dear NETCONF WG, draft minutes of the IETF 84 NETCONF WG Session are available: http://www.ietf.org/proceedings/84/minutes/minutes-84-netconf Please send us your comments by August 28, 2012. Many thanks to our minute takers: Lada Lhotka and Juergen Schoenwaelder. Mehmet=20 From mbj@tail-f.com Wed Aug 15 13:18:02 2012 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 95CE821F8615 for ; Wed, 15 Aug 2012 13:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.095, 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 5UqlbYLXguz4 for ; Wed, 15 Aug 2012 13:18: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 F36D021F8613 for ; Wed, 15 Aug 2012 13:18:01 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BED051200D10; Wed, 15 Aug 2012 22:17:52 +0200 (CEST) Date: Wed, 15 Aug 2012 22:17:51 +0200 (CEST) Message-Id: <20120815.221751.115590151.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <5020FA9F.9000200@bwijnen.net> References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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, 15 Aug 2012 20:18:03 -0000 Hi, We (tail-f) have a couple of different NETCONF clients, and a NETCONF server, implementing 1.0 and 1.1. I would prefer a f2f meeting for the interop, b/c I believe we can easier discuss interpretations of the text and fix issues in the code and continue testing if we meet. If Amsterdam (or Bremen) is difficult, how about doing the interop say Saturday / Sunday before the next IETF? /martin "Bert Wijnen (IETF)" wrote: > So, to my offer: > > On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: > > But interoperability testing is not necessarily a WG chartered > > activity or obligation. Of course if we as WG chairs can help > > to get such an event going, we will do so as much as we can. > > > > Do we want to do this ASAP or at or around the next IETF? > > If ASAP, is anyone offering to arrange it at their site/location? > > If needed, I think I can arrange space at the RIPE-NCC in > > Amsterdam. Let me know if I should investigate. > > I have hear a "yes I am interested" from Andy and from Martin. > Are there any others? > > I don't think that organizing ot for just 2 implementations > makes sense... well, they could then visit each other instead > of me organizing it in Amsterdam. > > So pls express your potential interest before Aug 15th. > If there is enough interest, then I will investigate possible > options in Amsterdam. > > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Aug 15 13:31:12 2012 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 3579221F8503 for ; Wed, 15 Aug 2012 13:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=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 gNMrmnErufSH for ; Wed, 15 Aug 2012 13:31:11 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F33E21F845C for ; Wed, 15 Aug 2012 13:31:11 -0700 (PDT) Received: by qcac10 with SMTP id c10so1759515qca.31 for ; Wed, 15 Aug 2012 13:31:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=fS6F9kpM8f6irFOKKKPXPlpyrBuv4JKx6aj6azCtHIQ=; b=BZG5Crs02+eK9km/q6z12/cOYjRuHGWcPgNhx6dREry+daaS1Z2Pz2PDBddGlamngf 6r1ivLJwrfJRktJvP7o+uDBhU4wx2AWvE2gqYxtsC9chlGzb17W2nmLm/VFksa28Xw5r C9hHvl42dGBuNLoiV0wi80sKysiUulnZwW/4skQjZpFVyMr+FUeoJEq9SpwXCzNR9fzz pERrX+NmOW/VDXfv6/Rexi0vCbtPGMD/QZv4WbwjzgdC1m9Ljm7xVSvYfJPKcILisxVU 17zkwbHx3ZVWcMn/ooMmatGrejMp0eSWO9VUGK0BELnh7WFvJPJNc84TxVXIICZyVR24 UUVQ== MIME-Version: 1.0 Received: by 10.224.181.16 with SMTP id bw16mr36051597qab.35.1345062670898; Wed, 15 Aug 2012 13:31:10 -0700 (PDT) Received: by 10.49.74.161 with HTTP; Wed, 15 Aug 2012 13:31:10 -0700 (PDT) In-Reply-To: <20120815.221751.115590151.mbj@tail-f.com> References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> <20120815.221751.115590151.mbj@tail-f.com> Date: Wed, 15 Aug 2012 13:31:10 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkSjN0WXTk44bGjCosetWPeNrxk7skW8z0n1T/9KpAA289gqNtFgGqnKcjJWWygxlSc3E93 Cc: netconf@ietf.org Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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, 15 Aug 2012 20:31:12 -0000 On Wed, Aug 15, 2012 at 1:17 PM, Martin Bjorklund wrote: > Hi, > > We (tail-f) have a couple of different NETCONF clients, and a NETCONF > server, implementing 1.0 and 1.1. > > I would prefer a f2f meeting for the interop, b/c I believe we can > easier discuss interpretations of the text and fix issues in the code > and continue testing if we meet. If Amsterdam (or Bremen) is > difficult, how about doing the interop say Saturday / Sunday before > the next IETF? > > That is a good idea, except it might be better Friday/Saturday if people have IETF (or other I*) meetings on Sunday. Not sure how we test servers embedded in networking devices either. What modules are we testing? Just published in RFCs? Not much config=true so far. I would not blame vendors for waiting until the new modules are published before starting any implementations. > /martin > Andy > > > "Bert Wijnen (IETF)" wrote: >> So, to my offer: >> >> On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >> > But interoperability testing is not necessarily a WG chartered >> > activity or obligation. Of course if we as WG chairs can help >> > to get such an event going, we will do so as much as we can. >> > >> > Do we want to do this ASAP or at or around the next IETF? >> > If ASAP, is anyone offering to arrange it at their site/location? >> > If needed, I think I can arrange space at the RIPE-NCC in >> > Amsterdam. Let me know if I should investigate. >> >> I have hear a "yes I am interested" from Andy and from Martin. >> Are there any others? >> >> I don't think that organizing ot for just 2 implementations >> makes sense... well, they could then visit each other instead >> of me organizing it in Amsterdam. >> >> So pls express your potential interest before Aug 15th. >> If there is enough interest, then I will investigate possible >> options in Amsterdam. >> >> Bert >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mbj@tail-f.com Wed Aug 15 13:33:25 2012 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 6FB5B21F86AB for ; Wed, 15 Aug 2012 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.088, 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 HI5uPcF7k28O for ; Wed, 15 Aug 2012 13:33:25 -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 E0EEF21F86A8 for ; Wed, 15 Aug 2012 13:33:24 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 31E861200AE5 for ; Wed, 15 Aug 2012 22:33:24 +0200 (CEST) Date: Wed, 15 Aug 2012 22:33:22 +0200 (CEST) Message-Id: <20120815.223322.474270084.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund In-Reply-To: <20120813195015.GA7839@elstar.local> References: <43AC0670-F187-4AF4-8E7F-BE6EE01D5C26@nic.cz> <20120813195015.GA7839@elstar.local> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] way forward 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, 15 Aug 2012 20:33:25 -0000 Hi, I agree that work needs to be done on the operational state problem (and I plan to work on this and submit an individual I-D). However, I think it might be too early to say if the solution to this problem requires an update to NETCONF and/or YANG, or can be done using only extensions. I do not think the WG should do further modularization of the base protocol. /martin From xiangli@seguesoft.com Wed Aug 15 13:43:51 2012 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 229E411E809A for ; Wed, 15 Aug 2012 13:43:51 -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 EppCZx4xuSII for ; Wed, 15 Aug 2012 13:43:50 -0700 (PDT) Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5334811E808A for ; Wed, 15 Aug 2012 13:43:50 -0700 (PDT) Received: from [192.168.2.10] ([98.212.151.151]) by p3plsmtpa06-06.prod.phx3.secureserver.net with id n8jo1j0083GEayi018jpYW; Wed, 15 Aug 2012 13:43:49 -0700 Message-ID: <502C0A07.5050302@seguesoft.com> Date: Wed, 15 Aug 2012 15:43:51 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> <20120815.221751.115590151.mbj@tail-f.com> In-Reply-To: <20120815.221751.115590151.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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, 15 Aug 2012 20:43:51 -0000 On 8/15/2012 3:17 PM, Martin Bjorklund wrote: > Hi, > > We (tail-f) have a couple of different NETCONF clients, and a NETCONF > server, implementing 1.0 and 1.1. > > I would prefer a f2f meeting for the interop, b/c I believe we can > easier discuss interpretations of the text and fix issues in the code > and continue testing if we meet. If Amsterdam (or Bremen) is > difficult, how about doing the interop say Saturday / Sunday before > the next IETF? I like this idea. --Xiang Li > > /martin > > > > "Bert Wijnen (IETF)" wrote: >> So, to my offer: >> >> On 8/2/12 8:13 PM, Bert Wijnen (IETF) wrote: >>> But interoperability testing is not necessarily a WG chartered >>> activity or obligation. Of course if we as WG chairs can help >>> to get such an event going, we will do so as much as we can. >>> >>> Do we want to do this ASAP or at or around the next IETF? >>> If ASAP, is anyone offering to arrange it at their site/location? >>> If needed, I think I can arrange space at the RIPE-NCC in >>> Amsterdam. Let me know if I should investigate. >> I have hear a "yes I am interested" from Andy and from Martin. >> Are there any others? >> >> I don't think that organizing ot for just 2 implementations >> makes sense... well, they could then visit each other instead >> of me organizing it in Amsterdam. >> >> So pls express your potential interest before Aug 15th. >> If there is enough interest, then I will investigate possible >> options in Amsterdam. >> >> Bert >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Thu Aug 16 00:21:43 2012 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 5B6C821F856F for ; Thu, 16 Aug 2012 00:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70Edi4wGH6EX for ; Thu, 16 Aug 2012 00:21:42 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C1BBA21F8575 for ; Thu, 16 Aug 2012 00:21:42 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T1uOj-0006FT-5E for netconf@ietf.org; Thu, 16 Aug 2012 09:21:42 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest102.guestnet.ripe.net) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T1uOj-0004oB-1T for netconf@ietf.org; Thu, 16 Aug 2012 09:21:41 +0200 Message-ID: <502C9F8A.8000800@bwijnen.net> Date: Thu, 16 Aug 2012 09:21:46 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> <20120815.221751.115590151.mbj@tail-f.com> In-Reply-To: <20120815.221751.115590151.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120816 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4dcef52c9550fab1809b7cd7cb89b99d8 Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 07:21:43 -0000 So... Anyone who knows people that can help with arranging a location in Atlanta, before the Next IETF. I think the dates would indeed best be Friday and Saturday 2-3 November 2012. Bert On 8/15/12 10:17 PM, Martin Bjorklund wrote: > I would prefer a f2f meeting for the interop, b/c I believe we can > easier discuss interpretations of the text and fix issues in the code > and continue testing if we meet. If Amsterdam (or Bremen) is > difficult, how about doing the interop say Saturday / Sunday before > the next IETF? From andy@yumaworks.com Thu Aug 16 07:57:08 2012 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 6198521F85C7 for ; Thu, 16 Aug 2012 07:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.818 X-Spam-Level: X-Spam-Status: No, score=-2.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td1FU7-g06QT for ; Thu, 16 Aug 2012 07:57:07 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF621F84F4 for ; Thu, 16 Aug 2012 07:57:07 -0700 (PDT) Received: by qcac10 with SMTP id c10so2432799qca.31 for ; Thu, 16 Aug 2012 07:57:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=tFUQadA2w8H+8BtlXvGmfrprZnIqI9AcC0LDgaDywiI=; b=ioRidCLx9oXzz0n5aGxlag2e9fIz1dU1EA0S09bVvfil7kWjHI5KnJaqabmOVyUoV2 /rJenJW7YKkVG86y+SeaD430Y4NeYAd2LOB2LYzpp/h99Wf+pspKr4/Um/PramRUxg1W TCBLTfE66cYDkMS90eU7iH16jc8JsDZVu3xO78W1Rkr4jJv5IYWeTAdTZCIG/djY2NOQ Qu8NUx71/rYulaZf0q4pr+KwAIkVLi+wYhiNRWFATmhSz9heAkp9uwGc0H462dIcqvTu lFmMZo9H+5gEeD0ChLvkuFgp1JTlnk2EBQzsM8TS5f+TtN4dcR68LC8ap3RwnZ/ogcen bpKw== MIME-Version: 1.0 Received: by 10.224.211.137 with SMTP id go9mr3680358qab.77.1345129026716; Thu, 16 Aug 2012 07:57:06 -0700 (PDT) Received: by 10.49.74.161 with HTTP; Thu, 16 Aug 2012 07:57:06 -0700 (PDT) In-Reply-To: <502C9F8A.8000800@bwijnen.net> References: <20120802180300.GB86840@elstar.local> <501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net> <20120815.221751.115590151.mbj@tail-f.com> <502C9F8A.8000800@bwijnen.net> Date: Thu, 16 Aug 2012 07:57:06 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmcpvNBpXKGU41GH03vE30uyAPqRAAf6YLofUI7c4yVYzp51hHqrzHIv+wuWMZmX/Bg4bbx Cc: netconf@ietf.org Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 14:57:08 -0000 On Thu, Aug 16, 2012 at 12:21 AM, Bert Wijnen (IETF) wrote: > So... > > Anyone who knows people that can help with arranging a location > in Atlanta, before the Next IETF. > I think the dates would indeed best be Friday and Saturday > 2-3 November 2012. This sort of test event requires some planning. IMO people should not be required to attend in person so conference calls (WebEx?) will be needed. Shipping routers and switches to Atlanta for this test seems extreme, so vendors should be able to setup servers in a DMZ for testing. Decent Internet connectivity will be needed (IETF net will not be ready so have to use hotel wifi). Mutual NDA is usually required. The point of the test is to improve code, not beat up vendors for having bugs. We can report problem areas in the RFCs without identifying which implementations had trouble. We need to identify 'false interoperability' (e.g., client apps that have been working for years with various servers by coding workarounds to particular server bugs.) If we need to spend a lot of time setting up equipment, then we have to rent a conf. room that can be locked. IMO, if we brought some Ethernet hubs and cables, we could find somewhere to test each day, and not leave equipment setup. If we find (after bugfixes) that we have at least 2 independent implementations of all features, then the discussion about base:1.2 vs. standards advancement of base:1.1 will get interesting. ;-) > > Bert Andy > > On 8/15/12 10:17 PM, Martin Bjorklund wrote: >> >> I would prefer a f2f meeting for the interop, b/c I believe we can >> easier discuss interpretations of the text and fix issues in the code >> and continue testing if we meet. If Amsterdam (or Bremen) is >> difficult, how about doing the interop say Saturday / Sunday before >> the next IETF? > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From mehmet.ersue@nsn.com Thu Aug 16 08:55:08 2012 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 3D31521F845F for ; Thu, 16 Aug 2012 08:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QmFJYsGcy14 for ; Thu, 16 Aug 2012 08:55:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4C05021F8460 for ; Thu, 16 Aug 2012 08:55:02 -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 q7GFswBL029838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Aug 2012 17:54:58 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7GFsuMs026819; Thu, 16 Aug 2012 17:54:58 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 16 Aug 2012 17:54:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2012 17:54:50 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404219B56@DEMUEXC006.nsn-intra.net> In-Reply-To: <502C9F8A.8000800@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Interoperability Testing - Action before Aug 15th Thread-Index: Ac17f8+NLv5nrmYtQxWluKF0CIB1DQAP56QQ References: <20120802180300.GB86840@elstar.local><501AC35A.4060107@bwijnen.net> <5020FA9F.9000200@bwijnen.net><20120815.221751.115590151.mbj@tail-f.com> <502C9F8A.8000800@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 16 Aug 2012 15:54:51.0415 (UTC) FILETIME=[7882AA70:01CD7BC7] 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: 1882 X-purgate-ID: 151667::1345132499-00003184-CAF40CE6/0-0/0-0 Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th 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 Aug 2012 15:55:08 -0000 Hi All,=20 it seems that I can book some rooms for November 2-3, 2012 in NSN Atlanta office at the Glenridge connector NE, which is 12-13 miles away from Atlanta downtown. There are hotels nearby, e.g. Courtyard Perimet Ctr Marriott and Holiday Inn Express (less expensive), The Westin Atlanta North (closest). May be should organize to book the same hotel to ease the transport. The meeting rooms AFAIK have beamer, phone and Internet connection via WLAN. I assume we bring the equipment we need such as notebooks, some Ethernet hubs and cables, etc. To get into the building on Saturday I definitely need the concrete name list some time earlier. So, whether we do such an interop event we should decide by e.g. October 1, 2012 and people interested should let me know their full name and affiliation by then privately. Cheers,=20 Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Bert Wijnen (IETF) > Sent: Thursday, August 16, 2012 9:22 AM > To: netconf@ietf.org > Subject: Re: [Netconf] Interoperability Testing - Action before Aug 15th >=20 > So... >=20 > Anyone who knows people that can help with arranging a location > in Atlanta, before the Next IETF. > I think the dates would indeed best be Friday and Saturday > 2-3 November 2012. >=20 > Bert >=20 > On 8/15/12 10:17 PM, Martin Bjorklund wrote: > > I would prefer a f2f meeting for the interop, b/c I believe we can > > easier discuss interpretations of the text and fix issues in the code > > and continue testing if we meet. If Amsterdam (or Bremen) is > > difficult, how about doing the interop say Saturday / Sunday before > > the next IETF? > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Thu Aug 16 15:12:40 2012 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 5276911E808E for ; Thu, 16 Aug 2012 15:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.361 X-Spam-Level: X-Spam-Status: No, score=-102.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhwPI9cb7kVl for ; Thu, 16 Aug 2012 15:12:39 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 898F311E808A for ; Thu, 16 Aug 2012 15:12:37 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T28Is-0007HN-QB for netconf@ietf.org; Fri, 17 Aug 2012 00:12:35 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T28Is-0007oG-ML for netconf@ietf.org; Fri, 17 Aug 2012 00:12:34 +0200 Message-ID: <502D7052.2070302@bwijnen.net> Date: Fri, 17 Aug 2012 00:12:34 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf References: <502D073D.7090200@bwijnen.net> In-Reply-To: <502D073D.7090200@bwijnen.net> X-Forwarded-Message-Id: <502D073D.7090200@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120816 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4296b24f21f728df0710e517ba750f1a7 Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 22:12:40 -0000 Based on the comments and feedback and the positions expressed on the mailing list, it is clear that after all we did NOT have consensus on the new WG charter. Without further ado, this is another proposed WG charter. It focuses on the things that we do seme to have agreement on. Pls comment and/or express your support or objections no later than August 31, 2012. OK, new chapter text (omitting the description of what we have achieved sofar): In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. Based on the implementation, deployment experience and interoperability testing, the WG will document the status of NETCONF in a report. Based on this, the WG may decide to make some clarifications to RFC6241 and RFC6242 (then also fixing any reported errata). 3. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis 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 NACM posted 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 Aug 2012 - submit initial WG draft for rfc5539bis Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. Sep 2012 - WGLC for rfc5539bis Sep 2012 - WGLC for RFC4743 and 4743 to historic Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc to IESG for publication as Informational RFC. Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG Bert and Mehmet From mehmet.ersue@nsn.com Fri Aug 17 01:36:04 2012 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 624F821F855B for ; Fri, 17 Aug 2012 01:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgmMhU-x2-wU for ; Fri, 17 Aug 2012 01:36:03 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0CA21F8554 for ; Fri, 17 Aug 2012 01:36:03 -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 q7H8ZvYL004609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Aug 2012 10:35:57 +0200 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7H8Zskp005173; Fri, 17 Aug 2012 10:35:57 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 17 Aug 2012 10:35:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Aug 2012 10:35:50 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A6404219C07@DEMUEXC006.nsn-intra.net> In-Reply-To: <502D7052.2070302@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st Thread-Index: Ac17/ESKSoquOdBsQ82ldC2NP9hVEQAU5zSA References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf" X-OriginalArrivalTime: 17 Aug 2012 08:35:51.0158 (UTC) FILETIME=[4EE82960:01CD7C53] 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: 3488 X-purgate-ID: 151667::1345192559-00006F5F-3CE97EBD/0-0/0-0 Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 08:36:04 -0000 It is not necessary to mention in the charter that interested parties can bring I-Ds into discussion following the usual WG process. Mehmet=20 > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext > Bert Wijnen (IETF) > Sent: Friday, August 17, 2012 12:13 AM > To: netconf > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORESept > 1st >=20 >=20 > Based on the comments and feedback and the positions > expressed on the mailing list, it is clear that after all > we did NOT have consensus on the new WG charter. >=20 > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. >=20 > Pls comment and/or express your support or objections > no later than August 31, 2012. >=20 > OK, new chapter text (omitting the description of what we have > achieved sofar): >=20 > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: >=20 > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. >=20 > 2. Based on the implementation, deployment experience and interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). >=20 > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. >=20 > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG >=20 > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From lhotka@nic.cz Fri Aug 17 02:04:27 2012 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 4916F21F84DF for ; Fri, 17 Aug 2012 02:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.966 X-Spam-Level: X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSgI7XMu91hc for ; Fri, 17 Aug 2012 02:04:26 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5097A21F845F for ; Fri, 17 Aug 2012 02:04:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id AD3C8540297; Fri, 17 Aug 2012 11:04:24 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKdHxLhtAadZ; Fri, 17 Aug 2012 11:04:20 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 7D05D540222; Fri, 17 Aug 2012 11:04:19 +0200 (CEST) From: Ladislav Lhotka To: "Bert Wijnen \(IETF\)" , netconf In-Reply-To: <502D7052.2070302@bwijnen.net> References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Fri, 17 Aug 2012 11:04:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 09:04:27 -0000 Hi, I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. So I propose the following fourth item for the charter: 4. The WG will investigate the relationship and interactions between configurations and operational state data, propose their appropriate representation and semantics, and devise methods for effective data modeling of both configurations and operational state data. It is expected that this work will be carried out in a close sooperation with the NETMOD WG. Lada "Bert Wijnen (IETF)" writes: > Based on the comments and feedback and the positions > expressed on the mailing list, it is clear that after all > we did NOT have consensus on the new WG charter. > > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. > > Pls comment and/or express your support or objections > no later than August 31, 2012. > > OK, new chapter text (omitting the description of what we have > achieved sofar): > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. Based on the implementation, deployment experience and interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG > > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Fri Aug 17 02:09:21 2012 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 BFD4221F846E for ; Fri, 17 Aug 2012 02:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+8vfiimZux8 for ; Fri, 17 Aug 2012 02:09:20 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2626A21F8598 for ; Fri, 17 Aug 2012 02:09:20 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T2IYO-0008VE-GD; Fri, 17 Aug 2012 11:09:18 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T2IYO-0001Pi-7O; Fri, 17 Aug 2012 11:09:16 +0200 Message-ID: <502E0A3B.9010008@bwijnen.net> Date: Fri, 17 Aug 2012 11:09:15 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120817 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd442e999a97e04743cf69f82c2058edbf4 Cc: netconf Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 09:09:21 -0000 We had agreed in our last f2f meeting that people would submit individual I-Ds, and based on that we would potentially consider work in this space. So by all means do submit such individual drafts and discuss them on the mailing list. But we do not have a good problem statement or starting I-D to base this work on, so cannot put it on the current charter. Bert Wijnen On 8/17/12 11:04 AM, Ladislav Lhotka wrote: > Hi, > > I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. > > So I propose the following fourth item for the charter: > > 4. The WG will investigate the relationship and interactions between configurations and > operational state data, propose their appropriate representation and semantics, and > devise methods for effective data modeling of both configurations and operational state data. > It is expected that this work will be carried out in a close sooperation with the NETMOD WG. > > Lada > > "Bert Wijnen (IETF)" writes: > >> Based on the comments and feedback and the positions >> expressed on the mailing list, it is clear that after all >> we did NOT have consensus on the new WG charter. >> >> Without further ado, this is another proposed WG charter. >> It focuses on the things that we do seme to have agreement on. >> >> Pls comment and/or express your support or objections >> no later than August 31, 2012. >> >> OK, new chapter text (omitting the description of what we have >> achieved sofar): >> >> In the current phase of the incremental development of NETCONF the >> workgroup will focus on following items: >> >> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >> This means that RFC5593 needs to be updated. >> >> 2. Based on the implementation, deployment experience and interoperability >> testing, the WG will document the status of NETCONF in a report. >> Based on this, the WG may decide to make some clarifications to >> RFC6241 and RFC6242 (then also fixing any reported errata). >> >> 3. Since Netconf over BEEP and over SOAP seem not being deployed >> the WG will write a document that makes those 2 protocols >> (RFC4743 and RFC4744) HISTORIC. >> >> Goals and Milestones: >> done - Send with-defaults to IESG for consideration as Proposed Standard >> done - WG Last Call on rfc4741bis >> 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 NACM posted >> 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 >> Aug 2012 - submit initial WG draft for rfc5539bis >> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. >> Sep 2012 - WGLC for rfc5539bis >> Sep 2012 - WGLC for RFC4743 and 4743 to historic >> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard >> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic >> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 >> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience >> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >> Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc >> to IESG for publication as Informational RFC. >> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG >> >> Bert and Mehmet >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From ietfc@btconnect.com Mon Aug 20 02:41:51 2012 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 9E8B721F86F7 for ; Mon, 20 Aug 2012 02:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_40=-0.185, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7G51jmzSKkU for ; Mon, 20 Aug 2012 02:41:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id A7AE621F86F4 for ; Mon, 20 Aug 2012 02:41:50 -0700 (PDT) Received: from mail155-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 09:41:47 +0000 Received: from mail155-va3 (localhost [127.0.0.1]) by mail155-va3-R.bigfish.com (Postfix) with ESMTP id EE79C200CE; Mon, 20 Aug 2012 09:41:46 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT009.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -34 X-BigFish: PS-34(zz9371I542M1432I1418Ia65Rzz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail155-va3 (localhost.localdomain [127.0.0.1]) by mail155-va3 (MessageSwitch) id 1345455704768144_24943; Mon, 20 Aug 2012 09:41:44 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.235]) by mail155-va3.bigfish.com (Postfix) with ESMTP id B7D6B420294; Mon, 20 Aug 2012 09:41:44 +0000 (UTC) Received: from DB3PRD0702HT009.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 09:41:44 +0000 Received: from SN2PRD0610HT001.namprd06.prod.outlook.com (157.56.234.133) by pod51017.outlook.com (10.3.4.174) with Microsoft SMTP Server (TLS) id 14.15.108.4; Mon, 20 Aug 2012 09:41:38 +0000 Message-ID: <00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , "Bert Wijnen (IETF)" , netconf References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> Date: Mon, 20 Aug 2012 10:26:13 +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.234.133] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 09:41:51 -0000 ---- Original Message ----- From: "Ladislav Lhotka" To: "Bert Wijnen (IETF)" ; "netconf" Sent: Friday, August 17, 2012 10:04 AM > > I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. > > So I propose the following fourth item for the charter: > > 4. The WG will investigate the relationship and interactions between configurations and > operational state data, propose their appropriate representation and semantics, and > devise methods for effective data modeling of both configurations and operational state data. > It is expected that this work will be carried out in a close sooperation with the NETMOD WG. Trouble is, I think that the distinction between operational state and configuration data is an artificial one, that is that the Netconf/MOD WGs have adopted a definition that allows an object to be classified as one or the other but that the distinction is not then a helpful one when it comes to operating networks. Whilst focussing on core data models, then this issue hardly arises, the objects of interest are mostly configuration; get more sophisticated and I think that we open up a can of worms that we are unlikely to resolve any better than we have to date. Tom Petch > Lada > > "Bert Wijnen (IETF)" writes: > > > Based on the comments and feedback and the positions > > expressed on the mailing list, it is clear that after all > > we did NOT have consensus on the new WG charter. > > > > Without further ado, this is another proposed WG charter. > > It focuses on the things that we do seme to have agreement on. > > > > Pls comment and/or express your support or objections > > no later than August 31, 2012. > > > > OK, new chapter text (omitting the description of what we have > > achieved sofar): > > > > In the current phase of the incremental development of NETCONF the > > workgroup will focus on following items: > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > This means that RFC5593 needs to be updated. > > > > 2. Based on the implementation, deployment experience and interoperability > > testing, the WG will document the status of NETCONF in a report. > > Based on this, the WG may decide to make some clarifications to > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > the WG will write a document that makes those 2 protocols > > (RFC4743 and RFC4744) HISTORIC. > > > > Goals and Milestones: > > done - Send with-defaults to IESG for consideration as Proposed Standard > > done - WG Last Call on rfc4741bis > > 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 NACM posted > > 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 > > Aug 2012 - submit initial WG draft for rfc5539bis > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > > Sep 2012 - WGLC for rfc5539bis > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > > to IESG for publication as Informational RFC. > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG > > > > Bert and Mehmet > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Mon Aug 20 03:14:05 2012 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 580F321F8717 for ; Mon, 20 Aug 2012 03:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtLaN-Fx2UNR for ; Mon, 20 Aug 2012 03:14:05 -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 C8E3221F8710 for ; Mon, 20 Aug 2012 03:14:04 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7841E1200AEC; Mon, 20 Aug 2012 12:14:02 +0200 (CEST) Date: Mon, 20 Aug 2012 12:14:02 +0200 (CEST) Message-Id: <20120820.121402.690772910019271220.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> References: <502D7052.2070302@bwijnen.net> <00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 10:14:05 -0000 Hi, t.petch wrote: > Trouble is, I think that the distinction between operational state and > configuration data is an artificial one, that is that the Netconf/MOD > WGs have adopted a definition that allows an object to be classified as > one or the other but that the distinction is not then a helpful one when > it comes to operating networks. Actually, we have no definition of "operational state" in 6241 or 6020. 6241 mentions the term, but 6020 does not. And this is the problem - how to identify what is the operational state (the schema), how to view the current operational state ("") and how to edit the (writable subset of the) operational state. > Whilst focussing on core data models, then this issue hardly arises, the > objects of interest are mostly configuration; get more sophisticated and > I think that we open up a can of worms that we are unlikely to resolve > any better than we have to date. Maybe, but I hope not :) /martin From lhotka@nic.cz Mon Aug 20 03:15:12 2012 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 DD15B21F8718 for ; Mon, 20 Aug 2012 03:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWKP88gUPw2D for ; Mon, 20 Aug 2012 03:15:12 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3B21F8717 for ; Mon, 20 Aug 2012 03:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 5D3D254035B; Mon, 20 Aug 2012 12:15:10 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFUmJPsy9X6T; Mon, 20 Aug 2012 12:15:05 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AADA7540239; Mon, 20 Aug 2012 12:15:03 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , "Bert Wijnen \(IETF\)" , netconf In-Reply-To: <00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Mon, 20 Aug 2012 12:15:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 10:15:13 -0000 "t.petch" writes: > > Trouble is, I think that the distinction between operational state and > configuration data is an artificial one, that is that the Netconf/MOD > WGs have adopted a definition that allows an object to be classified as > one or the other but that the distinction is not then a helpful one when > it comes to operating networks. I agree, therefore the definitions of operational state and configuration data should be clarified. > > Whilst focussing on core data models, then this issue hardly arises, the > objects of interest are mostly configuration; get more sophisticated and > I think that we open up a can of worms that we are unlikely to resolve > any better than we have to date. It is clear that even the existing core modules need some more state data to be really useful. For example, the "ietf-ip" module doesn't offer any means for obtaining auto-configured adresses that are in operational use on an interface. Yes, it can (and will) get tricky, but I think we should at least try to address this issue. Lada > > Tom Petch > >> Lada >> >> "Bert Wijnen (IETF)" writes: >> >> > Based on the comments and feedback and the positions >> > expressed on the mailing list, it is clear that after all >> > we did NOT have consensus on the new WG charter. >> > >> > Without further ado, this is another proposed WG charter. >> > It focuses on the things that we do seme to have agreement on. >> > >> > Pls comment and/or express your support or objections >> > no later than August 31, 2012. >> > >> > OK, new chapter text (omitting the description of what we have >> > achieved sofar): >> > >> > In the current phase of the incremental development of NETCONF > the >> > workgroup will focus on following items: >> > >> > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >> > This means that RFC5593 needs to be updated. >> > >> > 2. Based on the implementation, deployment experience and > interoperability >> > testing, the WG will document the status of NETCONF in a > report. >> > Based on this, the WG may decide to make some clarifications > to >> > RFC6241 and RFC6242 (then also fixing any reported errata). >> > >> > 3. Since Netconf over BEEP and over SOAP seem not being deployed >> > the WG will write a document that makes those 2 protocols >> > (RFC4743 and RFC4744) HISTORIC. >> > >> > Goals and Milestones: >> > done - Send with-defaults to IESG for consideration as > Proposed Standard >> > done - WG Last Call on rfc4741bis >> > 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 NACM posted >> > 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 >> > Aug 2012 - submit initial WG draft for rfc5539bis >> > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. >> > Sep 2012 - WGLC for rfc5539bis >> > Sep 2012 - WGLC for RFC4743 and 4743 to historic >> > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as > Proposed Standard >> > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 > historic >> > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 > and 6242 >> > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience >> > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment > experience >> > Feb 2013 - submit RFC6241/6242 implementation/deployment > experience doc >> > to IESG for publication as Informational RFC. >> > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG > or close WG >> > >> > Bert and Mehmet >> > _______________________________________________ >> > Netconf mailing list >> > Netconf@ietf.org >> > https://www.ietf.org/mailman/listinfo/netconf >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From kwatsen@juniper.net Mon Aug 20 08:40:13 2012 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 693E421F866E for ; Mon, 20 Aug 2012 08:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H35lQbIRM5BE for ; Mon, 20 Aug 2012 08:40:13 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E070221F8618 for ; Mon, 20 Aug 2012 08:40:12 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUDJaWmWUbE7JAgmpBpmy46bQvRcinY3y@postini.com; Mon, 20 Aug 2012 08:40:12 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 20 Aug 2012 08:40:04 -0700 From: Kent Watsen To: Martin Bjorklund , "ietfc@btconnect.com" Date: Mon, 20 Aug 2012 08:40:10 -0700 Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: Ac1+6hFAy8iWcjWISN2W1lJr5iN17g== Message-ID: In-Reply-To: <20120820.121402.690772910019271220.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 15:40:13 -0000 On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: >And how to edit the (writable subset of the) operational state. > Is any operational-state writable? How would it be different than ephemeral configuration, such as what the SDN folks want? Thanks, Kent From andy@yumaworks.com Mon Aug 20 09:17:49 2012 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 BB5E621F8489 for ; Mon, 20 Aug 2012 09:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQd2fFhvxzUq for ; Mon, 20 Aug 2012 09:17:49 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3349E21F847F for ; Mon, 20 Aug 2012 09:17:49 -0700 (PDT) Received: by qadz3 with SMTP id z3so2976453qad.10 for ; Mon, 20 Aug 2012 09:17:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=oRMJamFaJiZXZx/ZqQ9z/tr268KUUyl77N8s6vBEYak=; b=KwgL9+IgYfcW4qlad22mfGLX9N7+8lrm9PVUdJzDgkpPA7CPEzHkDoEHreiC8lnCZO vTEJjLfAh8d5jlu1EENPLPYm8s8fpTEdzsxrMcOkkr9W/MDYhSn9Mwca61WUENIMVCXr YDJjMN/vGKDAogrQXLt9ht+e1CA7FiLQxy6Dlk3kp6Pv9kOztqCEL8Fr0xFeQH8p4a7F ApezB7E82hNrlIqbSWntCEkt1x6d200N9MQy4IDbxjsKiMbjGxCH3DWAsJZUxUyw3984 MmwWUBZ9pUcvuQoN69jzIe2y8d2i8tG92lrbrzUAABQB7C5LxrAyvJ6Rp7EY4LR/6pzd OZmg== MIME-Version: 1.0 Received: by 10.229.135.76 with SMTP id m12mr13326944qct.68.1345479467385; Mon, 20 Aug 2012 09:17:47 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 20 Aug 2012 09:17:47 -0700 (PDT) In-Reply-To: References: <20120820.121402.690772910019271220.mbj@tail-f.com> Date: Mon, 20 Aug 2012 09:17:47 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkmkkv25XQPvuHLoqQlTt/WDOu4fpFFKNcaxAjGkT2LelGE/W4mtv+hTTRU4y7JmRVXkcPr Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 16:17:49 -0000 On Mon, Aug 20, 2012 at 8:40 AM, Kent Watsen wrote: > > > On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: > >>And how to edit the (writable subset of the) operational state. >> > > > Is any operational-state writable? How would it be different than > ephemeral configuration, such as what the SDN folks want? > I brought this issue during RFC 4741 discussions. I wanted a 3rd classification for this 'middle ground', I called 'tconfig'. But we ended up with a boolean + . I brought it up again in 2009: http://www.ietf.org/mail-archive/web/netmod/current/msg03812.html The SDN discussions seem to include access-control, rollback and roll-forward, and other CM-like tasks for which NETCONF already has standard solutions. I don't know if "SDN content" should be defined in YANG -- that is a different part of the problem space. > Thanks, > Kent Andy From ietfc@btconnect.com Mon Aug 20 09:23:29 2012 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 66D2B21F86D8 for ; Mon, 20 Aug 2012 09:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.908 X-Spam-Level: X-Spam-Status: No, score=-4.908 tagged_above=-999 required=5 tests=[AWL=1.091, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPO7L79a8JVz for ; Mon, 20 Aug 2012 09:23:28 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id BE56721F86AD for ; Mon, 20 Aug 2012 09:23:28 -0700 (PDT) Received: from mail114-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 16:23:28 +0000 Received: from mail114-tx2 (localhost [127.0.0.1]) by mail114-tx2-R.bigfish.com (Postfix) with ESMTP id 0A90B2A0198; Mon, 20 Aug 2012 16:23:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zz98dI9371I542M1432I1418Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail114-tx2 (localhost.localdomain [127.0.0.1]) by mail114-tx2 (MessageSwitch) id 1345479806754084_10194; Mon, 20 Aug 2012 16:23:26 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.239]) by mail114-tx2.bigfish.com (Postfix) with ESMTP id B53FCC0054; Mon, 20 Aug 2012 16:23:26 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 16:23:26 +0000 Received: from SN2PRD0610HT004.namprd06.prod.outlook.com (157.56.234.133) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.108.4; Mon, 20 Aug 2012 16:23:20 +0000 Message-ID: <01be01cd7eef$753c9300$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <502D7052.2070302@bwijnen.net><00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> <20120820.121402.690772910019271220.mbj@tail-f.com> Date: Mon, 20 Aug 2012 17:18:12 +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.234.133] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 16:23:29 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Monday, August 20, 2012 11:14 AM > Hi, > > t.petch wrote: > > Trouble is, I think that the distinction between operational state and > > configuration data is an artificial one, that is that the Netconf/MOD > > WGs have adopted a definition that allows an object to be classified as > > one or the other but that the distinction is not then a helpful one when > > it comes to operating networks. > > Actually, we have no definition of "operational state" in 6241 or > 6020. 6241 mentions the term, but 6020 does not. And this is the > problem - how to identify what is the operational state (the schema), > how to view the current operational state ("") and > how to edit the (writable subset of the) operational state. That surprises me. RFC6020 has a lot to say about configuration and state data, implying that they are the two alternatives, the former writable, that latter mostly not. Unless, of course, you are differentiating state and operational state, in which case I do not know what the latter is. Lada's item 4 also suggests to me that there are just two already defined alternatives. If not, then item 4 does not seem to make sense to me. Tom Petch > > > Whilst focussing on core data models, then this issue hardly arises, the > > objects of interest are mostly configuration; get more sophisticated and > > I think that we open up a can of worms that we are unlikely to resolve > > any better than we have to date. > > Maybe, but I hope not :) > > > /martin > From ietfc@btconnect.com Mon Aug 20 09:34:20 2012 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 85F7221F861A for ; Mon, 20 Aug 2012 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RUI5l4RBJ-A for ; Mon, 20 Aug 2012 09:34:20 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id B4C9C21F8526 for ; Mon, 20 Aug 2012 09:34:19 -0700 (PDT) Received: from mail8-co1-R.bigfish.com (10.243.78.227) by CO1EHSOBE008.bigfish.com (10.243.66.71) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 16:34:18 +0000 Received: from mail8-co1 (localhost [127.0.0.1]) by mail8-co1-R.bigfish.com (Postfix) with ESMTP id D4783B40122; Mon, 20 Aug 2012 16:34:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: PS-25(zzbb2dI98dI9371I542M4015Izz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail8-co1 (localhost.localdomain [127.0.0.1]) by mail8-co1 (MessageSwitch) id 1345480456694143_18518; Mon, 20 Aug 2012 16:34:16 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.250]) by mail8-co1.bigfish.com (Postfix) with ESMTP id A711B88004C; Mon, 20 Aug 2012 16:34:16 +0000 (UTC) Received: from DB3PRD0702HT001.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 16:34:16 +0000 Received: from SN2PRD0610HT005.namprd06.prod.outlook.com (157.56.234.133) by pod51017.outlook.com (10.3.4.141) with Microsoft SMTP Server (TLS) id 14.15.108.4; Mon, 20 Aug 2012 16:34:14 +0000 Message-ID: <01d001cd7ef0$faf4a400$4001a8c0@gateway.2wire.net> From: t.petch To: Kent Watsen , Martin Bjorklund References: Date: Mon, 20 Aug 2012 17:29:23 +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.234.133] X-FOPE-CRA-Verdict: 157.55.224.141$juniper.net%12218%2%btconnect.com%True%True%0$ X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 16:34:20 -0000 ----- Original Message ----- From: "Kent Watsen" To: "Martin Bjorklund" ; Cc: Sent: Monday, August 20, 2012 4:40 PM On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: >And how to edit the (writable subset of the) operational state. > Is any operational-state writable? Previous list discussions suggested not, to me, but RFC6020 says " state data: The additional data on a system that is not configuration data such as read-only status information and collected statistics [RFC4741]." which could be parsed as "read-only status information" "collected statistics" ... or "read-only status information" " read-only collected statistics" "read-only ...". I assumed the latter, as I did that state and operational state are equivalent. The routing(forwarding) table is an interesting case to model, with entries put in explicitly, statically; entries put in implicitly from the configuration of an ip address on an interface; entries learnt from a routing protocol; entries calculated as a result of link state information from a protocol; and all that then subjected to a configurable filtering algorithm which may or may not yield one or more best routes. Operationally, I would hope to see the combined routing(forwarding) table that the box is using, regardless of its classification by configuration, state or whatever. Tom Petch How would it be different than ephemeral configuration, such as what the SDN folks want? Thanks, Kent From lhotka@nic.cz Mon Aug 20 09:45:17 2012 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 BFE6921F86B4 for ; Mon, 20 Aug 2012 09:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.672 X-Spam-Level: X-Spam-Status: No, score=-1.672 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cMEGJMsVW7T for ; Mon, 20 Aug 2012 09:45:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6BA21F86B3 for ; Mon, 20 Aug 2012 09:45:17 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D535613F64F; Mon, 20 Aug 2012 18:45:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1345481115; bh=JwTCaVCdwDO4LMtTNkjcxyssCZGq7MZRVmSb7IwBiFM=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Y0q0REPi0PQt5/lqqF1iYA1gTq+3kgzYE3G1mkngLHGvDJw8/NiKYdSljtdgq8WLk hIKuCSFvNdiSyJCRugGccM2T46mo2Sr0L7gnr86Fhgf9Ly6T2Hu/otZQz4c7cufY66 SkCpwxQR9oqmwPA/8uvqhUDoUr9iftUs2MhNQorg= Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) Content-Type: text/plain; charset=iso-8859-1 From: Ladislav Lhotka X-Priority: 3 In-Reply-To: <01be01cd7eef$753c9300$4001a8c0@gateway.2wire.net> Date: Mon, 20 Aug 2012 18:45:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <93EEE5F9-680F-4083-A534-0F8CE0E9EB25@nic.cz> References: <502D7052.2070302@bwijnen.net><00a201cd7eb7$572e9d00$4001a8c0@gateway.2wire.net> <20120820.121402.690772910019271220.mbj@tail-f.com> <01be01cd7eef$753c9300$4001a8c0@gateway.2wire.net> To: t.petch X-Mailer: Apple Mail (2.1485) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 16:45:17 -0000 On Aug 20, 2012, at 6:18 PM, t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; ; > Sent: Monday, August 20, 2012 11:14 AM >> Hi, >>=20 >> t.petch wrote: >>> Trouble is, I think that the distinction between operational state > and >>> configuration data is an artificial one, that is that the > Netconf/MOD >>> WGs have adopted a definition that allows an object to be classified > as >>> one or the other but that the distinction is not then a helpful one > when >>> it comes to operating networks. >>=20 >> Actually, we have no definition of "operational state" in 6241 or >> 6020. 6241 mentions the term, but 6020 does not. And this is the >> problem - how to identify what is the operational state (the schema), >> how to view the current operational state ("") and >> how to edit the (writable subset of the) operational state. >=20 > That surprises me. RFC6020 has a lot to say about configuration and > state data, implying that they are the two alternatives, the former > writable, that latter mostly not. Unless, of course, you are > differentiating > state and operational state, in which case I do not know what the > latter is. >=20 > Lada's item 4 also suggests to me that there are just two already > defined > alternatives. If not, then item 4 does not seem to make sense to me. My take is that what really matters is the full set of operational state = data because it is what governs the device behaviour. NETCONF then = provides an interface for changing (parts of) this operational state. As I understand it, "writable operational state", "ephemeral config" = etc. just mean other similar (and usually simpler) interfaces. Lada >=20 > Tom Petch >=20 >>=20 >>> Whilst focussing on core data models, then this issue hardly arises, > the >>> objects of interest are mostly configuration; get more sophisticated > and >>> I think that we open up a can of worms that we are unlikely to > resolve >>> any better than we have to date. >>=20 >> Maybe, but I hope not :) >>=20 >>=20 >> /martin >>=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Mon Aug 20 12:37:05 2012 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 90D4421F8575 for ; Mon, 20 Aug 2012 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49AZSFdZoNlV for ; Mon, 20 Aug 2012 12:37:05 -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 0F0BE21F852C for ; Mon, 20 Aug 2012 12:37:05 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DCEDA1200A6E; Mon, 20 Aug 2012 21:37:02 +0200 (CEST) Date: Mon, 20 Aug 2012 21:37:02 +0200 (CEST) Message-Id: <20120820.213702.226942467.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20120820.121402.690772910019271220.mbj@tail-f.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 19:37:05 -0000 Kent Watsen wrote: > > > On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: > > >And how to edit the (writable subset of the) operational state. > > > > > Is any operational-state writable? How would it be different than > ephemeral configuration, such as what the SDN folks want? I think it's the same thing. /martin From Tina.Tsou.Zouting@huawei.com Mon Aug 20 12:53:08 2012 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 218D221F856C for ; Mon, 20 Aug 2012 12:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.064 X-Spam-Level: X-Spam-Status: No, score=-6.064 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2y0+-AAMm32 for ; Mon, 20 Aug 2012 12:53:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6DE21F8496 for ; Mon, 20 Aug 2012 12:53:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfwdlp01-ep.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath) with ESMTP id AJF14645; Mon, 20 Aug 2012 11:53:06 -0800 (PST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 20 Aug 2012 12:48:11 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.159]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 20 Aug 2012 12:48:10 -0700 From: Tina TSOU To: Andy Bierman Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: AQHNfrySbAabEZSeukSaLN+WUF746ZdjTAkAgAAKgoD//8VwpA== Date: Mon, 20 Aug 2012 19:48:10 +0000 Message-ID: <7EFDF049-C64D-4D90-9479-86EB336A5E89@huawei.com> References: <20120820.121402.690772910019271220.mbj@tail-f.com> , In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 19:53:08 -0000 Tina On Aug 20, 2012, at 9:18 AM, "Andy Bierman" wrote: > On Mon, Aug 20, 2012 at 8:40 AM, Kent Watsen wrote: >>=20 >>=20 >> On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: >>=20 >>> And how to edit the (writable subset of the) operational state. >>>=20 >>=20 >>=20 >> Is any operational-state writable? How would it be different than >> ephemeral configuration, such as what the SDN folks want? >>=20 >=20 > I brought this issue during RFC 4741 discussions. > I wanted a 3rd classification for this 'middle ground', I called 'tconfig= '. > But we ended up with a boolean + . >=20 > I brought it up again in 2009: > http://www.ietf.org/mail-archive/web/netmod/current/msg03812.html >=20 > The SDN discussions seem to include access-control, rollback and > roll-forward, and other CM-like tasks for which NETCONF already > has standard solutions. I don't know if "SDN content" should be > defined in YANG -- that is a different part of the problem space. [Tina]=20 I think it should go to netmod WG. It is about data model. >=20 >> Thanks, >> Kent >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Mon Aug 20 15:23:43 2012 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 BA67711E8097 for ; Mon, 20 Aug 2012 15:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5Na8EzeMH3B for ; Mon, 20 Aug 2012 15:23:43 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8845F11E8098 for ; Mon, 20 Aug 2012 15:23:40 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUDK47BB4p+II/tIphbJkdwhVvNZIBr+U@postini.com; Mon, 20 Aug 2012 15:23:43 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Aug 2012 15:23:24 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7KMN8h39156; Mon, 20 Aug 2012 15:23:08 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7KMLpxi031569; Mon, 20 Aug 2012 18:22:11 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208202222.q7KMLpxi031569@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Mon, 20 Aug 2012 18:21:50 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 22:23:43 -0000 "operational state" is what the current operational state is, not what you asked it to be. The real state will be an outcome driven by configuration data (the existing NETCONF datastores), external sources (BGP peers, link state databases, RADIUS servers, DHCP replies, etc), and some local logic (protocol engines, dhclient.conf, etc). You should always be able to ask "what did I tell you to set it to" distinctly from "what is the current operational value". Thanks, Phil Kent Watsen writes: > > >On 8/20/12 6:14 AM, "Martin Bjorklund" wrote: > >>And how to edit the (writable subset of the) operational state. >> > > >Is any operational-state writable? How would it be different than >ephemeral configuration, such as what the SDN folks want? > >Thanks, >Kent > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From kwatsen@juniper.net Mon Aug 20 16:19:15 2012 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 E1CAA21F843C for ; Mon, 20 Aug 2012 16:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fAYx5Pr0rQw for ; Mon, 20 Aug 2012 16:19:15 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1E21F843A for ; Mon, 20 Aug 2012 16:19:15 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUDLF8X1eZYyVqASNyxC1Gf4cIS2aEcdr@postini.com; Mon, 20 Aug 2012 16:19:15 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Mon, 20 Aug 2012 16:18:39 -0700 From: Kent Watsen To: Phil Shafer Date: Mon, 20 Aug 2012 16:18:37 -0700 Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: Ac1/KiFpXomMMYSKSC2q2ccqc7c6PA== Message-ID: In-Reply-To: <201208202222.q7KMLpxi031569@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 20 Aug 2012 23:19:16 -0000 On 8/20/12 6:21 PM, "Phil Shafer" wrote: >"operational state" is what the current operational state is, not >what you asked it to be. The real state will be an outcome driven >by configuration data (the existing NETCONF datastores), external >sources (BGP peers, link state databases, RADIUS servers, DHCP >replies, etc), and some local logic (protocol engines, dhclient.conf, >etc). You should always be able to ask "what did I tell you to set it >to" distinctly from "what is the current operational value". > This matches my view as well. To me, ephemeral configuration is *config* that either goes to a special datastore or to the "running" datastore with an XML-attribute indicating that it's ephemeral. Likewise, we either on a special datastore or with a flag to the running datastore indicating that ephemeral config should also be returned, with the nodes annotated with a XML-attribute to distinguish them from standard config. Comparing this to Andy's 3rd-state (tconfig), I guess this puts me in the "boolean boat" ;) Regarding moving this discussion to the NETMOD list so that the data modeling aspects can be sorted, I think that it's the *conceptual* model that needs to be worked out first and thus suggest keeping the discussion here, if we choose to discuss it all, since it didn't come up as a charter item before. Of course, all this assumes that a XML-based protocol is performant enough for the use-cases that we'd be trying to enable... Thanks, Kent From alex@cisco.com Mon Aug 20 17:43:19 2012 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 89E5011E809A for ; Mon, 20 Aug 2012 17:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1klYODdsaPr for ; Mon, 20 Aug 2012 17:43:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BCA2711E8097 for ; Mon, 20 Aug 2012 17:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alex@cisco.com; l=3357; q=dns/txt; s=iport; t=1345509799; x=1346719399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oX43WHyNnkdOSH0pQ+XJZenkqF9bCtd32Q3Zfq0e1HM=; b=gNOivIkZoJqUZir6S7Wxz0JXlJ9nyQXOs9Ur+F7wD4H3j7/2DCVoXH8W UpJk9FyEBHd3/+IEs3Em9zME3PiD16DQFhBsjKIji4PZwJ9l5TpcZZsT7 sER631TqTy64OFMLnlwAnFrt+IfAEHnpnFMQ+wmAxT35QE5Ea2ovwEY5K g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGjZMlCtJV2c/2dsb2JhbABFuluBB4IgAQEBBAEBAQ8BJzQLDAQCAQgOAwQBAQsUCQcnCxQJCAIEAQ0FCBqHawuZJqAzBIsLhjxgA6N8gWaCYQ X-IronPort-AV: E=Sophos;i="4.77,799,1336348800"; d="scan'208";a="113591241" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2012 00:43:03 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7L0h2eE021367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 00:43:02 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.54]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 19:43:02 -0500 From: "Alexander Clemm (alex)" To: Kent Watsen , Phil Shafer Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: AQHNfyo6Ga0lIi6Kn0mDo8yK+L7AX5djaV4g Date: Tue, 21 Aug 2012 00:43:02 +0000 Message-ID: References: <201208202222.q7KMLpxi031569@idle.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.200.94] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19126.004 x-tm-as-result: No--43.741800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 00:43:19 -0000 I tend to agree as well. I do think there are additional distinctions. E.g. physical immutable prop= erties associated with a device, such as its equipment type or serial numbe= r - clearly not config, but the term "operational data" does not capture it= quite either. Likewise, historical records (e.g. of events). =20 At the end of the day, what is important is who "owns" the data, i.e. where= it originates from - an external app or the managed system - this is what = I think the operational / config data distinction ultimately refers to (mak= ing "operational" somewhat of a misnomer) - and whether the data is "transi= ent" or "persistent", which could be covered by the notion of different dat= a stores.=20 One aspect or distinction that could perhaps be made clearer concerns the n= otion of data stores _complementing_ each other, versus providing _alternat= ives_ to one another. The aspect of ephemeral data points to the need to p= erhaps distinguish multiple data stores, which collectively provide the "ov= erall" view of the managed system, as opposed to e.g. the notion of running= and startup and candidate which provides more alternative views of the sam= e information. The ability to make such a distinction of complementing vs = "competing" data stores is something that appears to be missing. =20 --- Alex -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Kent Watsen Sent: Monday, August 20, 2012 4:19 PM To: Phil Shafer Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFO= RE Sept 1st On 8/20/12 6:21 PM, "Phil Shafer" wrote: >"operational state" is what the current operational state is, not >what you asked it to be. The real state will be an outcome driven >by configuration data (the existing NETCONF datastores), external >sources (BGP peers, link state databases, RADIUS servers, DHCP >replies, etc), and some local logic (protocol engines, dhclient.conf, >etc). You should always be able to ask "what did I tell you to set it >to" distinctly from "what is the current operational value". > This matches my view as well. To me, ephemeral configuration is *config* that either goes to a special datastore or to the "running" datastore with an XML-attribute indicating that it's ephemeral. Likewise, we either on a special datastore or with a flag to the running datastore indicating that ephemeral config should also be returned, with the nodes annotated with a XML-attribute to distinguish them from standard config. Comparing this to Andy's 3rd-state (tconfig), I guess this puts me in the "boolean boat" ;) Regarding moving this discussion to the NETMOD list so that the data modeling aspects can be sorted, I think that it's the *conceptual* model that needs to be worked out first and thus suggest keeping the discussion here, if we choose to discuss it all, since it didn't come up as a charter item before. Of course, all this assumes that a XML-based protocol is performant enough for the use-cases that we'd be trying to enable... Thanks, Kent _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From xiangli@seguesoft.com Mon Aug 20 17:47:26 2012 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 145E921F84B5 for ; Mon, 20 Aug 2012 17:47:26 -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.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07WCA6tB7gUy for ; Mon, 20 Aug 2012 17:47:25 -0700 (PDT) Received: from m1plsmtpa01-01.prod.mesa1.secureserver.net (m1plsmtpa01-01.prod.mesa1.secureserver.net [64.202.165.173]) by ietfa.amsl.com (Postfix) with ESMTP id E846421F84B2 for ; Mon, 20 Aug 2012 17:47:24 -0700 (PDT) Received: from [192.168.2.10] ([98.212.151.151]) by m1plsmtpa01-01.prod.mesa1.secureserver.net with id pCnP1j0093GEayi01CnPvR; Mon, 20 Aug 2012 17:47:24 -0700 Message-ID: <5032DA9D.2010004@seguesoft.com> Date: Mon, 20 Aug 2012 19:47:25 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 00:47:26 -0000 On 8/17/2012 4:04 AM, Ladislav Lhotka wrote: > Hi, > > I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. > > So I propose the following fourth item for the charter: > > 4. The WG will investigate the relationship and interactions between configurations and > operational state data, propose their appropriate representation and semantics, and > devise methods for effective data modeling of both configurations and operational state data. > It is expected that this work will be carried out in a close sooperation with the NETMOD WG. I can easily understand "ephemeral config" or Andy's "transient config", but the concept of " operational state data" and "the writable subset of the operational state" are rather hard for me to grasp. --Xiang > > Lada > > "Bert Wijnen (IETF)" writes: > >> Based on the comments and feedback and the positions >> expressed on the mailing list, it is clear that after all >> we did NOT have consensus on the new WG charter. >> >> Without further ado, this is another proposed WG charter. >> It focuses on the things that we do seme to have agreement on. >> >> Pls comment and/or express your support or objections >> no later than August 31, 2012. >> >> OK, new chapter text (omitting the description of what we have >> achieved sofar): >> >> In the current phase of the incremental development of NETCONF the >> workgroup will focus on following items: >> >> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >> This means that RFC5593 needs to be updated. >> >> 2. Based on the implementation, deployment experience and interoperability >> testing, the WG will document the status of NETCONF in a report. >> Based on this, the WG may decide to make some clarifications to >> RFC6241 and RFC6242 (then also fixing any reported errata). >> >> 3. Since Netconf over BEEP and over SOAP seem not being deployed >> the WG will write a document that makes those 2 protocols >> (RFC4743 and RFC4744) HISTORIC. >> >> Goals and Milestones: >> done - Send with-defaults to IESG for consideration as Proposed Standard >> done - WG Last Call on rfc4741bis >> 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 NACM posted >> 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 >> Aug 2012 - submit initial WG draft for rfc5539bis >> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. >> Sep 2012 - WGLC for rfc5539bis >> Sep 2012 - WGLC for RFC4743 and 4743 to historic >> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard >> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic >> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 >> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience >> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >> Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc >> to IESG for publication as Informational RFC. >> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG >> >> Bert and Mehmet >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf -- --Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 Mobile: 1 (217) 472-4108 From xiangli@seguesoft.com Mon Aug 20 18:11:14 2012 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 40B0521F8525 for ; Mon, 20 Aug 2012 18:11:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRrRsO8rKeuI for ; Mon, 20 Aug 2012 18:11:09 -0700 (PDT) Received: from p3plsmtpa08-04.prod.phx3.secureserver.net (p3plsmtpa08-04.prod.phx3.secureserver.net [173.201.193.105]) by ietfa.amsl.com (Postfix) with SMTP id 7A04C21F851E for ; Mon, 20 Aug 2012 18:11:09 -0700 (PDT) Received: (qmail 24167 invoked from network); 21 Aug 2012 01:11:08 -0000 Received: from unknown (98.212.151.151) by p3plsmtpa08-04.prod.phx3.secureserver.net (173.201.193.105) with ESMTP; 21 Aug 2012 01:11:07 -0000 Message-ID: <5032E02B.2090801@seguesoft.com> Date: Mon, 20 Aug 2012 20:11:07 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Kent Watsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 01:11:14 -0000 On 8/20/2012 6:18 PM, Kent Watsen wrote: > On 8/20/12 6:21 PM, "Phil Shafer" wrote: > >> .... >> This matches my view as well. >> >> To me, ephemeral configuration is *config* that either goes to a special datastore I think Kent explained this very well. I think "ephemeral config" (or Andy's "transient config") can still be considered as 'config data'. It would be nice we can keep things simple and conceptually only maintain two set of data: (readonly) state data and (readwrte) config data. I am not sure the "ephemeral config" should go to a special datastore because doing that means the device needs to look at the "config datastore" and "transient config datastore" to get to its operational state. Is that a bad or good thing, I don't know... guess further discussion is needed. > or to the "running" datastore with an XML-attribute indicating > that it's ephemeral. That could work. But if a device does not support <:writable-running> then we have a problem. --Xiang > > Regarding moving this discussion to the NETMOD list so that the data > modeling aspects can be sorted, I think that it's the *conceptual* model > that needs to be worked out first and thus suggest keeping the discussion > here, if we choose to discuss it all, since it didn't come up as a charter > item before. Of course, all this assumes that a XML-based protocol is > performant enough for the use-cases that we'd be trying to enable... > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- --Xiang Li From andy@yumaworks.com Mon Aug 20 18:40:46 2012 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 C2FC221F8596 for ; Mon, 20 Aug 2012 18:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YLtSjzRw5BO for ; Mon, 20 Aug 2012 18:40:46 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B609B21F85B4 for ; Mon, 20 Aug 2012 18:40:45 -0700 (PDT) Received: by qadb17 with SMTP id b17so3256589qad.10 for ; Mon, 20 Aug 2012 18:40:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=02GANaxXAJmLdDav69VzEy1ajz7w4KGc5BtmH6BQlYI=; b=JE00hxbGKr5c5BvzaaD2FAjH/tuUxJfR3UjKTWWOKCAUNCyJFB894FYJ/zlWN7VodG ULOV31mU2LbFsODXQzApNDvuHvvmUnIurtrJftI/YOIThSww+pacVJubZIFLNIw4MO/M SVrL/fQWxZpSXe2EWWXGmTP9qbUiXy+0XgfssbC8H8T8OktB/v5IAhvlL1RVjN8uxVHN 8Pq33DnKU66TVRyg38ntnWVVnFSRtTjF2/jd2xoYpYutWDtZTE5GQpGGd47GKB3jGZVj xSZeEpV5Z/3Eqvh/AUj9geF7hOvFrzy4e3TAs3acVsUQUFVMEg+C7zKzmgch8AumuHR6 OJ3g== MIME-Version: 1.0 Received: by 10.224.59.212 with SMTP id m20mr1542017qah.14.1345513245030; Mon, 20 Aug 2012 18:40:45 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Mon, 20 Aug 2012 18:40:44 -0700 (PDT) In-Reply-To: <5032DA9D.2010004@seguesoft.com> References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <5032DA9D.2010004@seguesoft.com> Date: Mon, 20 Aug 2012 18:40:44 -0700 Message-ID: From: Andy Bierman To: Xiang Li Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl+JWYJWOdwajGwiWFiLtnA9dVMdvoVGdefqaomjs7wVSGKRRyVofrGhKltfG4OXuYt+TBG Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 01:40:46 -0000 On Mon, Aug 20, 2012 at 5:47 PM, Xiang Li wrote: > > On 8/17/2012 4:04 AM, Ladislav Lhotka wrote: >> >> Hi, >> >> I had the impression that there was a reasonable agreement that work on >> operational state data is needed. Although this problem lies somewhere >> between NETCONF and NETMOD, I think the NETCONF WG is now in a better >> position to start this work because apparently NETMOD WG will have to >> continue the work on the core data models for some time. >> >> So I propose the following fourth item for the charter: >> >> 4. The WG will investigate the relationship and interactions between >> configurations and >> operational state data, propose their appropriate representation and >> semantics, and >> devise methods for effective data modeling of both configurations and >> operational state data. >> It is expected that this work will be carried out in a close >> sooperation with the NETMOD WG. > > > I can easily understand "ephemeral config" or Andy's "transient config", but > the concept of " operational state data" and "the writable subset of the > operational state" are rather hard for me to grasp. > I think would not return 'tconfig' like I said in 2009. That was wrong. Martin's would return tconfig and would allow it to be changed. It is a fuzzy boundary. A config=true table to pre-load an ARP cache with static entries seems clearly to be config. But what if the entries are not stored across a reboot but rather generated on the fly (e.g., launch VM)? This is the middle ground -- client injecting stuff into the control plane. This seems to be what SDN needs, and would address that. It is not intended to write server state or statistics. > > --Xiang > Andy >> >> Lada >> >> "Bert Wijnen (IETF)" writes: >> >>> Based on the comments and feedback and the positions >>> expressed on the mailing list, it is clear that after all >>> we did NOT have consensus on the new WG charter. >>> >>> Without further ado, this is another proposed WG charter. >>> It focuses on the things that we do seme to have agreement on. >>> >>> Pls comment and/or express your support or objections >>> no later than August 31, 2012. >>> >>> OK, new chapter text (omitting the description of what we have >>> achieved sofar): >>> >>> In the current phase of the incremental development of NETCONF the >>> workgroup will focus on following items: >>> >>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>> This means that RFC5593 needs to be updated. >>> >>> 2. Based on the implementation, deployment experience and >>> interoperability >>> testing, the WG will document the status of NETCONF in a report. >>> Based on this, the WG may decide to make some clarifications to >>> RFC6241 and RFC6242 (then also fixing any reported errata). >>> >>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>> the WG will write a document that makes those 2 protocols >>> (RFC4743 and RFC4744) HISTORIC. >>> >>> Goals and Milestones: >>> done - Send with-defaults to IESG for consideration as Proposed >>> Standard >>> done - WG Last Call on rfc4741bis >>> 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 NACM posted >>> 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 >>> Aug 2012 - submit initial WG draft for rfc5539bis >>> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >>> historic. >>> Sep 2012 - WGLC for rfc5539bis >>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed >>> Standard >>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 >>> historic >>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and >>> 6242 >>> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment >>> experience >>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >>> Feb 2013 - submit RFC6241/6242 implementation/deployment experience >>> doc >>> to IESG for publication as Informational RFC. >>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or >>> close WG >>> >>> Bert and Mehmet >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf > > > -- > --Xiang Li > Web: www.seguesoft.com > Voice: 1 (872) 216-2610 > Mobile: 1 (217) 472-4108 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From bertietf@bwijnen.net Tue Aug 21 00:46:37 2012 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 444C921F8648 for ; Tue, 21 Aug 2012 00:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.08 X-Spam-Level: X-Spam-Status: No, score=-102.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAl0qOS0azH5 for ; Tue, 21 Aug 2012 00:46:36 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id EDB6021F862A for ; Tue, 21 Aug 2012 00:46:33 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T3jAU-0001cL-Nm for netconf@ietf.org; Tue, 21 Aug 2012 09:46:32 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T3jAU-0008FW-Gl for netconf@ietf.org; Tue, 21 Aug 2012 09:46:30 +0200 Message-ID: <50333CD6.1040803@bwijnen.net> Date: Tue, 21 Aug 2012 09:46:30 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <5032DA9D.2010004@seguesoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120821 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4bd182215b0751e1fd123cdd4817e563d Subject: [Netconf] Operational (or other non config) state data [Was: Re: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st] 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 Aug 2012 07:46:37 -0000 PLEASE.... pay attention to the SUBJECT line. We (WG chairs) are trying to get AGREEMENT of a pretty simple, short, straight forward WG Charter to let us finalize some work in the coming 3-6 months. It was clear from earlier charter discussion (WGLC etc) that the WG does NOT AGREE on what exactly to do for - REST API or YANG API - operational (or other) non-config data. We (WG Chairs) are FINE if you discuss these matters (with appropriate SUBJECT lines PLEASE) on teh WG list. It may result in good individual I-Ds (for next ietf or the one after that) so that we can THEN consider to take any of these work items as WG work items. For NOW, PLEASE do let us know if you support (or object to) the simple short/concise proposed new WG charter. If so, we can quickly get it approved by the IESG, and I think we can then also quickly (i.e. within 3-6 months) complete that work. In parallel, we/you can discuss these other matters, but PLEASE PLEASE use appropriate SUBJECT lines, so that it is easier to wade thought the relevant postings for a specific subject issue. Bert On 8/21/12 3:40 AM, Andy Bierman wrote: > On Mon, Aug 20, 2012 at 5:47 PM, Xiang Li wrote: >> >> On 8/17/2012 4:04 AM, Ladislav Lhotka wrote: >>> >>> Hi, >>> >>> I had the impression that there was a reasonable agreement that work on >>> operational state data is needed. Although this problem lies somewhere >>> between NETCONF and NETMOD, I think the NETCONF WG is now in a better >>> position to start this work because apparently NETMOD WG will have to >>> continue the work on the core data models for some time. >>> >>> So I propose the following fourth item for the charter: >>> >>> 4. The WG will investigate the relationship and interactions between >>> configurations and >>> operational state data, propose their appropriate representation and >>> semantics, and >>> devise methods for effective data modeling of both configurations and >>> operational state data. >>> It is expected that this work will be carried out in a close >>> sooperation with the NETMOD WG. >> >> >> I can easily understand "ephemeral config" or Andy's "transient config", but >> the concept of " operational state data" and "the writable subset of the >> operational state" are rather hard for me to grasp. >> > > I think would not return 'tconfig' like I said in 2009. > That was wrong. Martin's would return tconfig > and would allow it to be changed. > > It is a fuzzy boundary. > A config=true table to pre-load an ARP cache with static entries > seems clearly to be config. But what if the entries are not stored > across a reboot but rather generated on the fly (e.g., launch VM)? > This is the middle ground -- client injecting stuff into the control plane. > This seems to be what SDN needs, and would > address that. It is not intended to write server state or statistics. > > >> >> --Xiang >> > > Andy > >>> >>> Lada >>> >>> "Bert Wijnen (IETF)" writes: >>> >>>> Based on the comments and feedback and the positions >>>> expressed on the mailing list, it is clear that after all >>>> we did NOT have consensus on the new WG charter. >>>> >>>> Without further ado, this is another proposed WG charter. >>>> It focuses on the things that we do seme to have agreement on. >>>> >>>> Pls comment and/or express your support or objections >>>> no later than August 31, 2012. >>>> >>>> OK, new chapter text (omitting the description of what we have >>>> achieved sofar): >>>> >>>> In the current phase of the incremental development of NETCONF the >>>> workgroup will focus on following items: >>>> >>>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>>> This means that RFC5593 needs to be updated. >>>> >>>> 2. Based on the implementation, deployment experience and >>>> interoperability >>>> testing, the WG will document the status of NETCONF in a report. >>>> Based on this, the WG may decide to make some clarifications to >>>> RFC6241 and RFC6242 (then also fixing any reported errata). >>>> >>>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>>> the WG will write a document that makes those 2 protocols >>>> (RFC4743 and RFC4744) HISTORIC. >>>> >>>> Goals and Milestones: >>>> done - Send with-defaults to IESG for consideration as Proposed >>>> Standard >>>> done - WG Last Call on rfc4741bis >>>> 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 NACM posted >>>> 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 >>>> Aug 2012 - submit initial WG draft for rfc5539bis >>>> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >>>> historic. >>>> Sep 2012 - WGLC for rfc5539bis >>>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed >>>> Standard >>>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 >>>> historic >>>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and >>>> 6242 >>>> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment >>>> experience >>>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >>>> Feb 2013 - submit RFC6241/6242 implementation/deployment experience >>>> doc >>>> to IESG for publication as Informational RFC. >>>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or >>>> close WG >>>> >>>> Bert and Mehmet >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >> >> >> -- >> --Xiang Li >> Web: www.seguesoft.com >> Voice: 1 (872) 216-2610 >> Mobile: 1 (217) 472-4108 >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From ietfc@btconnect.com Tue Aug 21 01:56:15 2012 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 8AF9A21F870A for ; Tue, 21 Aug 2012 01:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+Iy3M+fRA4y for ; Tue, 21 Aug 2012 01:56:14 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id A092721F8704 for ; Tue, 21 Aug 2012 01:56:14 -0700 (PDT) Received: from mail24-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 08:56:13 +0000 Received: from mail24-va3 (localhost [127.0.0.1]) by mail24-va3-R.bigfish.com (Postfix) with ESMTP id 639BF40220; Tue, 21 Aug 2012 08:56:13 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: PS-30(zz9371I542M1432Ia65R853kzz1202hzz8275ch1033IL8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail24-va3 (localhost.localdomain [127.0.0.1]) by mail24-va3 (MessageSwitch) id 1345539371736988_17718; Tue, 21 Aug 2012 08:56:11 +0000 (UTC) Received: from VA3EHSMHS030.bigfish.com (unknown [10.7.14.247]) by mail24-va3.bigfish.com (Postfix) with ESMTP id B0BEA2C035F; Tue, 21 Aug 2012 08:56:11 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS030.bigfish.com (10.7.99.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 08:56:08 +0000 Received: from CH1PRD0710HT001.namprd07.prod.outlook.com (157.56.245.5) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 21 Aug 2012 08:56:03 +0000 Message-ID: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , "Bert Wijnen (IETF)" , netconf References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> Date: Tue, 21 Aug 2012 09:51:10 +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.245.5] X-OriginatorOrg: btconnect.com Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 08:56:15 -0000 Going back to the original question, I cannot see how we can meaningfully work on item 2) without first resolving this issue of a third type of data. Most of the views expressed in the past day or so seem to support the existence of a third type, which is something I cannot reconcile with RFC6241 as currently worded. In which case, item 2) does not make sense to me. As Lada says, 'there was a reasonable agreement that work on xxx' is needed for some choice of the phrase xxx. Tom Petch ----- Original Message ----- From: "Ladislav Lhotka" To: "Bert Wijnen (IETF)" ; "netconf" Sent: Friday, August 17, 2012 10:04 AM > > I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. > > So I propose the following fourth item for the charter: > > 4. The WG will investigate the relationship and interactions between configurations and > operational state data, propose their appropriate representation and semantics, and > devise methods for effective data modeling of both configurations and operational state data. > It is expected that this work will be carried out in a close sooperation with the NETMOD WG. > > Lada > > "Bert Wijnen (IETF)" writes: > > > Based on the comments and feedback and the positions > > expressed on the mailing list, it is clear that after all > > we did NOT have consensus on the new WG charter. > > > > Without further ado, this is another proposed WG charter. > > It focuses on the things that we do seme to have agreement on. > > > > Pls comment and/or express your support or objections > > no later than August 31, 2012. > > > > OK, new chapter text (omitting the description of what we have > > achieved sofar): > > > > In the current phase of the incremental development of NETCONF the > > workgroup will focus on following items: > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > This means that RFC5593 needs to be updated. > > > > 2. Based on the implementation, deployment experience and interoperability > > testing, the WG will document the status of NETCONF in a report. > > Based on this, the WG may decide to make some clarifications to > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > the WG will write a document that makes those 2 protocols > > (RFC4743 and RFC4744) HISTORIC. > > > > Goals and Milestones: > > done - Send with-defaults to IESG for consideration as Proposed Standard > > done - WG Last Call on rfc4741bis > > 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 NACM posted > > 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 > > Aug 2012 - submit initial WG draft for rfc5539bis > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > > Sep 2012 - WGLC for rfc5539bis > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > > to IESG for publication as Informational RFC. > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG > > > > Bert and Mehmet > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From mbj@tail-f.com Tue Aug 21 02:06:17 2012 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 D2D9A21F86A1 for ; Tue, 21 Aug 2012 02:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYn8obD3ZfHz for ; Tue, 21 Aug 2012 02:06:17 -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 DF8A421F8671 for ; Tue, 21 Aug 2012 02:06:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7C7451200D40; Tue, 21 Aug 2012 11:06:14 +0200 (CEST) Date: Tue, 21 Aug 2012 11:06:14 +0200 (CEST) Message-Id: <20120821.110614.245770058077084953.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 09:06:17 -0000 t.petch wrote: > Going back to the original question, I cannot see how we can > meaningfully work on item 2) without first resolving this issue of a > third type of data. Most of the views expressed in the past day or so > seem to support the existence of a third type, which is something I > cannot reconcile with RFC6241 as currently worded. In which case, item > 2) does not make sense to me. As Lada says, 'there was a reasonable > agreement that work on xxx' is needed for some choice of the phrase xxx. The way I see this is that NETCONF currently does not support read/write of operational state. This would be an additional feature that we might add in the future. But this should not preclude us from verifying the existing protocol with its current features (which I beleive what item 2 is about). /martin > > Tom Petch > > > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "Bert Wijnen (IETF)" ; "netconf" > > Sent: Friday, August 17, 2012 10:04 AM > > > > I had the impression that there was a reasonable agreement that work > on operational state data is needed. Although this problem lies > somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a > better position to start this work because apparently NETMOD WG will > have to continue the work on the core data models for some time. > > > > So I propose the following fourth item for the charter: > > > > 4. The WG will investigate the relationship and interactions between > configurations and > > operational state data, propose their appropriate representation > and semantics, and > > devise methods for effective data modeling of both configurations > and operational state data. > > It is expected that this work will be carried out in a close > sooperation with the NETMOD WG. > > > > Lada > > > > "Bert Wijnen (IETF)" writes: > > > > > Based on the comments and feedback and the positions > > > expressed on the mailing list, it is clear that after all > > > we did NOT have consensus on the new WG charter. > > > > > > Without further ado, this is another proposed WG charter. > > > It focuses on the things that we do seme to have agreement on. > > > > > > Pls comment and/or express your support or objections > > > no later than August 31, 2012. > > > > > > OK, new chapter text (omitting the description of what we have > > > achieved sofar): > > > > > > In the current phase of the incremental development of NETCONF > the > > > workgroup will focus on following items: > > > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > > This means that RFC5593 needs to be updated. > > > > > > 2. Based on the implementation, deployment experience and > interoperability > > > testing, the WG will document the status of NETCONF in a > report. > > > Based on this, the WG may decide to make some clarifications > to > > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > > the WG will write a document that makes those 2 protocols > > > (RFC4743 and RFC4744) HISTORIC. > > > > > > Goals and Milestones: > > > done - Send with-defaults to IESG for consideration as > Proposed Standard > > > done - WG Last Call on rfc4741bis > > > 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 NACM posted > > > 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 > > > Aug 2012 - submit initial WG draft for rfc5539bis > > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > > > Sep 2012 - WGLC for rfc5539bis > > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as > Proposed Standard > > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 > historic > > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 > and 6242 > > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment > experience > > > Feb 2013 - submit RFC6241/6242 implementation/deployment > experience doc > > > to IESG for publication as Informational RFC. > > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG > or close WG > > > > > > Bert and Mehmet > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From bertietf@bwijnen.net Tue Aug 21 02:33:32 2012 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 175AF21F854F for ; Tue, 21 Aug 2012 02:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.777 X-Spam-Level: X-Spam-Status: No, score=-101.777 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diTxLeHQpw53 for ; Tue, 21 Aug 2012 02:33:31 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 2C74421F8550 for ; Tue, 21 Aug 2012 02:33:28 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T3kps-0006kR-0o; Tue, 21 Aug 2012 11:33:21 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T3kpr-00085w-RI; Tue, 21 Aug 2012 11:33:19 +0200 Message-ID: <503355DF.3020305@bwijnen.net> Date: Tue, 21 Aug 2012 11:33:19 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Martin Bjorklund References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> In-Reply-To: <20120821.110614.245770058077084953.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120821 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd445a2e70641c248b257563b3499c0e86e Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 09:33:32 -0000 On 8/21/12 11:06 AM, Martin Bjorklund wrote: > t.petch wrote: >> Going back to the original question, I cannot see how we can >> meaningfully work on item 2) without first resolving this issue of a >> third type of data. Most of the views expressed in the past day or so >> seem to support the existence of a third type, which is something I >> cannot reconcile with RFC6241 as currently worded. In which case, item >> 2) does not make sense to me. As Lada says, 'there was a reasonable >> agreement that work on xxx' is needed for some choice of the phrase xxx. > > The way I see this is that NETCONF currently does not support > read/write of operational state. This would be an additional feature > that we might add in the future. But this should not preclude us from > verifying the existing protocol with its current features (which I > beleive what item 2 is about). > EXACTLY. It has been a long while (I believe) that we last did any interoperability testing. Would be very good to know what the state of the art is and if the RFCs are clear for implementers. Bert > > /martin > > > >> >> Tom Petch >> >> >> ----- Original Message ----- >> From: "Ladislav Lhotka" >> To: "Bert Wijnen (IETF)" ; "netconf" >> >> Sent: Friday, August 17, 2012 10:04 AM >>> >>> I had the impression that there was a reasonable agreement that work >> on operational state data is needed. Although this problem lies >> somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a >> better position to start this work because apparently NETMOD WG will >> have to continue the work on the core data models for some time. >>> >>> So I propose the following fourth item for the charter: >>> >>> 4. The WG will investigate the relationship and interactions between >> configurations and >>> operational state data, propose their appropriate representation >> and semantics, and >>> devise methods for effective data modeling of both configurations >> and operational state data. >>> It is expected that this work will be carried out in a close >> sooperation with the NETMOD WG. >>> >>> Lada >>> >>> "Bert Wijnen (IETF)" writes: >>> >>>> Based on the comments and feedback and the positions >>>> expressed on the mailing list, it is clear that after all >>>> we did NOT have consensus on the new WG charter. >>>> >>>> Without further ado, this is another proposed WG charter. >>>> It focuses on the things that we do seme to have agreement on. >>>> >>>> Pls comment and/or express your support or objections >>>> no later than August 31, 2012. >>>> >>>> OK, new chapter text (omitting the description of what we have >>>> achieved sofar): >>>> >>>> In the current phase of the incremental development of NETCONF >> the >>>> workgroup will focus on following items: >>>> >>>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>>> This means that RFC5593 needs to be updated. >>>> >>>> 2. Based on the implementation, deployment experience and >> interoperability >>>> testing, the WG will document the status of NETCONF in a >> report. >>>> Based on this, the WG may decide to make some clarifications >> to >>>> RFC6241 and RFC6242 (then also fixing any reported errata). >>>> >>>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>>> the WG will write a document that makes those 2 protocols >>>> (RFC4743 and RFC4744) HISTORIC. >>>> >>>> Goals and Milestones: >>>> done - Send with-defaults to IESG for consideration as >> Proposed Standard >>>> done - WG Last Call on rfc4741bis >>>> 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 NACM posted >>>> 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 >>>> Aug 2012 - submit initial WG draft for rfc5539bis >>>> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >> historic. >>>> Sep 2012 - WGLC for rfc5539bis >>>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as >> Proposed Standard >>>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 >> historic >>>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 >> and 6242 >>>> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment >> experience >>>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment >> experience >>>> Feb 2013 - submit RFC6241/6242 implementation/deployment >> experience doc >>>> to IESG for publication as Informational RFC. >>>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG >> or close WG >>>> >>>> Bert and Mehmet >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From ietfc@btconnect.com Tue Aug 21 03:22:30 2012 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 46F9321F86D1 for ; Tue, 21 Aug 2012 03:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+wR9zRGOsJb for ; Tue, 21 Aug 2012 03:22:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5F77621F86D0 for ; Tue, 21 Aug 2012 03:22:28 -0700 (PDT) Received: from mail180-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 10:22:28 +0000 Received: from mail180-ch1 (localhost [127.0.0.1]) by mail180-ch1-R.bigfish.com (Postfix) with ESMTP id 4EB2940421; Tue, 21 Aug 2012 10:22:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: PS-31(zz98dI9371I542M1432Ia65R853kzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail180-ch1 (localhost.localdomain [127.0.0.1]) by mail180-ch1 (MessageSwitch) id 1345544545911057_10902; Tue, 21 Aug 2012 10:22:25 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail180-ch1.bigfish.com (Postfix) with ESMTP id DC2D2380056; Tue, 21 Aug 2012 10:22:25 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 10:22:25 +0000 Received: from CH1PRD0710HT004.namprd07.prod.outlook.com (157.56.245.5) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 21 Aug 2012 10:22:24 +0000 Message-ID: <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <502D7052.2070302@bwijnen.net><00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> Date: Tue, 21 Aug 2012 11:17:32 +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.245.5] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 10:22:30 -0000 ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Tuesday, August 21, 2012 10:06 AM > t.petch wrote: > > Going back to the original question, I cannot see how we can > > meaningfully work on item 2) without first resolving this issue of a > > third type of data. Most of the views expressed in the past day or so > > seem to support the existence of a third type, which is something I > > cannot reconcile with RFC6241 as currently worded. In which case, item > > 2) does not make sense to me. As Lada says, 'there was a reasonable > > agreement that work on xxx' is needed for some choice of the phrase xxx. > > The way I see this is that NETCONF currently does not support > read/write of operational state. This would be an additional feature > that we might add in the future. But this should not preclude us from > verifying the existing protocol with its current features (which I > beleive what item 2 is about). Yes, but should we be approving the definitions in NETCONF base of there only being two kinds of data when we seem to have established that there are more? I think not. I was not suggesting we go as far as Lada, in developing schema and protocol, but that we should update the definitions to accept that there is at least one more type of data - such as ephemeral configuration - which is a subject for future work. I prefer 'ephemeral configuration' to operational state, since we have resolutely stated for 10 years than state is read only whereas configuration is written, so now to have writable state seems a bigger somersault than to have ephemeral configuration. Tom Petch > > /martin > > > > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Ladislav Lhotka" > > To: "Bert Wijnen (IETF)" ; "netconf" > > > > Sent: Friday, August 17, 2012 10:04 AM > > > > > > I had the impression that there was a reasonable agreement that work > > on operational state data is needed. Although this problem lies > > somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a > > better position to start this work because apparently NETMOD WG will > > have to continue the work on the core data models for some time. > > > > > > So I propose the following fourth item for the charter: > > > > > > 4. The WG will investigate the relationship and interactions between > > configurations and > > > operational state data, propose their appropriate representation > > and semantics, and > > > devise methods for effective data modeling of both configurations > > and operational state data. > > > It is expected that this work will be carried out in a close > > sooperation with the NETMOD WG. > > > > > > Lada > > > > > > "Bert Wijnen (IETF)" writes: > > > > > > > Based on the comments and feedback and the positions > > > > expressed on the mailing list, it is clear that after all > > > > we did NOT have consensus on the new WG charter. > > > > > > > > Without further ado, this is another proposed WG charter. > > > > It focuses on the things that we do seme to have agreement on. > > > > > > > > Pls comment and/or express your support or objections > > > > no later than August 31, 2012. > > > > > > > > OK, new chapter text (omitting the description of what we have > > > > achieved sofar): > > > > > > > > In the current phase of the incremental development of NETCONF > > the > > > > workgroup will focus on following items: > > > > > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > > > This means that RFC5593 needs to be updated. > > > > > > > > 2. Based on the implementation, deployment experience and > > interoperability > > > > testing, the WG will document the status of NETCONF in a > > report. > > > > Based on this, the WG may decide to make some clarifications > > to > > > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > > > the WG will write a document that makes those 2 protocols > > > > (RFC4743 and RFC4744) HISTORIC. > > > > > > > > Goals and Milestones: > > > > done - Send with-defaults to IESG for consideration as > > Proposed Standard > > > > done - WG Last Call on rfc4741bis > > > > 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 NACM posted > > > > 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 > > > > Aug 2012 - submit initial WG draft for rfc5539bis > > > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > > historic. > > > > Sep 2012 - WGLC for rfc5539bis > > > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as > > Proposed Standard > > > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 > > historic > > > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 > > and 6242 > > > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > > experience > > > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment > > experience > > > > Feb 2013 - submit RFC6241/6242 implementation/deployment > > experience doc > > > > to IESG for publication as Informational RFC. > > > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG > > or close WG > > > > > > > > Bert and Mehmet > > > > _______________________________________________ > > > > Netconf mailing list > > > > Netconf@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: E74E8C0C > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > From mbj@tail-f.com Tue Aug 21 03:30:47 2012 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 AC5EE21F86C7 for ; Tue, 21 Aug 2012 03:30:47 -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.247, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8UvSmvPn967 for ; Tue, 21 Aug 2012 03:30:47 -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 182CC21F86A3 for ; Tue, 21 Aug 2012 03:30:46 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 216721200D40; Tue, 21 Aug 2012 12:30:46 +0200 (CEST) Date: Tue, 21 Aug 2012 12:30:45 +0200 (CEST) Message-Id: <20120821.123045.1963971943672105467.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> References: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 10:30:47 -0000 t.petch wrote: > ----- Original Message ----- > From: "Martin Bjorklund" > To: > Cc: ; ; > Sent: Tuesday, August 21, 2012 10:06 AM > > t.petch wrote: > > > Going back to the original question, I cannot see how we can > > > meaningfully work on item 2) without first resolving this issue of a > > > third type of data. Most of the views expressed in the past day or > so > > > seem to support the existence of a third type, which is something I > > > cannot reconcile with RFC6241 as currently worded. In which case, > item > > > 2) does not make sense to me. As Lada says, 'there was a reasonable > > > agreement that work on xxx' is needed for some choice of the phrase > xxx. > > > > The way I see this is that NETCONF currently does not support > > read/write of operational state. This would be an additional feature > > that we might add in the future. But this should not preclude us from > > verifying the existing protocol with its current features (which I > > beleive what item 2 is about). > > Yes, but should we be approving the definitions in NETCONF base of there > only being two kinds of data when we seem to have established that there > are > more? I think not. Item 2) was: 2. Based on the implementation, deployment experience and interoperability testing, the WG will document the status of NETCONF in a report. Based on this, the WG may decide to make some clarifications to RFC6241 and RFC6242 (then also fixing any reported errata). I think both these activities can be done w/o introducing "operational state" (or whatever the term will be). However, if (as a result of the report) we open 6241, there is of course an opportunity to define more terms etc... /martin From mbj@tail-f.com Tue Aug 21 03:56:28 2012 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 0B2B621F875B for ; Tue, 21 Aug 2012 03:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFDKgZ2hyO2P for ; Tue, 21 Aug 2012 03:56:27 -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 5C17721F875A for ; Tue, 21 Aug 2012 03:56:27 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 320421200D40; Tue, 21 Aug 2012 12:56:26 +0200 (CEST) Date: Tue, 21 Aug 2012 12:56:25 +0200 (CEST) Message-Id: <20120821.125625.243340034007491618.mbj@tail-f.com> To: ietfc@btconnect.com From: Martin Bjorklund In-Reply-To: <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> References: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: [Netconf] Operational state (Was: New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st) 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 Aug 2012 10:56:28 -0000 t.petch wrote: > I prefer 'ephemeral configuration' to operational state, since we have > resolutely > stated for 10 years than state is read only whereas configuration is > written, so > now to have writable state seems a bigger somersault than to have > ephemeral > configuration. To me, "ephemeral configuration" seems to indicate that it is a separate datastore, probably merged with the running datastore to produce the initial operational state (what the device is *really* using). The IRS people had a use case where they wanted to inject routes into the routing table. If the routing table is operation state, they need to modify the operational state through a protocol. I think a solution that directly modifies the operational state is easy to understand and use, but a solution that merges different datastores will be very complex. But I guess we need to work out the details and describe the solutions we believe work in individual drafts. /martin From ietfc@btconnect.com Tue Aug 21 06:07:51 2012 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 69DAB21F855F for ; Tue, 21 Aug 2012 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dftMF7k0Pv+X for ; Tue, 21 Aug 2012 06:07:50 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id A64CA21F8581 for ; Tue, 21 Aug 2012 06:07:50 -0700 (PDT) Received: from mail1-va3-R.bigfish.com (10.7.14.252) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Tue, 21 Aug 2012 13:07:49 +0000 Received: from mail1-va3 (localhost [127.0.0.1]) by mail1-va3-R.bigfish.com (Postfix) with ESMTP id 794EF1803BA; Tue, 21 Aug 2012 13:07:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT010.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz98dI9371I542M1432I853kzz1202hzz8275ch1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l) Received: from mail1-va3 (localhost.localdomain [127.0.0.1]) by mail1-va3 (MessageSwitch) id 1345554468266171_18517; Tue, 21 Aug 2012 13:07:48 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.253]) by mail1-va3.bigfish.com (Postfix) with ESMTP id 32C57200047; Tue, 21 Aug 2012 13:07:48 +0000 (UTC) Received: from DB3PRD0702HT010.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 21 Aug 2012 13:07:45 +0000 Received: from CH1PRD0710HT004.namprd07.prod.outlook.com (157.56.245.5) by pod51017.outlook.com (10.3.4.178) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 21 Aug 2012 13:07:42 +0000 Message-ID: <016301cd7f9d$4a5cc840$4001a8c0@gateway.2wire.net> From: t.petch To: Martin Bjorklund References: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net><20120821.110614.245770058077084953.mbj@tail-f.com><011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120821.123045.1963971943672105467.mbj@tail-f.com> Date: Tue, 21 Aug 2012 14:02:51 +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.245.5] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 13:07:51 -0000 ---- Original Message ----- From: "Martin Bjorklund" To: Cc: ; ; Sent: Tuesday, August 21, 2012 11:30 AM > t.petch wrote: > > ----- Original Message ----- > > From: "Martin Bjorklund" > > To: > > Cc: ; ; > > Sent: Tuesday, August 21, 2012 10:06 AM > > > t.petch wrote: > > > > Going back to the original question, I cannot see how we can > > > > meaningfully work on item 2) without first resolving this issue of a > > > > third type of data. Most of the views expressed in the past day or > > so > > > > seem to support the existence of a third type, which is something I > > > > cannot reconcile with RFC6241 as currently worded. In which case, > > item > > > > 2) does not make sense to me. As Lada says, 'there was a reasonable > > > > agreement that work on xxx' is needed for some choice of the phrase > > xxx. > > > > > > The way I see this is that NETCONF currently does not support > > > read/write of operational state. This would be an additional feature > > > that we might add in the future. But this should not preclude us from > > > verifying the existing protocol with its current features (which I > > > beleive what item 2 is about). > > > > Yes, but should we be approving the definitions in NETCONF base of there > > only being two kinds of data when we seem to have established that there > > are > > more? I think not. > > Item 2) was: > > 2. Based on the implementation, deployment experience and > interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). > > I think both these activities can be done w/o introducing "operational > state" (or whatever the term will be). Yes, it can be done:-) I think though, that given the current debate about how many states there are, it would be wrong not to tackle the issue as part of 2) i.e 2) should call out this issue as a possible clarification, that we agree that this must be looked at even if we do not go as far as new protocols or schema. Tom Petch > However, if (as a result of the report) we open 6241, there is of > course an opportunity to define more terms etc... > > /martin > From lhotka@nic.cz Tue Aug 21 06:19:11 2012 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 6403F21F85AD for ; Tue, 21 Aug 2012 06:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjRJNSzhZ16t for ; Tue, 21 Aug 2012 06:19:10 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7F821F8597 for ; Tue, 21 Aug 2012 06:19:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 509EB540436; Tue, 21 Aug 2012 15:19:08 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20S+cnW34-mZ; Tue, 21 Aug 2012 15:19:01 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 272225401C0; Tue, 21 Aug 2012 15:19:00 +0200 (CEST) From: Ladislav Lhotka To: "Bert Wijnen \(IETF\)" In-Reply-To: <502E0A3B.9010008@bwijnen.net> References: <502D073D.7090200@bwijnen.net> <502D7052.2070302@bwijnen.net> <502E0A3B.9010008@bwijnen.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 21 Aug 2012 15:19:04 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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 Aug 2012 13:19:11 -0000 "Bert Wijnen (IETF)" writes: > We had agreed in our last f2f meeting that people would submit > individual I-Ds, and based on that we would potentially > consider work in this space. So by all means do submit > such individual drafts and discuss them on the mailing list. > > But we do not have a good problem statement or starting I-D > to base this work on, so cannot put it on the current charter. OK, after this clarification I support the charter with your three items. I am sorry for leading this thread a little astray, it was not my intention. Lada > > Bert Wijnen > > On 8/17/12 11:04 AM, Ladislav Lhotka wrote: >> Hi, >> >> I had the impression that there was a reasonable agreement that work on operational state data is needed. Although this problem lies somewhere between NETCONF and NETMOD, I think the NETCONF WG is now in a better position to start this work because apparently NETMOD WG will have to continue the work on the core data models for some time. >> >> So I propose the following fourth item for the charter: >> >> 4. The WG will investigate the relationship and interactions between configurations and >> operational state data, propose their appropriate representation and semantics, and >> devise methods for effective data modeling of both configurations and operational state data. >> It is expected that this work will be carried out in a close sooperation with the NETMOD WG. >> >> Lada >> >> "Bert Wijnen (IETF)" writes: >> >>> Based on the comments and feedback and the positions >>> expressed on the mailing list, it is clear that after all >>> we did NOT have consensus on the new WG charter. >>> >>> Without further ado, this is another proposed WG charter. >>> It focuses on the things that we do seme to have agreement on. >>> >>> Pls comment and/or express your support or objections >>> no later than August 31, 2012. >>> >>> OK, new chapter text (omitting the description of what we have >>> achieved sofar): >>> >>> In the current phase of the incremental development of NETCONF the >>> workgroup will focus on following items: >>> >>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>> This means that RFC5593 needs to be updated. >>> >>> 2. Based on the implementation, deployment experience and interoperability >>> testing, the WG will document the status of NETCONF in a report. >>> Based on this, the WG may decide to make some clarifications to >>> RFC6241 and RFC6242 (then also fixing any reported errata). >>> >>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>> the WG will write a document that makes those 2 protocols >>> (RFC4743 and RFC4744) HISTORIC. >>> >>> Goals and Milestones: >>> done - Send with-defaults to IESG for consideration as Proposed Standard >>> done - WG Last Call on rfc4741bis >>> 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 NACM posted >>> 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 >>> Aug 2012 - submit initial WG draft for rfc5539bis >>> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. >>> Sep 2012 - WGLC for rfc5539bis >>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard >>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic >>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 >>> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience >>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >>> Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc >>> to IESG for publication as Informational RFC. >>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG >>> >>> Bert and Mehmet >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Aug 21 06:52:48 2012 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 F382E21F846F for ; Tue, 21 Aug 2012 06:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqLc1x7haQ3Z for ; Tue, 21 Aug 2012 06:52:47 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5909021F84D3 for ; Tue, 21 Aug 2012 06:52:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4BB55540436; Tue, 21 Aug 2012 15:52:46 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-i7dJIf5HZA; Tue, 21 Aug 2012 15:52:41 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id D1B015401C0; Tue, 21 Aug 2012 15:52:38 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , ietfc@btconnect.com In-Reply-To: <20120821.125625.243340034007491618.mbj@tail-f.com> References: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120821.125625.243340034007491618.mbj@tail-f.com> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Tue, 21 Aug 2012 15:52:37 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] Operational state (Was: New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st) 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 Aug 2012 13:52:48 -0000 Martin Bjorklund writes: > t.petch wrote: >> I prefer 'ephemeral configuration' to operational state, since we have >> resolutely >> stated for 10 years than state is read only whereas configuration is >> written, so >> now to have writable state seems a bigger somersault than to have >> ephemeral >> configuration. > > To me, "ephemeral configuration" seems to indicate that it is a > separate datastore, probably merged with the running datastore to > produce the initial operational state (what the device is *really* > using). Why is it then called ephemeral? To me, this adjective indicates that this configuration will disappear after a while. > > The IRS people had a use case where they wanted to inject routes into > the routing table. If the routing table is operation state, they need > to modify the operational state through a protocol. But is this really different from NETCONF? The NETCONF client provides a list of static routes and these routes eventually appear in the routing table. Writing directly to the routing table just bypasses - for better or worse - all bells and whistles of the NETCONF stack (and maybe other software). It's like with the speed of a car - a normal driver's interface are only the pedals while a serviceman may be able to connect a special-purpose computer to achieve the same effect more directly. The statement that operational state is not writeble means (to me at least) that the NETCONF client can achieve modifications in the state only through writing something to the running datastore. However, the state as such must be modifiable, otherwise the device wouldn't be very interesting. > > I think a solution that directly modifies the operational state is > easy to understand and use, but a solution that merges different > datastores will be very complex. But I guess we need to work out the > details and describe the solutions we believe work in individual > drafts. +1 Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Aug 21 08:49:38 2012 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 4CFAF21F86DE for ; Tue, 21 Aug 2012 08:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.221 X-Spam-Level: X-Spam-Status: No, score=-2.221 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y08ow6PVjbw for ; Tue, 21 Aug 2012 08:49:37 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4F21F86C8 for ; Tue, 21 Aug 2012 08:49:37 -0700 (PDT) Received: by qadb17 with SMTP id b17so3682521qad.10 for ; Tue, 21 Aug 2012 08:49:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=wMBKHxSQUZJ9oyvveiGtfP+PijXmRLV0fkyldICuI7w=; b=aKxffhX6MBWHoZmFrSLT/jpqHseIabOX+DkRyiTVFQ50RhfkXy6Yg/cTUkJH8umrDc eNOy/bi+hdKGoPCXfULAASAX4FDdNF4EbcvfB3130AdITjqVvR0ikQkRKS4cu/9Taj05 43f8wXTu/UEG4uT/taDWUWpoMRyBOl//kKqZuUXgqVawqEUzEeR2PnkPO2B84OGG6bIo tmmWuOYfG+PoM45t0r8ZWX2qGZ7iudfzNnw6jNNxOf7NXOhiFQb2Xeqfg+RC44GIXEvi aC52P5YerlPkYQix49gD9kmXzpEX3IvAh+qL91iXt4qoNGPWu1AegcpQAkHRpT2Iny1P XQzw== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr4961355qaf.2.1345564170554; Tue, 21 Aug 2012 08:49:30 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Tue, 21 Aug 2012 08:49:30 -0700 (PDT) In-Reply-To: References: <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120821.125625.243340034007491618.mbj@tail-f.com> Date: Tue, 21 Aug 2012 08:49:30 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlyWlinsfo006BNtnn2cS17b4OGh77Q+H6VICs3kq27WmvImxePrQzeFn0a4ILTb9Q6KZAp Cc: netconf@ietf.org Subject: Re: [Netconf] Operational state (Was: New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st) 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 Aug 2012 15:49:38 -0000 On Tue, Aug 21, 2012 at 6:52 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > >> t.petch wrote: >>> I prefer 'ephemeral configuration' to operational state, since we have >>> resolutely >>> stated for 10 years than state is read only whereas configuration is >>> written, so >>> now to have writable state seems a bigger somersault than to have >>> ephemeral >>> configuration. >> >> To me, "ephemeral configuration" seems to indicate that it is a >> separate datastore, probably merged with the running datastore to >> produce the initial operational state (what the device is *really* >> using). > > Why is it then called ephemeral? To me, this adjective indicates that thi= s configuration will disappear after a while. > >> >> The IRS people had a use case where they wanted to inject routes into >> the routing table. If the routing table is operation state, they need >> to modify the operational state through a protocol. > > But is this really different from NETCONF? The NETCONF client provides a = list of static routes and these routes eventually appear in the routing tab= le. Writing directly to the routing table just bypasses - for better or wor= se - all bells and whistles of the NETCONF stack (and maybe other software)= . > > It's like with the speed of a car - a normal driver's interface are only = the pedals while a serviceman may be able to connect a special-purpose comp= uter to achieve the same effect more directly. > > The statement that operational state is not writeble means (to me at leas= t) that the NETCONF client can achieve modifications in the state only thro= ugh writing something to the running datastore. > However, the state as such must be modifiable, otherwise the device would= n't be very interesting. > > >> >> I think a solution that directly modifies the operational state is >> easy to understand and use, but a solution that merges different >> datastores will be very complex. But I guess we need to work out the >> details and describe the solutions we believe work in individual >> drafts. > I agree with Martin that operational state can be added as a new capability= . There is no impact on interoperability of existing operations that I can se= e. Here is a list of operational state examples that Lada raised 3 years ago: The recent examples demonstrate various interactions between config and operational parameters, e.g. - IP address configured either manually (from a config item) or via DH= CP - use global value if local is not set (hold-time example) - operational routing table is a union of static routes (config item) and routes obtained from routing protocols I think the each NETMOD YANG module addresses these operational state issues in an ad-hoc manner. The new feature we are calling "operational st= ate" is to be able to handle this class of data in a generic manner. Currently we can use the description-stmt to say that operStatus is related to the adminStatus leaf. We can write a custom RPC called if we want to modify specific operational routing data. I am not seen any generic solution proposals and I am not convinced that a generic approach will be worth the cost, and be that much better than the ad-hoc approach we already have. I certainly do not agree that base:1.1 is broken because we have an ad-hoc solution instead of a generic solution for this corner-case. > +1 > > Lada Andy > >> >> >> /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue Aug 21 10:17:02 2012 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 D3CB021F8775 for ; Tue, 21 Aug 2012 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1sKE8dwLkQ2 for ; Tue, 21 Aug 2012 10:17:02 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 0951E21F8772 for ; Tue, 21 Aug 2012 10:16:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPCi9tOt0ne1aZGw7XJVco8jlpbssz9@postini.com; Tue, 21 Aug 2012 10:17:02 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 10:15:26 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7LEhIh01207; Tue, 21 Aug 2012 07:43:19 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7LEg2lh037439; Tue, 21 Aug 2012 10:42:22 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208211442.q7LEg2lh037439@idle.juniper.net> To: Kent Watsen In-Reply-To: Date: Tue, 21 Aug 2012 10:42:02 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 17:17:02 -0000 Kent Watsen writes: >To me, ephemeral configuration is *config* that either goes to a special >datastore or to the "running" datastore with an XML-attribute indicating >that it's ephemeral. I have a hard time using the term "config" for a route learned via BGP or an address learned via DHCP. This will be hopelessly confusing to modelers and reviewers. Thanks, Phil From kwatsen@juniper.net Tue Aug 21 10:26:45 2012 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 9F25521F8723 for ; Tue, 21 Aug 2012 10:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T33tO9m5LgEq for ; Tue, 21 Aug 2012 10:26:45 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 059A221F86C8 for ; Tue, 21 Aug 2012 10:26:44 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPE0ghCjzmMdy/Xvce5nV54MhRt33z6@postini.com; Tue, 21 Aug 2012 10:26:45 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 21 Aug 2012 10:26:16 -0700 From: Kent Watsen To: Phil Shafer Date: Tue, 21 Aug 2012 10:26:16 -0700 Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: Ac1/whIKOLKaAtQiQCGLCaHtD/UBQw== Message-ID: In-Reply-To: <201208211442.q7LEg2lh037439@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 17:26:45 -0000 On 8/21/12 10:42 AM, "Phil Shafer" wrote: >Kent Watsen writes: >>To me, ephemeral configuration is *config* that either goes to a special >>datastore or to the "running" datastore with an XML-attribute indicating >>that it's ephemeral. > >I have a hard time using the term "config" for a route learned via >BGP or an address learned via DHCP. This will be hopelessly >confusing to modelers and reviewers. Agreed. My use of ephemeral config wasn't intended to cover what's learned from within protocols, which seems more like "operational state" as far as NETCONF is concerned. I liked very much what Alex wrote yesterday: At the end of the day, what is important is who "owns" the data, i.e. Where it originates from - an external app or the managed system - this is what I think the operational / config data distinction ultimately refers to (making "operational" somewhat of a misnomer) - and whether the data is "transient" or "persistent", which could be covered by the notion of different data stores. Thanks, Kent From andy@yumaworks.com Tue Aug 21 11:04:48 2012 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 2161821F853B for ; Tue, 21 Aug 2012 11:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.816 X-Spam-Level: X-Spam-Status: No, score=-2.816 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvNz1udPK8W2 for ; Tue, 21 Aug 2012 11:04:47 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3137421F8679 for ; Tue, 21 Aug 2012 11:04:47 -0700 (PDT) Received: by qcac10 with SMTP id c10so72788qca.31 for ; Tue, 21 Aug 2012 11:04:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=JIDAA4zfBUGESqOc0s36C2gFsxDarjZU/zPyhbFou64=; b=eSLpOvvCCI6ehn66YHjKQCv0yWKAeKmGaNuedlHF4/BK4iHoy9u+8QyMuvRGT5yQge uAwZeIcoDEuhkUaTFMMAN9iv5tzF8k6mmEee++CK53g+F+fIOZqQkjaNg0qyeQuu3N4E kgNd5S1DnXEjisPhXzqvGiQJ//3cwQsX7x+e3s4I9m5ZU+1U5Mn0Ny8FMBm9cwzoVY57 bApL7KxdlyCOGZa+aQkhW0wkWotj+XOwk56cRDQxdVzI6PDCOU83dp5Umu+NeDc/LXjX UOyd8N6Owk54CeMUlIoKMi65X1YTrzRYZDlL8bwJNhpgaFjmNVg2oTa1pc/d8YrTbx6c ECFw== MIME-Version: 1.0 Received: by 10.229.136.14 with SMTP id p14mr7589803qct.93.1345572281110; Tue, 21 Aug 2012 11:04:41 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Tue, 21 Aug 2012 11:04:39 -0700 (PDT) In-Reply-To: References: <201208211442.q7LEg2lh037439@idle.juniper.net> Date: Tue, 21 Aug 2012 11:04:39 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQk5j6u9StT0qVjsWiD6mUottxStPrw3YfZAbA7tRmubNZzN4Hp+iMc8MY3GORO3DahDzDe/ Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 18:04:48 -0000 On Tue, Aug 21, 2012 at 10:26 AM, Kent Watsen wrote: > > > On 8/21/12 10:42 AM, "Phil Shafer" wrote: > >>Kent Watsen writes: >>>To me, ephemeral configuration is *config* that either goes to a special >>>datastore or to the "running" datastore with an XML-attribute indicating >>>that it's ephemeral. >> >>I have a hard time using the term "config" for a route learned via >>BGP or an address learned via DHCP. This will be hopelessly >>confusing to modelers and reviewers. > > Agreed. My use of ephemeral config wasn't intended to cover what's > learned from within protocols, which seems more like "operational state" > as far as NETCONF is concerned. > > I liked very much what Alex wrote yesterday: > > At the end of the day, what is important is who "owns" the data, i.e. > Where > it originates from - an external app or the managed system - this is what > I > think the operational / config data distinction ultimately refers to > (making > "operational" somewhat of a misnomer) - and whether the data is > "transient" > or "persistent", which could be covered by the notion of different data > stores. > This sounds like model-specific meta-data to me. Is also seems model-specific whether the internal protocol behavior needs to be modeled at all. (e.g., routing cfg vs. forwarding table). I am a bit concerned about boiling a lake if the charter is to identify every possible situation where a data modeler might want to allow the client to alter service behavior. Designing the solution for 1 popular use-case doesn't make it a generic solution. I like . That is long overdue. I am not convinced at all that is going to be better than model-specific operations like . > > Thanks, > Kent Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From phil@juniper.net Tue Aug 21 13:42:03 2012 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 AD23E21F85FF for ; Tue, 21 Aug 2012 13:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw8Zh+ASgykC for ; Tue, 21 Aug 2012 13:42:03 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 587B121F85FC for ; Tue, 21 Aug 2012 13:42:02 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUDPymWeUQ+nEKHq7Ubz+byrsDSt0DLgA@postini.com; Tue, 21 Aug 2012 13:42:03 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Aug 2012 13:41:29 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id q7LKfDh30038; Tue, 21 Aug 2012 13:41:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id q7LKe7u4039790; Tue, 21 Aug 2012 16:40:31 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201208212040.q7LKe7u4039790@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Tue, 21 Aug 2012 16:40:07 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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 Aug 2012 20:42:03 -0000 Andy Bierman writes: >I like . That is long overdue. >I am not convinced at all that >is going to be better than model-specific operations >like . means the model has to indicate if/how/when the operational data can be munged. I'd prefer is the operational data be the _real_ operational data and if the model wants to allow external interjection of data, they model that data and describe how it interacts with config data, operational data, learned data, etc. For example, if you expose your OSPF link state database as operational data, allowing clients to edit it would be pointless. The OSPF checksum would fail, and you would get a new copy of the database. But if you want to alter how that routes in the LSDB are imported into other RIBs, then that would need to be expressed in the model, and the router would need to understand how to integrate data from protocols, configuration, IRS, etc. So I think we need to look at a new sort of NETCONF datastore that I'll call "dynamic", in that data is put there dynamically during the normal operation of the router and it's neither configuration data nor operational data. We used the term "control data" at the last IETF, and either works, though "control" makes one think "control plane", which is not completely accurate. "Dynamic" is pretty fuzzy, but, well, that's completely appropriate. Many questions remain re: the interaction of config and dynamic data. But my guess is that the model will have to describe this in words. Thanks, Phil From randy_presuhn@mindspring.com Tue Aug 21 16:40:14 2012 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 DC55321F85A8 for ; Tue, 21 Aug 2012 16:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2ze58ooBviF for ; Tue, 21 Aug 2012 16:40:14 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC7221F859B for ; Tue, 21 Aug 2012 16:40:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nxGu1nTCq1vFkR56QNtJtAlgR0gMBMfbwkjlvaSaoRM1+eLuakWSRj/OW8nifvxl; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.30.226.42] (helo=oemcomputer) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1T3y3O-0003Q9-89 for netconf@ietf.org; Tue, 21 Aug 2012 19:40:10 -0400 Message-ID: <000401cd7ff7$295999c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Tue, 21 Aug 2012 16:46:16 -0700 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.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888b7f3a87d4e9c50f14b03056604eada68015f353942e50397350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.30.226.42 Subject: [Netconf] Transience, persistence, configuration and operational semantics 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 Aug 2012 23:40:15 -0000 Hi - (new subject line, heeding Bert's plea) > From: "Kent Watsen" > To: "Phil Shafer" > Cc: > Sent: Tuesday, August 21, 2012 10:26 AM > Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st > > > On 8/21/12 10:42 AM, "Phil Shafer" wrote: > > >Kent Watsen writes: > >>To me, ephemeral configuration is *config* that either goes to a special > >>datastore or to the "running" datastore with an XML-attribute indicating > >>that it's ephemeral. > > > >I have a hard time using the term "config" for a route learned via > >BGP or an address learned via DHCP. This will be hopelessly > >confusing to modelers and reviewers. > > Agreed. My use of ephemeral config wasn't intended to cover what's > learned from within protocols, which seems more like "operational state" > as far as NETCONF is concerned. > > I liked very much what Alex wrote yesterday: > > At the end of the day, what is important is who "owns" the data, i.e. > Where > it originates from - an external app or the managed system - this is what > I > think the operational / config data distinction ultimately refers to > (making > "operational" somewhat of a misnomer) - and whether the data is > "transient" > or "persistent", which could be covered by the notion of different data > stores. While that distinction is useful, more is needed, and it goes beyond ownership. It goes beyond whether a particular bit of data is writeable or even persistent. I think the first question is: (1) is it something that would make sense in *versioned* configuration data? That is, if the value is changed, it's really a different configuration, from a configuration management perspective. This begs a second question: (2) The flip side of this is that there may be knobs that can be twiddled, but which in a sense don't constitute a change to a system's configuration. While (1) is likely to be persistent, it doesn't have to be. Consider portions of a system's configuration delivered by other protocols - the mechanism for the persistence may lie outside the box. Likewise, (2) may include persistent post-it notes whose semantics put them outside the scope of (1). For example, a "Joe is monitoring this interface" post-it should probably be persistent across re-boots, but probably should not be considered as part of versioned configuration data. There are also the knobs that *do* things, but that we probably don't want to make persistent. For example, consider knobs on ephemeral objects like connections, or the route ontogenesis. Where does this all lead? It leads me to the conclusion that the persistence and +/- config of a piece of "configuration" are distinct aspects, and that the current approach which tends to mingle these will become increasingly problematic. With the historic management protocols, this would be purely a modeling issue, but the design of netconf makes it a protocol issue as well. Good luck. Randy From andy@yumaworks.com Wed Aug 22 08:09:06 2012 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 CEB2E21F8607 for ; Wed, 22 Aug 2012 08:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uKi6q5jg0Px for ; Wed, 22 Aug 2012 08:09:06 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2813721F85B1 for ; Wed, 22 Aug 2012 08:09:06 -0700 (PDT) Received: by qadb17 with SMTP id b17so4432417qad.10 for ; Wed, 22 Aug 2012 08:09:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MNv9gIH6I2xo/8l2QMtoBwpNswXfo2+cv7arOS1y78M=; b=ZD88briJzCN5XFplrofz8zBXLvJO9BIOsJkB/vrga2mtbvyyc/LZ+G610dG/JIDE80 S5gBXIu7FXGa2Zh1d2A8A5zS6suB4mA9eOpTgnU46fVSW2fcjB8egLYNNlHmmTO3FUq8 3nxjYGJTHy4CZpDuVOUTbexTHgQ2XrGV1FNGHYeQj5ADEaxR2o7L6CbRZ45GEOxcrsga 92WgS+1kvhr/LDZmQEqrefsdbgBGqqhdfRul2HQx5lLUWaYinHCDI5zOmZCMlhEbuzej ptWd3zMsGBEi4pB64WYs9R2UrZGkcs75Unmy8VZ4yl4TBUHw1/Wn6B++GNfRFLOfrfwn Ek1w== MIME-Version: 1.0 Received: by 10.224.44.202 with SMTP id b10mr11074939qaf.2.1345648145365; Wed, 22 Aug 2012 08:09:05 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 22 Aug 2012 08:09:05 -0700 (PDT) In-Reply-To: <000401cd7ff7$295999c0$6b01a8c0@oemcomputer> References: <000401cd7ff7$295999c0$6b01a8c0@oemcomputer> Date: Wed, 22 Aug 2012 08:09:05 -0700 Message-ID: From: Andy Bierman To: Randy Presuhn Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl4Y0KiwnoMa5kbWq7TYL4JmgShNGyV1hXawpIwTNXPloISVutkFbXCqTx3vfPAzIF8fjlI Cc: netconf@ietf.org Subject: Re: [Netconf] Transience, persistence, configuration and operational semantics 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, 22 Aug 2012 15:09:06 -0000 On Tue, Aug 21, 2012 at 4:46 PM, Randy Presuhn wrote: > Hi - > > (new subject line, heeding Bert's plea) > >> From: "Kent Watsen" >> To: "Phil Shafer" >> Cc: >> Sent: Tuesday, August 21, 2012 10:26 AM >> Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st >> >> >> On 8/21/12 10:42 AM, "Phil Shafer" wrote: >> >> >Kent Watsen writes: >> >>To me, ephemeral configuration is *config* that either goes to a special >> >>datastore or to the "running" datastore with an XML-attribute indicating >> >>that it's ephemeral. >> > >> >I have a hard time using the term "config" for a route learned via >> >BGP or an address learned via DHCP. This will be hopelessly >> >confusing to modelers and reviewers. >> >> Agreed. My use of ephemeral config wasn't intended to cover what's >> learned from within protocols, which seems more like "operational state" >> as far as NETCONF is concerned. >> >> I liked very much what Alex wrote yesterday: >> >> At the end of the day, what is important is who "owns" the data, i.e. >> Where >> it originates from - an external app or the managed system - this is what >> I >> think the operational / config data distinction ultimately refers to >> (making >> "operational" somewhat of a misnomer) - and whether the data is >> "transient" >> or "persistent", which could be covered by the notion of different data >> stores. > > While that distinction is useful, more is needed, and it goes beyond > ownership. It goes beyond whether a particular bit of data is > writeable or even persistent. I think the first question is: > > (1) is it something that would make sense in *versioned* > configuration data? That is, if the value is changed, it's > really a different configuration, from a configuration > management perspective. > > This begs a second question: > > (2) The flip side of this is that there may be knobs that can be > twiddled, but which in a sense don't constitute a change to > a system's configuration. > > While (1) is likely to be persistent, it doesn't have to be. Consider > portions of a system's configuration delivered by other protocols - > the mechanism for the persistence may lie outside the box. Likewise, > (2) may include persistent post-it notes whose semantics put them > outside the scope of (1). For example, a "Joe is monitoring this > interface" post-it should probably be persistent across re-boots, > but probably should not be considered as part of versioned > configuration data. > > There are also the knobs that *do* things, but that we probably don't > want to make persistent. For example, consider knobs on ephemeral > objects like connections, or the route ontogenesis. > > Where does this all lead? It leads me to the conclusion that > the persistence and +/- config of a piece of "configuration" > are distinct aspects, and that the current approach which > tends to mingle these will become increasingly problematic. > With the historic management protocols, this would be purely > a modeling issue, but the design of netconf makes it a > protocol issue as well. Good luck. I like the 'config comment' tagging example. Not only is config=false fuzzy, but so it config=true. We have work to do. ;-) Back in 2007, I thought the 3rd state (tconfig) was just like config except save-to-nvstore skipped this data. Transient config can be added or deleted by the client or server, but it was only part of the running config, never the startup config. Now I think this implementation was too simplistic, at least from a modeling perspective. It would be nice to get both the model and the implementation correct. The former is a much more subjective decision. > > Randy Andy From janl@tail-f.com Wed Aug 22 11:55:44 2012 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 ACCED21F866E for ; Wed, 22 Aug 2012 11:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.245 X-Spam-Level: X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seVbGTdKB6fp for ; Wed, 22 Aug 2012 11:55:43 -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 BCBE021F8665 for ; Wed, 22 Aug 2012 11:55:42 -0700 (PDT) Received: from [192.168.1.10] (unknown [117.198.141.196]) by mail.tail-f.com (Postfix) with ESMTPSA id D6D6D1200043; Wed, 22 Aug 2012 20:55:36 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_11FBF5CB-198C-4CD7-8F9B-735CE0206DBE" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Jan Lindblad In-Reply-To: Date: Wed, 22 Aug 2012 20:55:32 +0200 Message-Id: <362AB214-E6F7-4D35-BF34-84219D63624E@tail-f.com> References: <000401cd7ff7$295999c0$6b01a8c0@oemcomputer> To: Phil Shafer X-Mailer: Apple Mail (2.1485) Cc: "netconf@ietf.org" Subject: Re: [Netconf] Transience, persistence, configuration and operational semantics 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, 22 Aug 2012 18:55:44 -0000 --Apple-Mail=_11FBF5CB-198C-4CD7-8F9B-735CE0206DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let's organize the observations mentioned earlier in this thread into = perspective: 40 years ago, all routing information was config. Now it is mostly = operational data exchanged over routing protocols. 15 years ago we configured our host addresses. Now that us usually taken = care of by dhcp. 3 years ago base station frequencies and signal strengths were planned = and configured, today that is often operational data exchanged over SON = protocols. Today network topology is configuration, in a couple of years it might = be operational data exchanged over SDN protocols. When I define "configuration" in our NETCONF+Yang trainings, it usually = boils down to "the set of orders coming from the owner/commander of the = system". Alex and Kent said something similar "At the end of the day, = what is important is who "owns" the data, i.e. Where it originates = from." The truth is that with this definition, the set of objects that = constitute the configuration evolves over time, and it varies with the = use case. I think this is shown by the list of examples above. This = makes me wonder if this is (only) a modeling issue. A single model = declaring an element to be config or not, can't cover all use cases, = current and future. Even adding some middle state(s) to the single model = won't help really. Whatever you do here will only reflect the truth for = a specific set of use cases. Whether an element is treated as config or = not by a manager varies with the use case, and they vary over time. In many use cases (at least the ones I selected above) I think the = behavioral evolution can be summarized with: delegation. A manager delegates certain aspects (elements) of the configuration to a = sub-manager (protocol, mechanism). When that happens, the manager is no = longer interested in viewing the sub-managed aspects as part of the = (main) configuration. Those elements should no longer be visible in = , but in . They should no longer be included in backup = or rollback files visible to the manager. They should no longer be = affected by a operation performed by the main manager. =46rom the = manager's perspective, this is now operational data.=20 For the sub-manager, these elements should be treated as configuration. = They should be visible in , modified by , = affected by a performed by the sub-manager. The sub-manager = should not see the main part of the configuration, at least not be able = to modify it. =46rom the network element's perspective, lowest of them all, the set of = configurable elements is fixed. It is whatever the device offers to its = managers, delegated or not. It is still called running. So is the way to tackle the evolution of config true/false adding some = operation(s) to NETCONF? Maybe not.=20 Looking at the delegation concept more closely, I notice that this = resembles the semantics of a role based access control system, = implemented to its fullest. Could the main manager define access control = rules that limits its own view of the configuration, turning some areas = into (read-only) operational data? Could these rules limit the power of = to not include items that the main manager cannot touch? Could = the main manager configure a role for a sub-manager, such that the = sub-manager can view and modify the parts the main manager delegates? /Jan -- Jan Lindblad, janl@tail-f.com, +46 702855728 Principal Solutions Architect, Tail-f Systems, www.tail-f.com On 22 aug 2012, at 17:09, Andy Bierman wrote: > On Tue, Aug 21, 2012 at 4:46 PM, Randy Presuhn > wrote: >> Hi - >>=20 >> (new subject line, heeding Bert's plea) >>=20 >>> From: "Kent Watsen" >>> To: "Phil Shafer" >>> Cc: >>> Sent: Tuesday, August 21, 2012 10:26 AM >>> Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - = respondBEFORE Sept 1st >>>=20 >>>=20 >>> On 8/21/12 10:42 AM, "Phil Shafer" wrote: >>>=20 >>>> Kent Watsen writes: >>>>> To me, ephemeral configuration is *config* that either goes to a = special >>>>> datastore or to the "running" datastore with an XML-attribute = indicating >>>>> that it's ephemeral. >>>>=20 >>>> I have a hard time using the term "config" for a route learned via >>>> BGP or an address learned via DHCP. This will be hopelessly >>>> confusing to modelers and reviewers. >>>=20 >>> Agreed. My use of ephemeral config wasn't intended to cover what's >>> learned from within protocols, which seems more like "operational = state" >>> as far as NETCONF is concerned. >>>=20 >>> I liked very much what Alex wrote yesterday: >>>=20 >>> At the end of the day, what is important is who "owns" the data, = i.e. >>> Where >>> it originates from - an external app or the managed system - this is = what >>> I >>> think the operational / config data distinction ultimately refers to >>> (making >>> "operational" somewhat of a misnomer) - and whether the data is >>> "transient" >>> or "persistent", which could be covered by the notion of different = data >>> stores. >>=20 >> While that distinction is useful, more is needed, and it goes beyond >> ownership. It goes beyond whether a particular bit of data is >> writeable or even persistent. I think the first question is: >>=20 >> (1) is it something that would make sense in *versioned* >> configuration data? That is, if the value is changed, it's >> really a different configuration, from a configuration >> management perspective. >>=20 >> This begs a second question: >>=20 >> (2) The flip side of this is that there may be knobs that can be >> twiddled, but which in a sense don't constitute a change to >> a system's configuration. >>=20 >> While (1) is likely to be persistent, it doesn't have to be. = Consider >> portions of a system's configuration delivered by other protocols - >> the mechanism for the persistence may lie outside the box. Likewise, >> (2) may include persistent post-it notes whose semantics put them >> outside the scope of (1). For example, a "Joe is monitoring this >> interface" post-it should probably be persistent across re-boots, >> but probably should not be considered as part of versioned >> configuration data. >>=20 >> There are also the knobs that *do* things, but that we probably don't >> want to make persistent. For example, consider knobs on ephemeral >> objects like connections, or the route ontogenesis. >>=20 >> Where does this all lead? It leads me to the conclusion that >> the persistence and +/- config of a piece of "configuration" >> are distinct aspects, and that the current approach which >> tends to mingle these will become increasingly problematic. >> With the historic management protocols, this would be purely >> a modeling issue, but the design of netconf makes it a >> protocol issue as well. Good luck. >=20 > I like the 'config comment' tagging example. > Not only is config=3Dfalse fuzzy, but so it config=3Dtrue. > We have work to do. ;-) >=20 > Back in 2007, I thought the 3rd state (tconfig) was just like > config except save-to-nvstore skipped this data. Transient > config can be added or deleted by the client or server, but > it was only part of the running config, never the startup config. >=20 > Now I think this implementation was too simplistic, > at least from a modeling perspective. It would be nice to get > both the model and the implementation correct. > The former is a much more subjective decision. >=20 >=20 >>=20 >> Randy >=20 > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 --Apple-Mail=_11FBF5CB-198C-4CD7-8F9B-735CE0206DBE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii the set of = orders coming from the owner/commander of the system". Alex and Kent = said something similar "At the end of the day, what is important is = who "owns" the data, i.e. Where it originates = from."

The truth is that with this = definition, the set of objects that constitute the configuration = evolves over time, and it varies with the use case. I think this is = shown by the list of examples above. This makes me wonder if this = is (only) a modeling issue. A single model declaring an element to = be config or not, can't cover all use cases, current and future. Even = adding some middle state(s) to the single model won't help really. = Whatever you do here will only reflect the truth for a specific set of = use cases. Whether an element is treated as config or not by a manager = varies with the use case, and they vary over = time.

In many use cases (at least the = ones I selected above) I think the behavioral evolution can be = summarized with: delegation.

A manager = delegates certain aspects (elements) of the configuration to a = sub-manager (protocol, mechanism). When that happens, the manager is no = longer interested in viewing the sub-managed aspects as part of the = (main) configuration. Those elements should no longer be visible in = <get-config>, but in <get>. They should no longer be = included in backup or rollback files visible to the manager. They should = no longer be affected by a <lock> operation performed by the main = manager. =46rom the manager's perspective, this is now operational = data. 

For the sub-manager, these elements = should be treated as configuration. They should be visible in = <get-config>, modified by <edit-config>, affected by a = <lock> performed by the sub-manager. The sub-manager should not = see the main part of the configuration, at least not be able to modify = it.

=46rom the network element's perspective, = lowest of them all, the set of configurable elements is fixed. It is = whatever the device offers to its managers, delegated or not. It is = still called running.

So is the way to tackle = the evolution of config true/false adding some <delegate> = operation(s) to NETCONF?


Maybe = not. 

Looking at the delegation concept = more closely, I notice that this resembles the semantics of a role based = access control system, implemented to its fullest. Could the main = manager define access control rules that limits its own view of the = configuration, turning some areas into (read-only) operational data? = Could these rules limit the power of <lock> to not include items = that the main manager cannot touch? Could the main manager configure a = role for a sub-manager, such that the sub-manager can view and modify = the parts the main manager = delegates?


/Jan
janl@tail-f.com, +46 = 702855728
Principal Solutions Architect, Tail-f Systems, www.tail-f.com




On 22 aug 2012, at 17:09, Andy Bierman <andy@yumaworks.com> = wrote:

On Tue, Aug 21, 2012 at 4:46 PM, Randy Presuhn
<randy_presuhn@mindspring.com<= /a>> wrote:
Hi -

(new subject = line, heeding Bert's plea)

From: "Kent = Watsen" <kwatsen@juniper.net>
To: = "Phil Shafer" <phil@juniper.net>
Cc: <netconf@ietf.org>
Sent: = Tuesday, August 21, 2012 10:26 AM
Subject: Re: [Netconf] New WGLC for = a proposed new WG Charter - respondBEFORE Sept 1st


On 8/21/12 = 10:42 AM, "Phil Shafer" <phil@juniper.net> = wrote:

Kent Watsen = writes:
To me, ephemeral configuration is = *config* that either goes to a special
datastore or to the "running" = datastore with an XML-attribute indicating
that it's = ephemeral.

I have a hard time using the term = "config" for a route learned via
BGP or an address learned via DHCP. =  This will be hopelessly
confusing to modelers and = reviewers.

Agreed.  My use of ephemeral config = wasn't intended to cover what's
learned from within protocols, which = seems more like "operational state"
as far as NETCONF is = concerned.

I liked very much what Alex wrote yesterday:

At = the end of the day, what is important is who "owns" the data, = i.e.
Where
it originates from - an external app or the managed = system - this is what
I
think the operational / config data = distinction ultimately refers to
(making
"operational" somewhat of = a misnomer) - and whether the data is
"transient"
or "persistent", = which could be covered by the notion of different = data
stores.

While that distinction is useful, = more is needed, and it goes beyond
ownership.  It goes beyond = whether a particular bit of data is
writeable or even persistent. =  I think the first question is:

  (1) is it = something that would make sense in *versioned*
=         configuration data? =  That is, if the value is changed, it's
=         really a different = configuration, from a configuration
=         management = perspective.

This begs a second question:

  (2) = The flip side of this is that there may be knobs that can be
=         twiddled, but which in a = sense don't constitute a change to
=         a system's = configuration.

While (1) is likely to be persistent, it doesn't = have to be.  Consider
portions of a system's configuration = delivered by other protocols -
the mechanism for the persistence may = lie outside the box.  Likewise,
(2) may include persistent = post-it notes whose semantics put them
outside the scope of (1). =  For example, a "Joe is monitoring this
interface" post-it = should probably be persistent across re-boots,
but probably should = not be considered as part of versioned
configuration = data.

There are also the knobs that *do* things, but that we = probably don't
want to make persistent.  For example, consider = knobs on ephemeral
objects like connections, or the route = ontogenesis.

Where does this all lead?  It leads me to the = conclusion that
the persistence and +/- config of a piece of = "configuration"
are distinct aspects, and that the current approach = which
tends to mingle these will become increasingly = problematic.
With the historic management protocols, this would be = purely
a modeling issue, but the design of netconf makes it = a
protocol issue as well.  Good luck.

I like = the 'config comment' tagging example.
Not only is config=3Dfalse = fuzzy, but so it config=3Dtrue.
We have work to do. ;-)

Back = in 2007, I thought the 3rd state (tconfig) was just like
config = except save-to-nvstore skipped this data.  Transient
config can = be added or deleted by the client or server, but
it was only part of = the running config, never the startup config.

Now I think this = implementation was too simplistic,
at least from a modeling = perspective. It would be nice to get
both the model and the = implementation correct.
The former is a much more subjective = decision.



Randy

Andy
______________________= _________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.= org/mailman/listinfo/netconf


= --Apple-Mail=_11FBF5CB-198C-4CD7-8F9B-735CE0206DBE-- From j.schoenwaelder@jacobs-university.de Sun Aug 26 14:23:08 2012 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 074EA21F8471 for ; Sun, 26 Aug 2012 14:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.702 X-Spam-Level: X-Spam-Status: No, score=-101.702 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_40=-0.185, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66y0ube2KTzZ for ; Sun, 26 Aug 2012 14:23:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9221F845D for ; Sun, 26 Aug 2012 14:23:06 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36FAB20C2C; Sun, 26 Aug 2012 23:23:05 +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 d6zlYQB4EcUe; Sun, 26 Aug 2012 23:23:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9EBEB20C5D; Sun, 26 Aug 2012 23:23:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B88CB213DFFB; Sun, 26 Aug 2012 23:23:04 +0200 (CEST) Date: Sun, 26 Aug 2012 23:23:04 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20120826212304.GA7642@elstar.local> Mail-Followup-To: "t.petch" , Martin Bjorklund , netconf@ietf.org References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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: Sun, 26 Aug 2012 21:23:08 -0000 On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: > I prefer 'ephemeral configuration' to operational state, since we > have resolutely stated for 10 years than state is read only whereas > configuration is written, so now to have writable state seems a > bigger somersault than to have ephemeral configuration. I do not know why you believe that state is necessarily read only. RFC 6244 has some material in sections 4.3 and 4.4. The recommendation given in section 4.4. is not really workable, as we find out working on real data models in NETMOD. The first issue is that there is no standard way to retrieve operational state other than duplicating large parts of the data models, which seems costly and counter intuitive to modelers (who tend to put config false objects next to config true objects). The get() operation gives you a blend of operational state and configuration state with the result that the data is useless when it overlaps. I personally consider the get() operation somewhat broken and useless because of this. Sure, we can test that we got interoperable implementations of get() and make NETCONF a standard, the practical value of this however remains small. For me, something like get-operational is really a needed bug fix. The second issues is support for writable non-config / ephemeral / control / ... layers or datastores or whatever. This is about adding a new feature NETCONF currently does not have. This is harder to get right and after the side discussions in Vancouver I am also not sure we understand yet how this would work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From pgili@cisco.com Sun Aug 26 14:47:26 2012 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 322A221F8597 for ; Sun, 26 Aug 2012 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9itgwnmg01n for ; Sun, 26 Aug 2012 14:47:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 11F8021F8566 for ; Sun, 26 Aug 2012 14:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgili@cisco.com; l=5512; q=dns/txt; s=iport; t=1346017645; x=1347227245; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J3Zws2P4JB6xTCEZxS1eObJKmX8I1ldyKaELRJipMyw=; b=ZWhMTEIMnXqrWAr71sj+fh94dhB3LdT8zL+rTjipJeV9kimk5b5Fiq8P cXUqF8wXuJonAuEjq4V+WGsxjJNE8hPi7Y8AefWkf9XSUgi+H6SRg5JWp d1ltSn3vIaQPIkzdbJFDr+ISOQzx8uTHhdUkV4FMGpexaBMBsjlNdJbtf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOuXOlCtJXG+/2dsb2JhbABCA7ptgQeCIAEBAQMBAQEBDwEnNAsFBwICAgEIDgIBBAEBCxQJBxsMCxQJCAIEAQ0FCBqHZQYLmw+fLASLBBSDXIJBYAOkA4FngmOBWA X-IronPort-AV: E=Sophos;i="4.80,316,1344211200"; d="scan'208";a="115441759" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 26 Aug 2012 21:47:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7QLlM2f002482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Aug 2012 21:47:22 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.192]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Sun, 26 Aug 2012 16:47:22 -0500 From: "Patrick Gili (pgili)" To: Juergen Schoenwaelder , "t.petch" Thread-Topic: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st Thread-Index: AQHNg9D/V8mgf629X02IyZ0Di2uzoZdsmsQw Date: Sun, 26 Aug 2012 21:47:21 +0000 Message-ID: <50E64ADF99EAEE4CACEC18958F0FC0AB04B467@xmb-aln-x14.cisco.com> References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> In-Reply-To: <20120826212304.GA7642@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19140.001 x-tm-as-result: No--45.397600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 26 Aug 2012 21:47:26 -0000 I think some of the confusion we are experiencing has a lot to do with term= inology. In the past, we have traditionally only concerned ourselves with two types = of data: 1) Configuration data, which when modified transforms the operational state= of the device. It is worth noting that we have always limited to the scope= of what can modify this data to management interfaces, such as CLI, SNMP, = and NETCONF. 2) Operation data, which is strictly limited to read-only state, such as ro= utes learned by protocols (e.g., BGP) and statistics (to name of few types = of operational data). YANG adequately models these types of data. However, the evolution of feature sets over the last decade have blurred th= e lines between configuration and operational data. For example, during aut= hentication of a subscriber session, a device may receive a policy that it = needs to apply to the subscriber session. Typically, a policy consists of c= onfiguration data; however, we do not consider the policy pushed by the RAD= IUS server, because a management interface cannot change the policy and the= device will not persist the policy when an actor saves the running datasto= re to the startup datastore. On the other hand, if I invoke a command from = the device's console to list all the policies configured on the device, it = is desirable to see the policy pushed by the RADIUS server in the same list= as any other policy configured through a management interface. While some = vendors provide separate commands for this purpose, it has been determined = through experience that this is a pain point for operators and technicians. Drive this evolution one step further and we are at the brink of SDN. One a= pplicable example that comes to mind is a particular service provider (that= I won't name) that wants to eliminate RADIUS and push policy (and other co= nfiguration) using NETCONF. In this example, they want to configure the pol= icy and apply it to the subscriber session in a manner no different than if= I was sitting at a console doing it manually. However, there are slight di= fferences: 1) This configuration can never persist. 2) This configuration ideally should revert when the subscriber session ter= minates. The reversion criteria I have spelled out here are particular to t= he example, but in general, the client that created the configuration shoul= d be able to specify reversion criteria, when met causes the device to reve= rt the configuration. 3) There should exist a layered model of configuration that supports the ov= erride of lower priority configuration. At the bottom of this layer, we hav= e what we all know today as the running datastore. The layers above this re= present transient configuration applied according to the priority of the la= yer. We are referring to this as transient configuration and keep it separate fr= om the notion of "ephemeral configuration", which traditionally includes co= nfiguration inside the notion of the set of operational data created and ma= intained by mechanisms other than management interfaces, such as routing pr= otocols, DHCP, AAA, etc. -Patrick Gili -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Juergen Schoenwaelder Sent: Sunday, August 26, 2012 5:23 PM To: t.petch Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFO= RE Sept 1st On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: =20 > I prefer 'ephemeral configuration' to operational state, since we have=20 > resolutely stated for 10 years than state is read only whereas=20 > configuration is written, so now to have writable state seems a bigger=20 > somersault than to have ephemeral configuration. I do not know why you believe that state is necessarily read only. RFC 6244 has some material in sections 4.3 and 4.4. The recommendation given in= section 4.4. is not really workable, as we find out working on real data m= odels in NETMOD. The first issue is that there is no standard way to retrieve operational st= ate other than duplicating large parts of the data models, which seems cost= ly and counter intuitive to modelers (who tend to put config false objects = next to config true objects). The get() operation gives you a blend of oper= ational state and configuration state with the result that the data is usel= ess when it overlaps. I personally consider the get() operation somewhat b= roken and useless because of this. Sure, we can test that we got interopera= ble implementations of get() and make NETCONF a standard, the practical val= ue of this however remains small. For me, something like get-operational is= really a needed bug fix. The second issues is support for writable non-config / ephemeral / control = / ... layers or datastores or whatever. This is about adding a new feature = NETCONF currently does not have. This is harder to get right and after the = side discussions in Vancouver I am also not sure we understand yet how this= would work. /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 ietfc@btconnect.com Tue Aug 28 08:50:31 2012 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 3521C21F852D for ; Tue, 28 Aug 2012 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJLI944sFbns for ; Tue, 28 Aug 2012 08:50:30 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id AAC7021F851C for ; Tue, 28 Aug 2012 08:50:29 -0700 (PDT) Received: from mail25-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 Aug 2012 15:50:28 +0000 Received: from mail25-db3 (localhost [127.0.0.1]) by mail25-db3-R.bigfish.com (Postfix) with ESMTP id 301D74C00E8; Tue, 28 Aug 2012 15:50:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: PS-29(zz98dI9371I542M1432Ic1dMzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l1155h) Received: from mail25-db3 (localhost.localdomain [127.0.0.1]) by mail25-db3 (MessageSwitch) id 1346169026156649_1181; Tue, 28 Aug 2012 15:50:26 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.230]) by mail25-db3.bigfish.com (Postfix) with ESMTP id 22EA5260045; Tue, 28 Aug 2012 15:50:26 +0000 (UTC) Received: from DB3PRD0702HT004.eurprd07.prod.outlook.com (157.55.224.141) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 Aug 2012 15:50:23 +0000 Received: from AMSPRD0310HT001.eurprd03.prod.outlook.com (157.56.248.5) by pod51017.outlook.com (10.3.4.154) with Microsoft SMTP Server (TLS) id 14.15.108.4; Tue, 28 Aug 2012 15:50:23 +0000 Message-ID: <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> Date: Tue, 28 Aug 2012 16:44:44 +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.248.5] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] New WGLC for a proposed new WG Charter - respondBEFORE Sept 1st 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, 28 Aug 2012 15:50:31 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "t.petch" Cc: "Martin Bjorklund" ; Sent: Sunday, August 26, 2012 10:23 PM > On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: > > > I prefer 'ephemeral configuration' to operational state, since we > > have resolutely stated for 10 years than state is read only whereas > > configuration is written, so now to have writable state seems a > > bigger somersault than to have ephemeral configuration. > > I do not know why you believe that state is necessarily read only. Because most of what we have produced says so:-( and what we have produced reflects the discussions on the list). I remain unconvinced about the concept of operational state, that it is a meaningful concept. Reading what the operators asked for in RFC3535, "Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols." I always think of the routing table and think that that is by-and-large a unique, if very common, problem and that trying to extrapolate from the routing table to all the other data in a box is not helpful - there is nothing else like a routing table. The ARP cache has some similarities but is much simpler; MPLS FECs may be the other example. A separate problem is the interface up/down. An operator has configured an interface as up and the box says down, because it knows best - the line card just blew a fuse. This does have parallels elsewhere, with DHCP, and may be worth generalising but has little conceptually in common with routing tables IMO. Statistics are different in other ways. Read only, but only sort of; it is valuable to have a reset, so that counters may go to zero at midnight or some such. SMI recognised statistics as different with Counters and that was good to have. It struggled with the sheer volume of data - I once set a MIB walk going on the RMONMIB and if I had not shut the box down after several days, it would probably still be going some years later. But I see nothing in common with the routing table problem and the interface status problem, just how to get meaningful information from masses of raw data, ie do the maths in the box and ship out the summary - and SMI did look at that but it did not seem to catch on. Tom Petch RFC > 6244 has some material in sections 4.3 and 4.4. The recommendation > given in section 4.4. is not really workable, as we find out working > on real data models in NETMOD. > > The first issue is that there is no standard way to retrieve > operational state other than duplicating large parts of the data > models, which seems costly and counter intuitive to modelers (who tend > to put config false objects next to config true objects). The get() > operation gives you a blend of operational state and configuration > state with the result that the data is useless when it overlaps. I > personally consider the get() operation somewhat broken and useless > because of this. Sure, we can test that we got interoperable > implementations of get() and make NETCONF a standard, the practical > value of this however remains small. For me, something like > get-operational is really a needed bug fix. > > The second issues is support for writable non-config / ephemeral / > control / ... layers or datastores or whatever. This is about adding a > new feature NETCONF currently does not have. This is harder to get > right and after the side discussions in Vancouver I am also not sure > we understand yet how this would work. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From lhotka@nic.cz Wed Aug 29 02:13:34 2012 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 5207621F8493 for ; Wed, 29 Aug 2012 02:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZHb34VD41+3 for ; Wed, 29 Aug 2012 02:13:33 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 50AEC21F8578 for ; Wed, 29 Aug 2012 02:13:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C4D525403DE; Wed, 29 Aug 2012 11:13:18 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTf8x6e3902s; Wed, 29 Aug 2012 11:13:11 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 105A25401E6; Wed, 29 Aug 2012 11:13:09 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , Juergen Schoenwaelder In-Reply-To: <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Wed, 29 Aug 2012 11:13:08 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] operational state (WAS: New WGLC for a proposed new WG Charter ...) 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, 29 Aug 2012 09:13:34 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "t.petch" > Cc: "Martin Bjorklund" ; > Sent: Sunday, August 26, 2012 10:23 PM >> On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: >> >> > I prefer 'ephemeral configuration' to operational state, since we >> > have resolutely stated for 10 years than state is read only whereas >> > configuration is written, so now to have writable state seems a >> > bigger somersault than to have ephemeral configuration. >> >> I do not know why you believe that state is necessarily read only. > > Because most of what we have produced says so:-( and what we have > produced reflects the discussions on the list). > > I remain unconvinced about the concept of operational state, that it > is a meaningful concept. Reading what the operators asked for in It is difficult to argue about these concepts without having their definintion. These premises make sense to me though: 1. Each device has a set of system parameters/structures that *directly* influence the device behaviour, no matter how they were set (operator action, factory default, protocol, ...). I'd suggest to define this set as the "operational state" of the device. Operators need to be able to have one or more interfaces for viewing (a subset of) this set. 2. In order to be able to control the device, operators need an interface for specifying their instructions for intended changes to the operational state and, consequently, device behaviour. I'd suggest to call these instructions a configuration. The device takes a submitted configuration and applies it according to a certain algorithm depending on the configuration, active network protocols, built-in policies etc. Examples of configuration interfaces are: - NETCONF (or CLI), where the operator's instructions have to be installed as the "running configuration". - Unix init scripts, where the instructions are essentially shell scripts. - RESTful interface, where the operational state is exposed as a set of resources and some of them may be modified via HTTP methods. Of course, the hard part is to define the relationship and interactions between a configuration and operational state. In the simplest case, a configuration parameter directly maps to an operational state parameter - the device may accept the configured value or not. But there are also more complicated mappings, e.g.: - One configuration parameter may disable a subsystem, i.e. a subtree in operational state. - A list of configured entries get merged to a larger list which is a part of the operational state. An example is the routing table that contains static routes (= configuration) as well as routes learnt from routing protocols. > RFC3535, > "Some devices make it very hard to determine > which parameters were administratively configured and which > were obtained via other mechanisms such as routing > protocols." > I always think of the routing table and think that that is by-and-large > a unique, if very common, problem and that trying to extrapolate from > the routing table to all the other data in a box is not helpful - there > is > nothing else like a routing table. The ARP cache has some similarities > but is much simpler; MPLS FECs may be the other example. > > A separate problem is the interface up/down. An operator has configured > an interface as up and the box says down, because it knows best - the > line > card just blew a fuse. This does have parallels elsewhere, with DHCP, > and may be worth generalising but has little conceptually in common > with routing tables IMO. Right, so the operator gave an instruction/request but the device knows better and doesn't accept it: the up/down parameter in operational state remains down. > > Statistics are different in other ways. Read only, but only sort of; it I think that statistics should be put aside and not considered a part of operational state - at least for the purpose of this discussion. Lada > is > valuable to have a reset, so that counters may go to zero at midnight > or some such. SMI recognised statistics as different with Counters > and that was good to have. It struggled with the sheer volume of data - > I once set a MIB walk going on the RMONMIB and if I had not shut > the box down after several days, it would probably still be going some > years later. But I see nothing in common with the routing table problem > and the interface status problem, just how to get meaningful information > from masses of raw data, ie do the maths in the box and ship out the > summary - and SMI did look at that but it did not seem > to catch on. > > Tom Petch > > > RFC >> 6244 has some material in sections 4.3 and 4.4. The recommendation >> given in section 4.4. is not really workable, as we find out working >> on real data models in NETMOD. >> >> The first issue is that there is no standard way to retrieve >> operational state other than duplicating large parts of the data >> models, which seems costly and counter intuitive to modelers (who tend >> to put config false objects next to config true objects). The get() >> operation gives you a blend of operational state and configurat -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Wed Aug 29 03:08:04 2012 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 BEF3521F84C8 for ; Wed, 29 Aug 2012 03:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.363 X-Spam-Level: X-Spam-Status: No, score=-102.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrSNIhpysl2R for ; Wed, 29 Aug 2012 03:08:04 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C727A21F84B3 for ; Wed, 29 Aug 2012 03:08:03 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T6fBp-00050y-0F for netconf@ietf.org; Wed, 29 Aug 2012 12:08:02 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T6fBo-0003i0-Qe for netconf@ietf.org; Wed, 29 Aug 2012 12:08:00 +0200 Message-ID: <503DEA00.1030509@bwijnen.net> Date: Wed, 29 Aug 2012 12:08:00 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Netconf References: <502D7052.2070302@bwijnen.net> In-Reply-To: <502D7052.2070302@bwijnen.net> X-Forwarded-Message-Id: <502D7052.2070302@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120829 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4c03b3f59c52e8a52215fc8c148482656 Subject: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 10:08:04 -0000 Mmm... as far as I can determine, only ONE person has expressed a clear YES I SUPPORT statement. Others have diverged again into discussing "operational-state". Good discussion, but not what we were trying to get consensus on. Please express your SUPPORT or OBJECTION to the simple and easy charter below. It is a short-term charter with work items that we (seem) to have agreed on. Additional/other work (on which we have no consensus for the exact direction yet) can be brought to the WG in a normal manner via submitting individual I-Ds and getting the WG to discuss it. We can then later add that to the charter of we find that the WG is indeed interested in working on such things. For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT Bert -------- Original Message -------- Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st Date: Fri, 17 Aug 2012 00:12:34 +0200 From: Bert Wijnen (IETF) To: netconf Based on the comments and feedback and the positions expressed on the mailing list, it is clear that after all we did NOT have consensus on the new WG charter. Without further ado, this is another proposed WG charter. It focuses on the things that we do seme to have agreement on. Pls comment and/or express your support or objections no later than August 31, 2012. OK, new chapter text (omitting the description of what we have achieved sofar): In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. This means that RFC5593 needs to be updated. 2. Based on the implementation, deployment experience and interoperability testing, the WG will document the status of NETCONF in a report. Based on this, the WG may decide to make some clarifications to RFC6241 and RFC6242 (then also fixing any reported errata). 3. Since Netconf over BEEP and over SOAP seem not being deployed the WG will write a document that makes those 2 protocols (RFC4743 and RFC4744) HISTORIC. Goals and Milestones: done - Send with-defaults to IESG for consideration as Proposed Standard done - WG Last Call on rfc4741bis 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 NACM posted 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 Aug 2012 - submit initial WG draft for rfc5539bis Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. Sep 2012 - WGLC for rfc5539bis Sep 2012 - WGLC for RFC4743 and 4743 to historic Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc to IESG for publication as Informational RFC. Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG Bert and Mehmet From dromasca@avaya.com Wed Aug 29 03:09:33 2012 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 2C3E421F8618 for ; Wed, 29 Aug 2012 03:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JI+XXWEN44Q3 for ; Wed, 29 Aug 2012 03:09:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EE3AF21F8581 for ; Wed, 29 Aug 2012 03:09:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABTqPVCHCzI1/2dsb2JhbABFum+BB4IgAQEBAQMBAQEPHgo0FwQCAQgNBAMBAQELBgwHBAEGASYfCQgBAQQBEggah2sLngadLwSLCIV5YAObVIoXgmU X-IronPort-AV: E=Sophos;i="4.80,333,1344225600"; d="scan'208";a="321719595" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Aug 2012 06:05:39 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 29 Aug 2012 05:48:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2012 12:09:09 +0200 Message-ID: In-Reply-To: <503DEA00.1030509@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st Thread-Index: Ac2FzjDqpEi3l43dTqyStewQ9qcmgAAAB0rQ References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert Wijnen (IETF)" , "Netconf" Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 10:09:33 -0000 YES I SUPPORT Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Bert Wijnen (IETF) > Sent: Wednesday, August 29, 2012 1:08 PM > To: Netconf > Subject: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed > new WG Charter - respond BEFORE Sept 1st >=20 > Mmm... as far as I can determine, only ONE person has expressed a clear > YES I SUPPORT statement. > Others have diverged again into discussing "operational-state". > Good discussion, but not what we were trying to get consensus on. >=20 > Please express your SUPPORT or OBJECTION to the simple and easy charter > below. It is a short-term charter with work items that we (seem) to have > agreed on. >=20 > Additional/other work (on which we have no consensus for the exact > direction yet) can be brought to the WG in a normal manner via > submitting individual I-Ds and getting the WG to discuss it. > We can then later add that to the charter of we find that the WG is > indeed interested in working on such things. >=20 > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT >=20 > Bert >=20 >=20 > -------- Original Message -------- > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond > BEFORE Sept 1st > Date: Fri, 17 Aug 2012 00:12:34 +0200 > From: Bert Wijnen (IETF) > To: netconf >=20 >=20 > Based on the comments and feedback and the positions expressed on the > mailing list, it is clear that after all we did NOT have consensus on > the new WG charter. >=20 > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. >=20 > Pls comment and/or express your support or objections no later than > August 31, 2012. >=20 > OK, new chapter text (omitting the description of what we have achieved > sofar): >=20 > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: >=20 > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. >=20 > 2. Based on the implementation, deployment experience and > interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). >=20 > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. >=20 > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed > Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed > Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 > historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and > 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience > doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or > close WG >=20 > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Wed Aug 29 03:25:06 2012 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 07F9121F84A6 for ; Wed, 29 Aug 2012 03:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.201 X-Spam-Level: X-Spam-Status: No, score=-103.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OEHCjzEpQk8 for ; Wed, 29 Aug 2012 03:25:03 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id DF78821F8493 for ; Wed, 29 Aug 2012 03:25:02 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2770420CE1; Wed, 29 Aug 2012 12:25:01 +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 1s8WV37zbxFU; Wed, 29 Aug 2012 12:25:01 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B2AB20C84; Wed, 29 Aug 2012 12:25:00 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CDD68214A8D7; Wed, 29 Aug 2012 12:24:54 +0200 (CEST) Date: Wed, 29 Aug 2012 12:24:54 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20120829102454.GB3868@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503DEA00.1030509@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Netconf Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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: Wed, 29 Aug 2012 10:25:06 -0000 Hi, I am kind of OK with this although I am not sure we really need to have RFC6241/6242 implementation/deployment experience published as an informational RFC. Even if we decide in Nov/Dec to advance, this does not seem to be required (when we moved some of the ISMS documents to Draft Standard, having an I-D was good enough). But charters can be changed and I hope that we get to a clearer consensus what to do and what not to do in Nov/Dec. /js On Wed, Aug 29, 2012 at 12:08:00PM +0200, Bert Wijnen (IETF) wrote: > Mmm... as far as I can determine, only ONE person has expressed > a clear YES I SUPPORT statement. > Others have diverged again into discussing "operational-state". > Good discussion, but not what we were trying to get consensus on. > > Please express your SUPPORT or OBJECTION to the simple and > easy charter below. It is a short-term charter with work items > that we (seem) to have agreed on. > > Additional/other work (on which we have no consensus for the > exact direction yet) can be brought to the WG in a normal manner > via submitting individual I-Ds and getting the WG to discuss it. > We can then later add that to the charter of we find that the > WG is indeed interested in working on such things. > > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT > > Bert > > > -------- Original Message -------- > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st > Date: Fri, 17 Aug 2012 00:12:34 +0200 > From: Bert Wijnen (IETF) > To: netconf > > > Based on the comments and feedback and the positions > expressed on the mailing list, it is clear that after all > we did NOT have consensus on the new WG charter. > > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. > > Pls comment and/or express your support or objections > no later than August 31, 2012. > > OK, new chapter text (omitting the description of what we have > achieved sofar): > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. Based on the implementation, deployment experience and interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG > > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Aug 29 03:32:27 2012 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 AE90F21F85AF for ; Wed, 29 Aug 2012 03:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZgZpuT2YN1K for ; Wed, 29 Aug 2012 03:32:26 -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 7CACF21F8621 for ; Wed, 29 Aug 2012 03:32:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 94D541200AE5; Wed, 29 Aug 2012 12:32:24 +0200 (CEST) Date: Wed, 29 Aug 2012 12:32:24 +0200 (CEST) Message-Id: <20120829.123224.1567739347586295411.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20120829102454.GB3868@elstar.local> References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> <20120829102454.GB3868@elstar.local> X-Mailer: Mew version 6.4 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 10:32:27 -0000 Juergen Schoenwaelder wrote: > Hi, > > I am kind of OK with this although I am not sure we really need to > have RFC6241/6242 implementation/deployment experience published as an > informational RFC. +1 /martin Even if we decide in Nov/Dec to advance, this does > not seem to be required (when we moved some of the ISMS documents to > Draft Standard, having an I-D was good enough). > > But charters can be changed and I hope that we get to a clearer > consensus what to do and what not to do in Nov/Dec. > > /js > > On Wed, Aug 29, 2012 at 12:08:00PM +0200, Bert Wijnen (IETF) wrote: > > Mmm... as far as I can determine, only ONE person has expressed > > a clear YES I SUPPORT statement. > > Others have diverged again into discussing "operational-state". > > Good discussion, but not what we were trying to get consensus on. > > > > Please express your SUPPORT or OBJECTION to the simple and > > easy charter below. It is a short-term charter with work items > > that we (seem) to have agreed on. > > > > Additional/other work (on which we have no consensus for the > > exact direction yet) can be brought to the WG in a normal manner > > via submitting individual I-Ds and getting the WG to discuss it. > > We can then later add that to the charter of we find that the > > WG is indeed interested in working on such things. > > > > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT > > > > Bert > > > > > > -------- Original Message -------- > > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st > > Date: Fri, 17 Aug 2012 00:12:34 +0200 > > From: Bert Wijnen (IETF) > > To: netconf > > > > > > Based on the comments and feedback and the positions > > expressed on the mailing list, it is clear that after all > > we did NOT have consensus on the new WG charter. > > > > Without further ado, this is another proposed WG charter. > > It focuses on the things that we do seme to have agreement on. > > > > Pls comment and/or express your support or objections > > no later than August 31, 2012. > > > > OK, new chapter text (omitting the description of what we have > > achieved sofar): > > > > In the current phase of the incremental development of NETCONF the > > workgroup will focus on following items: > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > This means that RFC5593 needs to be updated. > > > > 2. Based on the implementation, deployment experience and interoperability > > testing, the WG will document the status of NETCONF in a report. > > Based on this, the WG may decide to make some clarifications to > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > the WG will write a document that makes those 2 protocols > > (RFC4743 and RFC4744) HISTORIC. > > > > Goals and Milestones: > > done - Send with-defaults to IESG for consideration as Proposed Standard > > done - WG Last Call on rfc4741bis > > 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 NACM posted > > 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 > > Aug 2012 - submit initial WG draft for rfc5539bis > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 historic. > > Sep 2012 - WGLC for rfc5539bis > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed Standard > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment experience > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > > to IESG for publication as Informational RFC. > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close WG > > > > Bert and Mehmet > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > 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 dromasca@avaya.com Wed Aug 29 03:33:33 2012 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 4525421F8606 for ; Wed, 29 Aug 2012 03:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z47G58eF2kgc for ; Wed, 29 Aug 2012 03:33:32 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id DC5B921F8604 for ; Wed, 29 Aug 2012 03:33:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOPuPVDGmAcF/2dsb2JhbABCA7pvgQeCIAEBAQEDAQEBDx4KNAsMAgICAQgNAQIBAwEBAQEKBgwHBAEGARoMHwkIAQEEARIIGodrC54bnTEEiwSDOIJBYAObVIoXgmU X-IronPort-AV: E=Sophos;i="4.80,333,1344225600"; d="scan'208";a="321722131" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 Aug 2012 06:29:57 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Aug 2012 06:27:25 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 29 Aug 2012 12:33:27 +0200 Message-ID: In-Reply-To: <20120829.123224.1567739347586295411.mbj@tail-f.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st Thread-Index: Ac2F0ZwAC4xFY98qRjmc1KAqfaqNIwAABWVw References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net><20120829102454.GB3868@elstar.local> <20120829.123224.1567739347586295411.mbj@tail-f.com> From: "Romascanu, Dan (Dan)" To: "Martin Bjorklund" , Cc: netconf@ietf.org Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 10:33:33 -0000 +1 Dan > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of Martin Bjorklund > Sent: Wednesday, August 29, 2012 1:32 PM > To: j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a > proposed new WG Charter - respond BEFORE Sept 1st >=20 > Juergen Schoenwaelder wrote: > > Hi, > > > > I am kind of OK with this although I am not sure we really need to > > have RFC6241/6242 implementation/deployment experience published as an > > informational RFC. >=20 > +1 >=20 >=20 > /martin >=20 >=20 >=20 > Even if we decide in Nov/Dec to advance, this does > > not seem to be required (when we moved some of the ISMS documents to > > Draft Standard, having an I-D was good enough). > > > > But charters can be changed and I hope that we get to a clearer > > consensus what to do and what not to do in Nov/Dec. > > > > /js > > > > On Wed, Aug 29, 2012 at 12:08:00PM +0200, Bert Wijnen (IETF) wrote: > > > Mmm... as far as I can determine, only ONE person has expressed a > > > clear YES I SUPPORT statement. > > > Others have diverged again into discussing "operational-state". > > > Good discussion, but not what we were trying to get consensus on. > > > > > > Please express your SUPPORT or OBJECTION to the simple and easy > > > charter below. It is a short-term charter with work items that we > > > (seem) to have agreed on. > > > > > > Additional/other work (on which we have no consensus for the exact > > > direction yet) can be brought to the WG in a normal manner via > > > submitting individual I-Ds and getting the WG to discuss it. > > > We can then later add that to the charter of we find that the WG is > > > indeed interested in working on such things. > > > > > > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT > > > > > > Bert > > > > > > > > > -------- Original Message -------- > > > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond > > > BEFORE Sept 1st > > > Date: Fri, 17 Aug 2012 00:12:34 +0200 > > > From: Bert Wijnen (IETF) > > > To: netconf > > > > > > > > > Based on the comments and feedback and the positions expressed on > > > the mailing list, it is clear that after all we did NOT have > > > consensus on the new WG charter. > > > > > > Without further ado, this is another proposed WG charter. > > > It focuses on the things that we do seme to have agreement on. > > > > > > Pls comment and/or express your support or objections no later than > > > August 31, 2012. > > > > > > OK, new chapter text (omitting the description of what we have > > > achieved sofar): > > > > > > In the current phase of the incremental development of NETCONF the > > > workgroup will focus on following items: > > > > > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > > > This means that RFC5593 needs to be updated. > > > > > > 2. Based on the implementation, deployment experience and > interoperability > > > testing, the WG will document the status of NETCONF in a > report. > > > Based on this, the WG may decide to make some clarifications to > > > RFC6241 and RFC6242 (then also fixing any reported errata). > > > > > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > > > the WG will write a document that makes those 2 protocols > > > (RFC4743 and RFC4744) HISTORIC. > > > > > > Goals and Milestones: > > > done - Send with-defaults to IESG for consideration as > Proposed Standard > > > done - WG Last Call on rfc4741bis > > > 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 NACM posted > > > 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 > > > Aug 2012 - submit initial WG draft for rfc5539bis > > > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > > > Sep 2012 - WGLC for rfc5539bis > > > Sep 2012 - WGLC for RFC4743 and 4743 to historic > > > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as > Proposed Standard > > > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 > historic > > > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 > and 6242 > > > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > > > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment > experience > > > Feb 2013 - submit RFC6241/6242 implementation/deployment > experience doc > > > to IESG for publication as Informational RFC. > > > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or > > > close WG > > > > > > Bert and Mehmet > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > -- > > 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 > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From andy@yumaworks.com Wed Aug 29 06:49:22 2012 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 444D611E809A for ; Wed, 29 Aug 2012 06:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWMlPSodSJn for ; Wed, 29 Aug 2012 06:49:21 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 062C311E808E for ; Wed, 29 Aug 2012 06:49:20 -0700 (PDT) Received: by qcac10 with SMTP id c10so425788qca.31 for ; Wed, 29 Aug 2012 06:49:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BqIDnKUSdhkRqPX9N51VN0jkq9sPQHTRkVs9Ws3YkFI=; b=nDNCsm/Pwe9oEQidQXqOli4vwMevbx4cwGkdARgYzNo2Uj2mrKVfwqOH/4FFfsVl1v AkOhiLIwo2LRbFbuf2XRe+l4SLb9ywGxGgy7I0eBxnDdgGzQ8GLzTOmBJrbAWz2RpPvo 1YW0ZnjV1MDTimXrT5H0zKMuBvD2KvGePxNmu5Yd2UenuFKTsELDkDoNWMbI2Sqyf2v4 tnA1S/HN7Y9KnlC3YiGPZ6gqhjp7bImGvDASKF/w5XvwYeeBliN6Jpzt6NpyzKOueaQD YiVX9UgrCoOUMkPYSUZOSjr/jUs4RNfAzXcFEFO9T2lqIil1obvWzbRbn5WOM8PW7AzP DlkQ== MIME-Version: 1.0 Received: by 10.229.134.200 with SMTP id k8mr803371qct.135.1346248160267; Wed, 29 Aug 2012 06:49:20 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 29 Aug 2012 06:49:20 -0700 (PDT) In-Reply-To: <503DEA00.1030509@bwijnen.net> References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> Date: Wed, 29 Aug 2012 06:49:20 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmqyp0UkxJ3Pj8dtJIarVKD0PP3K4SFdkNKf81shLUPc9aKRDStY98Dx7kl16/2lH9vV+9s Cc: Netconf Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 13:49:22 -0000 +0 I am neutral on this charter. When you say "support", does that mean the person is volunteering to review drafts, write drafts, participate in email discussions? Or does it mean you support the concept of the work item as long as somebody else does all the work? Please make sure you have the resources to do whatever work gets chartered. Andy On Wed, Aug 29, 2012 at 3:08 AM, Bert Wijnen (IETF) wrote: > Mmm... as far as I can determine, only ONE person has expressed > a clear YES I SUPPORT statement. > Others have diverged again into discussing "operational-state". > Good discussion, but not what we were trying to get consensus on. > > Please express your SUPPORT or OBJECTION to the simple and > easy charter below. It is a short-term charter with work items > that we (seem) to have agreed on. > > Additional/other work (on which we have no consensus for the > exact direction yet) can be brought to the WG in a normal manner > via submitting individual I-Ds and getting the WG to discuss it. > We can then later add that to the charter of we find that the > WG is indeed interested in working on such things. > > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT > > Bert > > > -------- Original Message -------- > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE > Sept 1st > Date: Fri, 17 Aug 2012 00:12:34 +0200 > From: Bert Wijnen (IETF) > To: netconf > > > Based on the comments and feedback and the positions > expressed on the mailing list, it is clear that after all > we did NOT have consensus on the new WG charter. > > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. > > Pls comment and/or express your support or objections > no later than August 31, 2012. > > OK, new chapter text (omitting the description of what we have > achieved sofar): > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. Based on the implementation, deployment experience and interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed > Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed > Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close > WG > > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From xiangli@seguesoft.com Wed Aug 29 07:15:40 2012 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 B481A21F8615 for ; Wed, 29 Aug 2012 07:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx6iiz590GX9 for ; Wed, 29 Aug 2012 07:15:39 -0700 (PDT) Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) by ietfa.amsl.com (Postfix) with SMTP id B05CB21F85AF for ; Wed, 29 Aug 2012 07:15:39 -0700 (PDT) Received: (qmail 11701 invoked from network); 29 Aug 2012 14:15:38 -0000 Received: from unknown (98.212.151.151) by p3plsmtpa07-07.prod.phx3.secureserver.net (173.201.192.236) with ESMTP; 29 Aug 2012 14:15:37 -0000 Message-ID: <503E2409.8070008@seguesoft.com> Date: Wed, 29 Aug 2012 09:15:37 -0500 From: Xiang Li User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: netconf@ietf.org References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> In-Reply-To: <503DEA00.1030509@bwijnen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 14:15:40 -0000 I support. On 8/29/2012 5:08 AM, Bert Wijnen (IETF) wrote: > Mmm... as far as I can determine, only ONE person has expressed > a clear YES I SUPPORT statement. > Others have diverged again into discussing "operational-state". > Good discussion, but not what we were trying to get consensus on. > > Please express your SUPPORT or OBJECTION to the simple and > easy charter below. It is a short-term charter with work items > that we (seem) to have agreed on. > > Additional/other work (on which we have no consensus for the > exact direction yet) can be brought to the WG in a normal manner > via submitting individual I-Ds and getting the WG to discuss it. > We can then later add that to the charter of we find that the > WG is indeed interested in working on such things. > > For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT > > Bert > > > -------- Original Message -------- > Subject: [Netconf] New WGLC for a proposed new WG Charter - respond > BEFORE Sept 1st > Date: Fri, 17 Aug 2012 00:12:34 +0200 > From: Bert Wijnen (IETF) > To: netconf > > > Based on the comments and feedback and the positions > expressed on the mailing list, it is clear that after all > we did NOT have consensus on the new WG charter. > > Without further ado, this is another proposed WG charter. > It focuses on the things that we do seme to have agreement on. > > Pls comment and/or express your support or objections > no later than August 31, 2012. > > OK, new chapter text (omitting the description of what we have > achieved sofar): > > In the current phase of the incremental development of NETCONF the > workgroup will focus on following items: > > 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. > This means that RFC5593 needs to be updated. > > 2. Based on the implementation, deployment experience and > interoperability > testing, the WG will document the status of NETCONF in a report. > Based on this, the WG may decide to make some clarifications to > RFC6241 and RFC6242 (then also fixing any reported errata). > > 3. Since Netconf over BEEP and over SOAP seem not being deployed > the WG will write a document that makes those 2 protocols > (RFC4743 and RFC4744) HISTORIC. > > Goals and Milestones: > done - Send with-defaults to IESG for consideration as Proposed > Standard > done - WG Last Call on rfc4741bis > 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 NACM posted > 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 > Aug 2012 - submit initial WG draft for rfc5539bis > Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 > historic. > Sep 2012 - WGLC for rfc5539bis > Sep 2012 - WGLC for RFC4743 and 4743 to historic > Oct 2012 - submit rfc5539bis to AD/IESG for consideration as > Proposed Standard > Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic > Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and > 6242 > Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment > experience > Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience > Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc > to IESG for publication as Informational RFC. > Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or > close WG > > Bert and Mehmet > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- -- Xiang Li Web: www.seguesoft.com Voice: 1 (872) 216-2610 From bertietf@bwijnen.net Wed Aug 29 07:17:02 2012 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 2C45821F8570 for ; Wed, 29 Aug 2012 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.371 X-Spam-Level: X-Spam-Status: No, score=-102.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqXy58FwotVO for ; Wed, 29 Aug 2012 07:17:01 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0543221F853E for ; Wed, 29 Aug 2012 07:17:01 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T6j4j-00064l-Q7; Wed, 29 Aug 2012 16:17:00 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T6j4j-0000mL-HR; Wed, 29 Aug 2012 16:16:57 +0200 Message-ID: <503E2459.6030605@bwijnen.net> Date: Wed, 29 Aug 2012 16:16:57 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Andy Bierman References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120829 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd41c9623caa8fd3278ce01b4d96e8b28e8 Cc: Netconf Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 14:17:02 -0000 inline On 8/29/12 3:49 PM, Andy Bierman wrote: > +0 > > I am neutral on this charter. > Thanks, that is fine > When you say "support", does that mean the person is volunteering > to review drafts, write drafts, participate in email discussions? > in principle, yes, that is what it means > Or does it mean you support the concept of the work item > as long as somebody else does all the work? > that too. We have however defined volunteers for the work items (or so I believe). Yes, we do expect WG participants to review any WG docs that get to WG LC. > Please make sure you have the resources to do whatever work > gets chartered. > I believe we do. You agreed to an interop event. Maybe not to the writeup? At the other hand, you earlier on agreed to advance 6241/42, which would mean documenting th eresults (maybe not as RFC). Bert > > Andy > > > On Wed, Aug 29, 2012 at 3:08 AM, Bert Wijnen (IETF) > wrote: >> Mmm... as far as I can determine, only ONE person has expressed >> a clear YES I SUPPORT statement. >> Others have diverged again into discussing "operational-state". >> Good discussion, but not what we were trying to get consensus on. >> >> Please express your SUPPORT or OBJECTION to the simple and >> easy charter below. It is a short-term charter with work items >> that we (seem) to have agreed on. >> >> Additional/other work (on which we have no consensus for the >> exact direction yet) can be brought to the WG in a normal manner >> via submitting individual I-Ds and getting the WG to discuss it. >> We can then later add that to the charter of we find that the >> WG is indeed interested in working on such things. >> >> For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT >> >> Bert >> >> >> -------- Original Message -------- >> Subject: [Netconf] New WGLC for a proposed new WG Charter - respond BEFORE >> Sept 1st >> Date: Fri, 17 Aug 2012 00:12:34 +0200 >> From: Bert Wijnen (IETF) >> To: netconf >> >> >> Based on the comments and feedback and the positions >> expressed on the mailing list, it is clear that after all >> we did NOT have consensus on the new WG charter. >> >> Without further ado, this is another proposed WG charter. >> It focuses on the things that we do seme to have agreement on. >> >> Pls comment and/or express your support or objections >> no later than August 31, 2012. >> >> OK, new chapter text (omitting the description of what we have >> achieved sofar): >> >> In the current phase of the incremental development of NETCONF the >> workgroup will focus on following items: >> >> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >> This means that RFC5593 needs to be updated. >> >> 2. Based on the implementation, deployment experience and interoperability >> testing, the WG will document the status of NETCONF in a report. >> Based on this, the WG may decide to make some clarifications to >> RFC6241 and RFC6242 (then also fixing any reported errata). >> >> 3. Since Netconf over BEEP and over SOAP seem not being deployed >> the WG will write a document that makes those 2 protocols >> (RFC4743 and RFC4744) HISTORIC. >> >> Goals and Milestones: >> done - Send with-defaults to IESG for consideration as Proposed >> Standard >> done - WG Last Call on rfc4741bis >> 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 NACM posted >> 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 >> Aug 2012 - submit initial WG draft for rfc5539bis >> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >> historic. >> Sep 2012 - WGLC for rfc5539bis >> Sep 2012 - WGLC for RFC4743 and 4743 to historic >> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed >> Standard >> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic >> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and 6242 >> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment >> experience >> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >> Feb 2013 - submit RFC6241/6242 implementation/deployment experience doc >> to IESG for publication as Informational RFC. >> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or close >> WG >> >> Bert and Mehmet >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From andy@yumaworks.com Wed Aug 29 07:22:04 2012 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 3230B21F85D5 for ; Wed, 29 Aug 2012 07:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4nZXQr35H+G for ; Wed, 29 Aug 2012 07:22:03 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4344421F85C4 for ; Wed, 29 Aug 2012 07:22:03 -0700 (PDT) Received: by qcac10 with SMTP id c10so457118qca.31 for ; Wed, 29 Aug 2012 07:22:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Z43DwkkjrKthaxjADH++OIeAUk+5tVBJVTtlgmUFruw=; b=CbPi7ZJy3iC1TETixbGLSfE9F9kDcjP5X7qL0O1Z1OQVyWGiU+RlJyS+AhH+nSaMOi qcVmJo3aIOPPiDaYV7z1YxFTPws128KmNI4BelAJLWTyuQRMIxcmXLiVh9AxkEOPp5SX pzaouYenJKH9fjH2VSkh7+lbX6Z4hplK7d45Q65GxZhnEmIzyooH2f6r3IXwdsicaWJ3 MlqZyZ+QX+ZbQRwDhY0Qe7OWyGeK29w122bY4N98cyePBLOw7D/6+3zM27w8+eYsCZJH LWEAA9B6fAEMeICTTeSHysF7ZNoS+PITTFcEhx0fHAMLVQKfBDH+c07slxPO6Oo6TAmk e/Xg== MIME-Version: 1.0 Received: by 10.224.77.13 with SMTP id e13mr3857292qak.68.1346250121836; Wed, 29 Aug 2012 07:22:01 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Wed, 29 Aug 2012 07:22:01 -0700 (PDT) In-Reply-To: <503E2459.6030605@bwijnen.net> References: <502D7052.2070302@bwijnen.net> <503DEA00.1030509@bwijnen.net> <503E2459.6030605@bwijnen.net> Date: Wed, 29 Aug 2012 07:22:01 -0700 Message-ID: From: Andy Bierman To: "Bert Wijnen (IETF)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnRjymkgv6cvtA48a9bOVh1+i0ES28W7HHCfEFC+WQJdBRBolSmpxNMmY07ny2nYMRh6qnY Cc: Netconf Subject: Re: [Netconf] REminder: deadline Aug 31st: New WGLC for a proposed new WG Charter - respond BEFORE Sept 1st 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, 29 Aug 2012 14:22:04 -0000 On Wed, Aug 29, 2012 at 7:16 AM, Bert Wijnen (IETF) wrote: > inline > > On 8/29/12 3:49 PM, Andy Bierman wrote: >> >> +0 >> >> I am neutral on this charter. >> > > Thanks, that is fine > >> When you say "support", does that mean the person is volunteering >> to review drafts, write drafts, participate in email discussions? >> > > in principle, yes, that is what it means > >> Or does it mean you support the concept of the work item >> as long as somebody else does all the work? >> > > that too. We have however defined volunteers for the work items > (or so I believe). Yes, we do expect WG participants to review any > WG docs that get to WG LC. > >> Please make sure you have the resources to do whatever work >> gets chartered. >> > > I believe we do. > You agreed to an interop event. Maybe not to the writeup? > At the other hand, you earlier on agreed to advance 6241/42, which > would mean documenting th eresults (maybe not as RFC). > Yes -- I am willing to work on an interop report draft/RFC. It would be very terse. Each feature/capability would be identified and documented wrt/ # of inter-operating implementations. > Bert >> >> >> Andy Andy >> >> >> On Wed, Aug 29, 2012 at 3:08 AM, Bert Wijnen (IETF) >> wrote: >>> >>> Mmm... as far as I can determine, only ONE person has expressed >>> a clear YES I SUPPORT statement. >>> Others have diverged again into discussing "operational-state". >>> Good discussion, but not what we were trying to get consensus on. >>> >>> Please express your SUPPORT or OBJECTION to the simple and >>> easy charter below. It is a short-term charter with work items >>> that we (seem) to have agreed on. >>> >>> Additional/other work (on which we have no consensus for the >>> exact direction yet) can be brought to the WG in a normal manner >>> via submitting individual I-Ds and getting the WG to discuss it. >>> We can then later add that to the charter of we find that the >>> WG is indeed interested in working on such things. >>> >>> For NOW, PLEASE stick to YES I SUPPORT or NO I OBJECT >>> >>> Bert >>> >>> >>> -------- Original Message -------- >>> Subject: [Netconf] New WGLC for a proposed new WG Charter - respond >>> BEFORE >>> Sept 1st >>> Date: Fri, 17 Aug 2012 00:12:34 +0200 >>> From: Bert Wijnen (IETF) >>> To: netconf >>> >>> >>> Based on the comments and feedback and the positions >>> expressed on the mailing list, it is clear that after all >>> we did NOT have consensus on the new WG charter. >>> >>> Without further ado, this is another proposed WG charter. >>> It focuses on the things that we do seme to have agreement on. >>> >>> Pls comment and/or express your support or objections >>> no later than August 31, 2012. >>> >>> OK, new chapter text (omitting the description of what we have >>> achieved sofar): >>> >>> In the current phase of the incremental development of NETCONF the >>> workgroup will focus on following items: >>> >>> 1. Advance NETCONF over TLS to be in-line with NETCONF 1:1. >>> This means that RFC5593 needs to be updated. >>> >>> 2. Based on the implementation, deployment experience and >>> interoperability >>> testing, the WG will document the status of NETCONF in a report. >>> Based on this, the WG may decide to make some clarifications to >>> RFC6241 and RFC6242 (then also fixing any reported errata). >>> >>> 3. Since Netconf over BEEP and over SOAP seem not being deployed >>> the WG will write a document that makes those 2 protocols >>> (RFC4743 and RFC4744) HISTORIC. >>> >>> Goals and Milestones: >>> done - Send with-defaults to IESG for consideration as Proposed >>> Standard >>> done - WG Last Call on rfc4741bis >>> 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 NACM posted >>> 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 >>> Aug 2012 - submit initial WG draft for rfc5539bis >>> Aug 2012 - submit initial WG draft for making RFC4743 and RFC4744 >>> historic. >>> Sep 2012 - WGLC for rfc5539bis >>> Sep 2012 - WGLC for RFC4743 and 4743 to historic >>> Oct 2012 - submit rfc5539bis to AD/IESG for consideration as Proposed >>> Standard >>> Oct 2012 - submit request to AD/IESG to make RFC4743 and 4744 historic >>> Nov 2012 - Collect Implementation/Deployment reports for RFC6241 and >>> 6242 >>> Dec 2012 - Initial I-D for RFC6241/6242 implementation/deployment >>> experience >>> Jan 2013 - WGLC on RFC6241/6242 implementation/deployment experience >>> Feb 2013 - submit RFC6241/6242 implementation/deployment experience >>> doc >>> to IESG for publication as Informational RFC. >>> Mar 2013 - Evaluate if more work needs to be done by NETCONF WG or >>> close >>> WG >>> >>> Bert and Mehmet >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >> >> > From bertietf@bwijnen.net Fri Aug 31 00:23:01 2012 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 C1F8C21F8452 for ; Fri, 31 Aug 2012 00:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZcv4jeYDf36 for ; Fri, 31 Aug 2012 00:23:00 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id BA7FB21F8450 for ; Fri, 31 Aug 2012 00:22:58 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T7LZ9-0004Rj-Cz for netconf@ietf.org; Fri, 31 Aug 2012 09:22:56 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest156.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T7LZ9-0003QS-29 for netconf@ietf.org; Fri, 31 Aug 2012 09:22:55 +0200 Message-ID: <5040664E.7030803@bwijnen.net> Date: Fri, 31 Aug 2012 09:22:54 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Netconf References: <3662635EF3C645549721026B9865FCE4@BertLaptop> In-Reply-To: <3662635EF3C645549721026B9865FCE4@BertLaptop> X-Forwarded-Message-Id: <3662635EF3C645549721026B9865FCE4@BertLaptop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120831 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4a54ad01fa51a76a4a30d49a72aa2c6a4 Subject: [Netconf] Action by Spet 4th: NetConf interop testing - doodle poll 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 Aug 2012 07:23:01 -0000 Several of the implementers have already agreed to come together for an Interop Test event just before the Atlanta IETF. I created a DOODLE poll to check for the best dates. If you want to come with your implementation to test, pls go to the doodle poll and express if you prefer Friday/Saturday (2-3 Nov) or Saturday/Sunday (3-4 Nov). PLEASE do so no later than Sept 4th 2012. The Event will either be at the IETF hotel or at an NSN facility in Atalanta (but a bit away from the IETF hotel). http://www.doodle.com/nibe3k4c4zuq84mw If you plan to participate, PLEASE fill out the doodle poll no later than Sept 4 Bert From ietfc@btconnect.com Fri Aug 31 04:28:59 2012 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 9764021F858E for ; Fri, 31 Aug 2012 04:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.086 X-Spam-Level: X-Spam-Status: No, score=-3.086 tagged_above=-999 required=5 tests=[AWL=-0.687, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjMI-bMDKN7v for ; Fri, 31 Aug 2012 04:28:58 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6BA21F8565 for ; Fri, 31 Aug 2012 04:28:58 -0700 (PDT) Received: from mail185-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 Aug 2012 11:28:57 +0000 Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id 772CC8C0140; Fri, 31 Aug 2012 11:28:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT012.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: PS-30(zz98dI9371I542M1432I1418Ic1dMzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah107ah1177h1179h304l1155h) Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1346412535673385_14951; Fri, 31 Aug 2012 11:28:55 +0000 (UTC) Received: from CO1EHSMHS014.bigfish.com (unknown [10.243.78.227]) by mail185-co1.bigfish.com (Postfix) with ESMTP id 9E4259E004A; Fri, 31 Aug 2012 11:28:55 +0000 (UTC) Received: from DB3PRD0702HT012.eurprd07.prod.outlook.com (157.55.224.141) by CO1EHSMHS014.bigfish.com (10.243.66.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 Aug 2012 11:28:55 +0000 Received: from CH1PRD0410HT001.namprd04.prod.outlook.com (157.56.244.181) by pod51017.outlook.com (10.3.5.132) with Microsoft SMTP Server (TLS) id 14.15.108.4; Fri, 31 Aug 2012 11:28:29 +0000 Message-ID: <000401cd876b$0e7aed40$4001a8c0@gateway.2wire.net> From: t.petch To: Ladislav Lhotka , Juergen Schoenwaelder References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> Date: Fri, 31 Aug 2012 12:08:57 +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.244.181] X-OriginatorOrg: btconnect.com Cc: netconf@ietf.org Subject: Re: [Netconf] operational state (WAS: New WGLC for a proposed new WG Charter ...) 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 Aug 2012 11:28:59 -0000 ----- Original Message ----- From: "Ladislav Lhotka" To: "t.petch" ; "Juergen Schoenwaelder" Cc: Sent: Wednesday, August 29, 2012 10:13 AM > "t.petch" writes: > > > ----- Original Message ----- > > From: "Juergen Schoenwaelder" > > To: "t.petch" > > Cc: "Martin Bjorklund" ; > > Sent: Sunday, August 26, 2012 10:23 PM > >> On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: > >> > >> > I prefer 'ephemeral configuration' to operational state, since we > >> > have resolutely stated for 10 years than state is read only whereas > >> > configuration is written, so now to have writable state seems a > >> > bigger somersault than to have ephemeral configuration. > >> > >> I do not know why you believe that state is necessarily read only. > > > > Because most of what we have produced says so:-( and what we have > > produced reflects the discussions on the list). > > > > I remain unconvinced about the concept of operational state, that it > > is a meaningful concept. Reading what the operators asked for in > > It is difficult to argue about these concepts without having their definintion. These premises make sense to me though: > > 1. Each device has a set of system parameters/structures that *directly* influence the device > behaviour, no matter how they were set (operator action, factory default, protocol, ...). I'd > suggest to define this set as the "operational state" of the device. Operators need to be able to > have one or more interfaces for viewing (a subset of) this set. Right, I have no problem with this, only that it is new and different to what we have previously discussed and is, for me, a fundamental change of view. I always have had a problem with the Netconf/netmod split of configuration and state, seeing it as artificial. Rather, what you define above, is what I would have called, pre-netmod/conf, configuration, by and large, with or without the epithet 'ephemeral', as I think that many others would do. It does not matter how the routing (/forwarding) table entry got there, the routing table is part of the configuration. I have always read RFC3535 as wanting - how to get a new box from the manufacturer operational - how to get a failing box working again by a variety of means and the netmod/conf view of configuration has focussed on the first which, while important, is not the whole story; and now we are starting to look at the whole story. Well, except that we are not, because it has been ruled out of scope pro tem:-( Tom Petch > 2. In order to be able to control the device, operators need an interface for specifying their instructions for intended changes to the operational state and, consequently, device behaviour. I'd suggest to call these instructions a configuration. The device takes a submitted configuration and applies it according to a certain algorithm depending on the configuration, active network protocols, built-in policies etc. > > Examples of configuration interfaces are: > > - NETCONF (or CLI), where the operator's instructions have to be installed as the "running configuration". > - Unix init scripts, where the instructions are essentially shell scripts. > - RESTful interface, where the operational state is exposed as a set of resources and some of them may be modified via HTTP methods. > > Of course, the hard part is to define the relationship and interactions between a configuration and operational state. In the simplest case, a configuration parameter directly maps to an operational state parameter - the device may accept the configured value or not. > > But there are also more complicated mappings, e.g.: > > - One configuration parameter may disable a subsystem, i.e. a subtree in operational state. > - A list of configured entries get merged to a larger list which is a part of the operational state. An example is the routing table that contains static routes (= configuration) as well as routes learnt from routing protocols. > > > RFC3535, > > "Some devices make it very hard to determine > > which parameters were administratively configured and which > > were obtained via other mechanisms such as routing > > protocols." > > I always think of the routing table and think that that is by-and-large > > a unique, if very common, problem and that trying to extrapolate from > > the routing table to all the other data in a box is not helpful - there > > is > > nothing else like a routing table. The ARP cache has some similarities > > but is much simpler; MPLS FECs may be the other example. > > > > A separate problem is the interface up/down. An operator has configured > > an interface as up and the box says down, because it knows best - the > > line > > card just blew a fuse. This does have parallels elsewhere, with DHCP, > > and may be worth generalising but has little conceptually in common > > with routing tables IMO. > > Right, so the operator gave an instruction/request but the device knows better and doesn't accept it: the up/down parameter in operational state remains down. > > > > > Statistics are different in other ways. Read only, but only sort of; it > > I think that statistics should be put aside and not considered a part of operational state - at least for the purpose of this discussion. > > Lada > > > is > > valuable to have a reset, so that counters may go to zero at midnight > > or some such. SMI recognised statistics as different with Counters > > and that was good to have. It struggled with the sheer volume of data - > > I once set a MIB walk going on the RMONMIB and if I had not shut > > the box down after several days, it would probably still be going some > > years later. But I see nothing in common with the routing table problem > > and the interface status problem, just how to get meaningful information > > from masses of raw data, ie do the maths in the box and ship out the > > summary - and SMI did look at that but it did not seem > > to catch on. > > > > Tom Petch > > > > > > RFC > >> 6244 has some material in sections 4.3 and 4.4. The recommendation > >> given in section 4.4. is not really workable, as we find out working > >> on real data models in NETMOD. > >> > >> The first issue is that there is no standard way to retrieve > >> operational state other than duplicating large parts of the data > >> models, which seems costly and counter intuitive to modelers (who tend > >> to put config false objects next to config true objects). The get() > >> operation gives you a blend of operational state and configurat > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > From lhotka@nic.cz Fri Aug 31 07:13:53 2012 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 E4D3A21F845B for ; Fri, 31 Aug 2012 07:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7l21tlI9hBio for ; Fri, 31 Aug 2012 07:13:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AF82A21F8498 for ; Fri, 31 Aug 2012 07:13:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 64D6F5401C0; Fri, 31 Aug 2012 16:13:50 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa5DORpsPMMq; Fri, 31 Aug 2012 16:13:44 +0200 (CEST) Received: from localhost (birdie.lhotkovi.cz [172.29.2.201]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8A74254004E; Fri, 31 Aug 2012 16:13:41 +0200 (CEST) From: Ladislav Lhotka To: "t.petch" , Juergen Schoenwaelder In-Reply-To: <000401cd876b$0e7aed40$4001a8c0@gateway.2wire.net> References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> <000401cd876b$0e7aed40$4001a8c0@gateway.2wire.net> User-Agent: Notmuch/0.13.2+77~g39beeb2 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Date: Fri, 31 Aug 2012 16:13:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] operational state (WAS: New WGLC for a proposed new WG Charter ...) 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 Aug 2012 14:13:54 -0000 "t.petch" writes: > ----- Original Message ----- > From: "Ladislav Lhotka" > To: "t.petch" ; "Juergen Schoenwaelder" > > Cc: > Sent: Wednesday, August 29, 2012 10:13 AM >> "t.petch" writes: >> >> > ----- Original Message ----- >> > From: "Juergen Schoenwaelder" >> > To: "t.petch" >> > Cc: "Martin Bjorklund" ; >> > Sent: Sunday, August 26, 2012 10:23 PM >> >> On Tue, Aug 21, 2012 at 11:17:32AM +0100, t.petch wrote: >> >> >> >> > I prefer 'ephemeral configuration' to operational state, since we >> >> > have resolutely stated for 10 years than state is read only > whereas >> >> > configuration is written, so now to have writable state seems a >> >> > bigger somersault than to have ephemeral configuration. >> >> >> >> I do not know why you believe that state is necessarily read only. >> > >> > Because most of what we have produced says so:-( and what we have >> > produced reflects the discussions on the list). >> > >> > I remain unconvinced about the concept of operational state, that it >> > is a meaningful concept. Reading what the operators asked for in >> >> It is difficult to argue about these concepts without having their > definintion. These premises make sense to me though: >> >> 1. Each device has a set of system parameters/structures that > *directly* influence the device >> behaviour, no matter how they were set (operator action, factory > default, protocol, ...). I'd >> suggest to define this set as the "operational state" of the device. > Operators need to be able to >> have one or more interfaces for viewing (a subset of) this set. > > Right, I have no problem with this, only that it is new and different to > what we have previously discussed and is, for me, a fundamental change > of view. I always have had a problem with the Netconf/netmod split of > configuration and state, seeing it as artificial. Rather, what you > define above, is what I would have called, pre-netmod/conf, > configuration, by and large, with or without the epithet 'ephemeral', as > I think that many others would do. It does not matter how the routing > (/forwarding) table entry got there, the routing table is part of the > configuration. Hmm, according to my definition, a routing table is a part of operational state. The term "configuration" is limited to the stuff explicitly written by the client/manager. > > I have always read RFC3535 as wanting > - how to get a new box from the manufacturer operational > - how to get a failing box working again by a variety of means > and the netmod/conf view of configuration has focussed on the first > which, while > important, is not the whole story; and now we are starting to look at > the whole story. > Well, except that we are not, because it has been ruled out of scope pro > tem:-( Do you mean it has been ruled out of scope because Bert didn't accept my fourth charter item? It is not how I see it - in fact, I believe there is now a general consensus that the "whole story" has to be addressed. The only problem is that nobody has proposed anything concrete so far, and Bert rightly demanded that such proposal(s) be first submitted as individual drafts. Lada > > Tom Petch > >> 2. In order to be able to control the device, operators need an > interface for specifying their instructions for intended changes to the > operational state and, consequently, device behaviour. I'd suggest to > call these instructions a configuration. The device takes a submitted > configuration and applies it according to a certain algorithm depending > on the configuration, active network protocols, built-in policies etc. >> >> Examples of configuration interfaces are: >> >> - NETCONF (or CLI), where the operator's instructions have to be > installed as the "running configuration". >> - Unix init scripts, where the instructions are essentially shell > scripts. >> - RESTful interface, where the operational state is exposed as a set > of resources and some of them may be modified via HTTP methods. >> >> Of course, the hard part is to define the relationship and > interactions between a configuration and operational state. In the > simplest case, a configuration parameter directly maps to an operational > state parameter - the device may accept the configured value or not. >> >> But there are also more complicated mappings, e.g.: >> >> - One configuration parameter may disable a subsystem, i.e. a subtree > in operational state. >> - A list of configured entries get merged to a larger list which is a > part of the operational state. An example is the routing table that > contains static routes (= configuration) as well as routes learnt from > routing protocols. >> >> > RFC3535, >> > "Some devices make it very hard to determine >> > which parameters were administratively configured and which >> > were obtained via other mechanisms such as routing >> > protocols." >> > I always think of the routing table and think that that is > by-and-large >> > a unique, if very common, problem and that trying to extrapolate > from >> > the routing table to all the other data in a box is not helpful - > there >> > is >> > nothing else like a routing table. The ARP cache has some > similarities >> > but is much simpler; MPLS FECs may be the other example. >> > >> > A separate problem is the interface up/down. An operator has > configured >> > an interface as up and the box says down, because it knows best - > the >> > line >> > card just blew a fuse. This does have parallels elsewhere, with > DHCP, >> > and may be worth generalising but has little conceptually in common >> > with routing tables IMO. >> >> Right, so the operator gave an instruction/request but the device > knows better and doesn't accept it: the up/down parameter in operational > state remains down. >> >> > >> > Statistics are different in other ways. Read only, but only sort > of; it >> >> I think that statistics should be put aside and not considered a part > of operational state - at least for the purpose of this discussion. >> >> Lada >> >> > is >> > valuable to have a reset, so that counters may go to zero at > midnight >> > or some such. SMI recognised statistics as different with Counters >> > and that was good to have. It struggled with the sheer volume of > data - >> > I once set a MIB walk going on the RMONMIB and if I had not shut >> > the box down after several days, it would probably still be going > some >> > years later. But I see nothing in common with the routing table > problem >> > and the interface status problem, just how to get meaningful > information >> > from masses of raw data, ie do the maths in the box and ship out the >> > summary - and SMI did look at that but it did not seem >> > to catch on. >> > >> > Tom Petch >> > >> > >> > RFC >> >> 6244 has some material in sections 4.3 and 4.4. The recommendation >> >> given in section 4.4. is not really workable, as we find out > working >> >> on real data models in NETMOD. >> >> >> >> The first issue is that there is no standard way to retrieve >> >> operational state other than duplicating large parts of the data >> >> models, which seems costly and counter intuitive to modelers (who > tend >> >> to put config false objects next to config true objects). The get() >> >> operation gives you a blend of operational state and configurat >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> > > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From bertietf@bwijnen.net Fri Aug 31 07:30:23 2012 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 52DBA21F861F for ; Fri, 31 Aug 2012 07:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.386 X-Spam-Level: X-Spam-Status: No, score=-102.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLBacN+W4QBD for ; Fri, 31 Aug 2012 07:30:22 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9721F8613 for ; Fri, 31 Aug 2012 07:30:21 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1T7SEl-0003x8-0a; Fri, 31 Aug 2012 16:30:19 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest156.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1T7SEk-0003XV-SZ; Fri, 31 Aug 2012 16:30:18 +0200 Message-ID: <5040CA7A.40704@bwijnen.net> Date: Fri, 31 Aug 2012 16:30:18 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ladislav Lhotka References: <502D7052.2070302@bwijnen.net> <00fb01cd7f7a$2241fce0$4001a8c0@gateway.2wire.net> <20120821.110614.245770058077084953.mbj@tail-f.com> <011f01cd7f86$329b5bc0$4001a8c0@gateway.2wire.net> <20120826212304.GA7642@elstar.local> <00ec01cd8534$27a794a0$4001a8c0@gateway.2wire.net> <000401cd876b$0e7aed40$4001a8c0@gateway.2wire.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816575, check: 20120831 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f12df0069ddb2c0885c37672485c48ff Cc: netconf@ietf.org Subject: Re: [Netconf] operational state (WAS: New WGLC for a proposed new WG Charter ...) 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 Aug 2012 14:30:23 -0000 Exactly On 8/31/12 4:13 PM, Ladislav Lhotka wrote: >> > >> >I have always read RFC3535 as wanting >> >- how to get a new box from the manufacturer operational >> >- how to get a failing box working again by a variety of means >> >and the netmod/conf view of configuration has focussed on the first >> >which, while >> >important, is not the whole story; and now we are starting to look at >> >the whole story. >> >Well, except that we are not, because it has been ruled out of scope pro >> >tem:-( > Do you mean it has been ruled out of scope because Bert didn't accept my > fourth charter item? It is not how I see it - in fact, I believe there > is now a general consensus that the "whole story" has to be addressed. > The only problem is that nobody has proposed anything concrete so far, > and Bert rightly demanded that such proposal(s) be first submitted as > individual drafts. > > Lada > Exactly! Bert From reid@snmp.com Fri Aug 31 09:28:19 2012 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 87A2821F846F for ; Fri, 31 Aug 2012 09:28:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3y7FAkjU8UY for ; Fri, 31 Aug 2012 09:28:19 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0921F8688 for ; Fri, 31 Aug 2012 09:28:18 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id MAA12060; Fri, 31 Aug 2012 12:28:16 -0400 (EDT) Received: from snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) with ESMTP id MAA20112; Fri, 31 Aug 2012 12:28:15 -0400 (EDT) Message-Id: <201208311628.MAA20112@adminfs.snmp.com> To: "Bert Wijnen (IETF)" From: David Reid In-reply-to: Your message of Fri, 31 Aug 2012 09:22:54 +0200. <5040664E.7030803@bwijnen.net> Date: Fri, 31 Aug 2012 12:28:14 -0400 Sender: reid@snmp.com Cc: Netconf Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle poll X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Reid List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:28:19 -0000 > If you plan to participate, > PLEASE fill out the doodle poll no later than Sept 4 I filled out the doodle poll, although I'm not yet sure if I can participate. There are a few issues that have been brought up on the list which would be helpful to resolve soon such as: What tests do we want to run? What Yang modules will we use? Will there be a mutual NDA? -David Reid From andy@yumaworks.com Fri Aug 31 11:51:17 2012 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 5751C21F8567 for ; Fri, 31 Aug 2012 11:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txTtvCMxeacG for ; Fri, 31 Aug 2012 11:51:16 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B785E21F8565 for ; Fri, 31 Aug 2012 11:51:16 -0700 (PDT) Received: by qcac10 with SMTP id c10so2633304qca.31 for ; Fri, 31 Aug 2012 11:51:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=aUxE6DV2yhtoC0zeeDIwMBLsLQmVBpaN3f4P3H5dR74=; b=i0QrejXRW0yTlp5R8NRQj4kCcjVp1FYIZgbttmgDamCPqRH8qYqm1gTSiRNQS/fjw1 g5/kBT/y3+kLQwYcrLK0+E4JRg7LT33MicvOuczNpBsO8Imxg/jgJjAeUOZE6baKji7W veO3KOVErunDGD0R/IayHEJVTP9jge71Olx+r9DTut6Ygsed2X44ObLkKpSI39OYZ9B8 rFrXsI3/q0Uxybxj2nrPnaW4svVp1cfqBdUNGzMJ7UqGRs9wraoqH9ZA3ZPTVbAgIgSw PiIk8pG++zlwMpEj2fjZcGmXrRhqQVxtJpMWjzq+tGx4uz1QJIkLb/bWFnn8CSJuKIW0 UY3w== MIME-Version: 1.0 Received: by 10.229.136.14 with SMTP id p14mr5383907qct.93.1346439075921; Fri, 31 Aug 2012 11:51:15 -0700 (PDT) Received: by 10.49.35.230 with HTTP; Fri, 31 Aug 2012 11:51:15 -0700 (PDT) In-Reply-To: <201208311628.MAA20112@adminfs.snmp.com> References: <5040664E.7030803@bwijnen.net> <201208311628.MAA20112@adminfs.snmp.com> Date: Fri, 31 Aug 2012 11:51:15 -0700 Message-ID: From: Andy Bierman To: David Reid Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnlCXQzj9YTLDE/tBaWJmmdlBfl6JCyxgNdGfkEEPJc9Hi5XTeHR6Xbz7W1bcvI0O/+74Fw Cc: Netconf Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle poll 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 Aug 2012 18:51:17 -0000 On Fri, Aug 31, 2012 at 9:28 AM, David Reid wrote: >> If you plan to participate, >> PLEASE fill out the doodle poll no later than Sept 4 > > I filled out the doodle poll, although I'm not yet sure if I can participate. > > There are a few issues that have been brought up on the list which would be > helpful to resolve soon such as: > > What tests do we want to run? Various people have some proprietary test tools. There are various real applications that can supposedly manage real servers. We need some content to test the operations in RFC 6241. > What Yang modules will we use? The $64 question. We have the following standard modules: - notifications (RFC 5277) - ietf-netconf-partial-lock (RFC 5717) - ietf-netconf-monitoring (RFC 6022) - ietf-netconf-with-defaults (RFC 6243) - ietf-netconf-notifications (RFC 6470) - ietf-netconf-acm (RFC 6536) We could test our own standard modules, some of which have content. Martin has a dummy test module for his scripts. We could use that for edit/retrieve content tests. > Wil l there be a mutual NDA? > This is not an official IETF event. The Note Well/contribution requirements should not apply, so an NDA is possible. > -David Reid Andy From mbj@tail-f.com Fri Aug 31 13:13:46 2012 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 988B921F8555 for ; Fri, 31 Aug 2012 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLX3uF84mu4u for ; Fri, 31 Aug 2012 13:13:46 -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 E371921F8533 for ; Fri, 31 Aug 2012 13:13:45 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id BC1FD1200D4F; Fri, 31 Aug 2012 22:13:43 +0200 (CEST) Date: Fri, 31 Aug 2012 22:13:43 +0200 (CEST) Message-Id: <20120831.221343.480406307.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <5040664E.7030803@bwijnen.net> <201208311628.MAA20112@adminfs.snmp.com> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] Action by Spet 4th: NetConf interop testing - doodle poll 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 Aug 2012 20:13:46 -0000 Andy Bierman wrote: > On Fri, Aug 31, 2012 at 9:28 AM, David Reid wrote: > >> If you plan to participate, > >> PLEASE fill out the doodle poll no later than Sept 4 > > > > I filled out the doodle poll, although I'm not yet sure if I can > > participate. Great if you can be there! > > There are a few issues that have been brought up on the list which would be > > helpful to resolve soon such as: > > > > What tests do we want to run? > > Various people have some proprietary test tools. > There are various real applications that can > supposedly manage real servers. > We need some content to test the operations > in RFC 6241. > > > What Yang modules will we use? Some (generic) implementations can work with any modules, and some implement a fixed set of modules. I think each implementation has to share the data models they implement with the others. For the generic implementation, we can pick some of the standard (or draft) modules. But we need to know well in advance, so that we can adapt our test programs. /martin