From bertietf@bwijnen.net Mon Aug 2 00:59:21 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAED53A6981 for ; Mon, 2 Aug 2010 00:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_50=0.001, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LccTCHBeX8K6 for ; Mon, 2 Aug 2010 00:59:20 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 94E0E3A6833 for ; Mon, 2 Aug 2010 00:59:19 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Ofpvv-00016X-Is for netconf@ietf.org; Mon, 02 Aug 2010 09:59:45 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-65.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Ofpvv-00047I-Dt for netconf@ietf.org; Mon, 02 Aug 2010 09:59:39 +0200 Message-ID: <4C567AEB.9050804@bwijnen.net> Date: Mon, 02 Aug 2010 09:59:39 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b93b509f352a84a682bb390cd1c81fad X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4b93b509f352a84a682bb390cd1c81fad Subject: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 07:59:22 -0000 WG participants, as discussed during our session at the IETF meeting in Maastricht, we are planning to start work on the Netconf Access Control Model (NACM) and also do some work on the netconf-system-specific data model. Below is the proposed charter text for that that your chairs want to present to our AD. This is a 1 week WGLC to comment on that. Pls send your comments asap,m but no later than 8 Aug 2010. If you suggest changes, then pls try to provide proposed text as well. Bert and Mehmet ----- draft new charter text as proposed on Aug 1 2010. Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Tech Advisor: Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/netconf/ Description of Working Group: Charlie Kaufman is Technical Advisor for Security Matters 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 is chartered to produce 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 will 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 a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. The NETCONF protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the NETCONF protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines The initial work started in 2003 and has already been completed and was restricted to following items: a) NETCONF Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. b) NETCONF over SSH Specification: Implementation Mandatory, c) NETCONF over BEEP Specification: Implementation Optional, d) NETCONF over SOAP Specification: Implementation Optional. These documents define how the NETCONF protocol is used with each transport protocol selected by the working group, and how it meets the security and transport layer requirements of the NETCONF Protocol Specification. e) NETCONF Notification Specification, which defines mechanisms that provide an asynchronous message notification delivery service for the NETCONF protocol. NETCONF Notification is an optional capability built on top of the base NETCONF definition and provides the capabilities and operations necessary to support this service. The NETCONF notification specification has been finished now as well. At re-chartering time (Aug 2010), the WG also had completed these work items: f) Fine-grain locking: The base NETCONF protocol only provides a lock for the entire configuration datastore, which is not deemed to meet important operational and security requirements. The NETCONF working group will produce a standards-track RFC specifying a mechanism for fine-grain locking of the NETCONF configuration datastore. g) NETCONF monitoring: It is considered best practice for IETF working groups to include management of their protocols within the scope of the solution they are providing. The NETCONF working group will produce a standards-track RFC with mechanisms allowing NETCONF itself to be used to monitor some aspects of NETCONF operation. Schema advertisement: Currently the NETCONF protocol is able to advertise which protocol features are supported on a particular netconf-capable device. However, there is currently no way to discover which XML Schema are supported on the device. The NETCONF working group will produce a standards-track RFC with mechanisms making this discovery possible (this item may be merged with "NETCONF monitoring" into a single document). Note: The schema-advertisement material has been merged into the NETCONF monitoring document based on WG consensus. h) NETCONF over TLS: Based on implementation experience there is a need for a standards track document to define NETCONF over TLS as an optional transport for the NETCONF protocol. i) NETCONF default handling: NETCONF today does not define whether default values should be returned by the server in replies to requests for reading configuration and state data. Different clients have different needs to receive or not to receive default data. The NETCONF working group will produce a standards-track RFC defining a mechanism that allows NETCONF clients to control whether default data is returned by the netconf server. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work was started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). 2. A technical errata has been posted on rfc4742. The work on rfc4741bis also uncovered some additional fixes/clarifications that need to be made to rfc4742, the WG has been working on rfc4742bis and is nearly done with this work item. 3. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 4. The NETCONF protocol and the NETCONF server may want to allow a client to check the status at the server end. In addition, the server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to address this requirement. It is specific for NETCONF protocol and server information. Goals and Milestones: Done - Working Group formed Done - Submit initial Netconf Protocol draft Done - Submit initial Netconf over (transport-TBD) draft Done - Begin Working Group Last Call for the Netconf Protocol draft Done - Begin Working Group Last Call for the Netconf over (transport-TBD) draft Done - Submit final version of the Netconf Protocol draft to the IESG Done - Submit final version of the Netconf over SOAP draft to the IESG Done - Submit final version of the Netconf over BEEP draft to the IESG Done - Submit final version of the Netconf over SSH draft to the IESG Done - Update charter Done - Submit first version of NETCONF Notifications document Done - Begin WGLC of NETCONF Notifications document Done - Submit NETCONF Notifications document to IESG for consideration as Proposed Standard Done - -00 draft for NETCONF Monitoring Done - -00 draft for Schema Advertisement Done - -00 draft for Fine Grain Locking Done - -00 draft for NETCONF over TLS Done - Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 Done - WG Last Call on NETCONF Monitoring after IETF72 Done - WG Last Call on NETCONF over TLS after IETF72 Done - WG Last Call on Fine Grain Locking after IETF72 Done - Send Partial Locking to IESG for consideration as Proposed Standards Done - Initial WG draft for with-defaults capability Done - Initial WG draft for rfc4741bis Done - WG Last Call on NETCONF Monitoring after IETF73 Done - Submit first WG draft for rfc4742bis Done - WG Last Call on with-defaults Done - Send NETCONF monitoring to IESG for approval as Proposed Standard Done - WG Last Call for rfc4742bis Done - with-defaults capability to IESG for considerations as Proposed Standard Aug 2010 - WG Last Call on rfc4741bis Sep 2010 - rfc4741bis to IESG for consideration as Proposed Standard Sep 2010 - Send rfc4742bis to IESG for consideration as proposed Standard. Sep 2010 - first WG draft (rev 00) on NACM posted Sep 2010 - first WG draft (rev 00) on System Monitoring posted Jan 2011 - WGLC for NACM document Jan 2011 - WGLC for System Monitoring document Mar 2011 - (if needed last) WGLC for NACM document Mar 2011 - (if needed last) WGLC for System Monitoring document Apr 2011 - submit NACM document to IESG for consideration as Proposed Standard Apr 2011 - submit System Monitoring document to IESG for consideration as Proposed Standard From j.schoenwaelder@jacobs-university.de Mon Aug 2 01:38:17 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF753A6B1B for ; Mon, 2 Aug 2010 01:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_40=-0.185, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prsEpG02Ctsw for ; Mon, 2 Aug 2010 01:38:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A96463A6B10 for ; Mon, 2 Aug 2010 01:37:47 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFD6AC0008; Mon, 2 Aug 2010 10:37:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gHVpOBU9mjVP; Mon, 2 Aug 2010 10:37:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9140C000A; Mon, 2 Aug 2010 10:37:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 439E313F676E; Mon, 2 Aug 2010 10:37:17 +0200 (CEST) Date: Mon, 2 Aug 2010 10:37:17 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100802083717.GA31061@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , netconf References: <4C567AEB.9050804@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C567AEB.9050804@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 02 Aug 2010 08:38:17 -0000 On Mon, Aug 02, 2010 at 09:59:39AM +0200, Bert (IETF) Wijnen wrote: > This is a 1 week WGLC to comment on that. > Pls send your comments asap,m but no later than 8 Aug 2010. > > If you suggest changes, then pls try to provide proposed > text as well. Do we have to keep all the historic garbage for procedural reasons or are we allowed to cut the charter to say one third, removing all the stuff that is not relevant anymore because it is already part of RFCs. I am happy to make a concrete proposal but before going there and spending time on it, I thought I first ask whether there is anyone who believes that keeping all the historic noise is a feature worth to preserve. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Mon Aug 2 02:10:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E1533A6B34 for ; Mon, 2 Aug 2010 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCgTjnL6jbiD for ; Mon, 2 Aug 2010 02:10:05 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id E8CF63A6B48 for ; Mon, 2 Aug 2010 02:10:00 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Ofr2K-0005QW-Sb; Mon, 02 Aug 2010 11:10:26 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-65.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Ofr2K-0006AD-O0; Mon, 02 Aug 2010 11:10:20 +0200 Message-ID: <4C568B7C.6030401@bwijnen.net> Date: Mon, 02 Aug 2010 11:10:20 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , netconf References: <4C567AEB.9050804@bwijnen.net> <20100802083717.GA31061@elstar.local> In-Reply-To: <20100802083717.GA31061@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40e9bc8e4c45f085f5068dfad2b7dd9bd X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd40e9bc8e4c45f085f5068dfad2b7dd9bd Subject: Re: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:10:06 -0000 Juergen Schoenwaelder wrote: > On Mon, Aug 02, 2010 at 09:59:39AM +0200, Bert (IETF) Wijnen wrote: > > >> This is a 1 week WGLC to comment on that. >> Pls send your comments asap,m but no later than 8 Aug 2010. >> >> If you suggest changes, then pls try to provide proposed >> text as well. >> > > Do we have to keep all the historic garbage for procedural reasons or > are we allowed to cut the charter to say one third, removing all the > stuff that is not relevant anymore because it is already part of RFCs. > > I am happy to make a concrete proposal but before going there and > spending time on it, I thought I first ask whether there is anyone who > believes that keeping all the historic noise is a feature worth to > preserve. > > /js > > I guess I sort of do that (got used to do that) because in the past, we would easily loose such information. Now that we in fact have all old charters archived and accessible from the WG charter page, I would have no problem to remove all the old and completed stuff. Dan, can you shed some light on this as well? Bert From dromasca@avaya.com Mon Aug 2 02:20:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF6B33A6875 for ; Mon, 2 Aug 2010 02:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoA+egHgbHKj for ; Mon, 2 Aug 2010 02:20:34 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id CB4793A67E7 for ; Mon, 2 Aug 2010 02:20:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,302,1278302400"; d="scan'208";a="230758696" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Aug 2010 05:21:01 -0400 X-IronPort-AV: E=Sophos;i="4.55,302,1278302400"; d="scan'208";a="488044000" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 02 Aug 2010 05:21:01 -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: Mon, 2 Aug 2010 11:20:48 +0200 Message-ID: In-Reply-To: <4C568B7C.6030401@bwijnen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th Thread-Index: AcsyIpmqHNPGw2WzRJ+JSKQ4o34XvQAADrZw References: <4C567AEB.9050804@bwijnen.net><20100802083717.GA31061@elstar.local> <4C568B7C.6030401@bwijnen.net> From: "Romascanu, Dan (Dan)" To: "Bert (IETF) Wijnen" , "netconf" Subject: Re: [Netconf] WGLC for proposed new WG charter - pls comment by Aug 8th X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:20:35 -0000 Bert is correct. With the archiving capabilities no need to carry full text of previous charter nor old milestones. I would just write a new paragraph resuming the previous stages of standardization the current stage builds upon, and I would keep from the old milestones only the publication of the RFCs which helps newcomers to the Web page (who may also not be too exercised in looking back in archives).=20 Dan > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Bert (IETF) Wijnen > Sent: Monday, August 02, 2010 12:10 PM > To: Bert (IETF) Wijnen; netconf > Subject: Re: [Netconf] WGLC for proposed new WG charter - pls=20 > comment by Aug 8th >=20 > Juergen Schoenwaelder wrote: > > On Mon, Aug 02, 2010 at 09:59:39AM +0200, Bert (IETF) Wijnen wrote: > > =20 > > =20 > >> This is a 1 week WGLC to comment on that. > >> Pls send your comments asap,m but no later than 8 Aug 2010. > >> > >> If you suggest changes, then pls try to provide proposed text as=20 > >> well. > >> =20 > > > > Do we have to keep all the historic garbage for procedural=20 > reasons or=20 > > are we allowed to cut the charter to say one third,=20 > removing all the=20 > > stuff that is not relevant anymore because it is already=20 > part of RFCs. > > > > I am happy to make a concrete proposal but before going there and=20 > > spending time on it, I thought I first ask whether there is=20 > anyone who=20 > > believes that keeping all the historic noise is a feature worth to=20 > > preserve. > > > > /js > > > > =20 > I guess I sort of do that (got used to do that) because in=20 > the past, we would easily loose such information. Now that we=20 > in fact have all old charters archived and accessible from=20 > the WG charter page, I would have no problem to remove all=20 > the old and completed stuff. >=20 > Dan, can you shed some light on this as well? >=20 > Bert > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From mehmet.ersue@nsn.com Wed Aug 4 05:57:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD7C83A67E2 for ; Wed, 4 Aug 2010 05:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=-0.545, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCwzhQeSRMvJ for ; Wed, 4 Aug 2010 05:57:53 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 5BB2B3A6767 for ; Wed, 4 Aug 2010 05:57:53 -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 o74CwKce011335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Aug 2010 14:58:20 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o74CwFtv017813 for ; Wed, 4 Aug 2010 14:58:20 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Aug 2010 14:58:18 +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, 4 Aug 2010 14:58:17 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64C9446C@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF #78 Draft NETCONF WG Session Minutes Thread-Index: Acsz1LVLQmzNVnL5Q5ulLaJbg/Gf4Q== From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 04 Aug 2010 12:58:18.0782 (UTC) FILETIME=[B5E2E3E0:01CB33D4] Subject: [Netconf] IETF #78 Draft NETCONF WG Session Minutes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 12:57:54 -0000 Dear NETCONF WG,=20 I uploaded the draft minutes for the NETCONF session=20 at IETF #78. Many thanks to Lada and Juergen for taking=20 the minutes!=20 http://www.ietf.org/proceedings/78/minutes/netconf.txt=20 Please review and let us know your comments by August 11,=20 2010 EOB. Thank you.=20 Mehmet & Bert From ietf@andybierman.com Thu Aug 5 10:51:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D197C3A6898 for ; Thu, 5 Aug 2010 10:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aYP9ceVtDZm for ; Thu, 5 Aug 2010 10:51:36 -0700 (PDT) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id 057B43A6A98 for ; Thu, 5 Aug 2010 10:51:35 -0700 (PDT) Received: (qmail 88785 invoked from network); 5 Aug 2010 17:52:03 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 05 Aug 2010 10:52:03 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: vkh8O0cVM1kQr1qbwjpkqRvywFgLyDJX7NuKiSvBixJgGlM AkZAsfzfa9P1p9yvW8K5Cx1qT7D.Auo92yn6T21PsbukUjL7.IXTKAxFahR0 qIh.XrX9LHVw.H8m1ZgyD_z3wLxqC93SJaw0MqcDCCmrA5Jt0L1faR70UGeT L2gQE0ZyISVBPwgENUWFcXsa1004GM3i5KuiJ549tjARzJfGFzrOg8e2V557 BF0BWDI3M3iyIFu1MaPmto4WXOLM6MuNQBZxoXqKZTzXfxxVIE8.4ViDTUQr bBfALs5y7bpqjY98iaLTRSQRDqwdAxjVQLVQ8gjRpUYMVcw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C5AFA42.5030802@andybierman.com> Date: Thu, 05 Aug 2010 10:52:02 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: NETCONF , NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Netconf] FYI: open-source NETCONF implementation X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 17:51:36 -0000 Hi, I have made my NETCONF tools into an open-source project with a BSD license: http://yuma.sourceforge.net/ I have started a new job (yet another email change to follow...), so I am looking for volunteers to maintain and improve the code base. (See the TODO list in the top directory.) I do not have enough time to actively work on code enhancements anymore. Andy From bertietf@bwijnen.net Sat Aug 7 06:06:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A062B3A69AD for ; Sat, 7 Aug 2010 06:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXiJsGMLBuCW for ; Sat, 7 Aug 2010 06:06:31 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1341]) by core3.amsl.com (Postfix) with ESMTP id 8E6303A686B for ; Sat, 7 Aug 2010 06:06:30 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.1.103]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Ohj71-0007sh-58 for netconf@ietf.org; Sat, 07 Aug 2010 15:07:00 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by ayeaye.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1Ohj70-0000DY-UB for netconf@ietf.org; Sat, 07 Aug 2010 15:06:55 +0200 Message-ID: <4C5D5A6E.2000505@bwijnen.net> Date: Sat, 07 Aug 2010 15:06:54 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45384b47d70fa365bc3d2cf407bb7079f X-RIPE-Spam-Level: ---- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45384b47d70fa365bc3d2cf407bb7079f Subject: [Netconf] status of the new NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 13:06:33 -0000 Based on comments from we have received from Dan, Juergen, Andy, and a few others, we now have the following text. The text has been shortened. We removed a lot of old work-items and milestones. These are all saved in the multiple versions of the charter that we see on our WG charter page these days. So no need to keep carrying it forward. We do explain the basics of the published NETCONF protocol, and then describe the work we need to do in the next phase. Content wise in terms of work to do, this is the same as what we did send out end of July. But have clarified some that the any YANG modules we do MUST be NETCONF specific. We are still planning to hand this to Dan asap, so hopefully he can still put it on the IESG agenda for August 12. So we intend to send the formal request to him coming Monday morning (Aug 9th). Bert and Mehmet ----------------- draft Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu 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) - Is in principle transport-independent, but mandates the use of a secure transport. Runs by default over SSH but currently also runs over TLS, BEEP, and SOAP. - Provides support for asynchronous notifications. The NETCONF protocol is using XML for data encoding purposes. 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. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work was started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). 2. A technical errata has been posted on rfc4742. The work on rfc4741bis also uncovered some additional fixes/clarifications that need to be made to rfc4742, the WG has been working on rfc4742bis and is nearly done with this work item. 3. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 4. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 5. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. Goals and Milestones: Aug 2010 - Send with-defaults to IESG for consideration as Proposed Standard Aug 2010 - WG Last Call on rfc4741bis Sep 2010 - rfc4741bis to IESG for consideration as Proposed Standard Sep 2010 - Send rfc4742bis to IESG for consideration as proposed Standard. Sep 2010 - first WG draft (rev 00) on NACM posted Sep 2010 - first WG draft (rev 00) on NETCONF specific YANG modules posted Jan 2011 - WGLC for NACM document Jan 2011 - WGLC for NETCONF specific YANG modules document Mar 2011 - (if needed last) WGLC for NACM document Mar 2011 - (if needed last) WGLC for NETCONF specific YANG modules document Apr 2011 - submit NACM document to IESG for consideration as Proposed Standard Apr 2011 - submit NETCONF specific YANG modules document to IESG for consideration as Proposed Standard From j.schoenwaelder@jacobs-university.de Mon Aug 9 02:14:10 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05E23A6AB7 for ; Mon, 9 Aug 2010 02:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.383 X-Spam-Level: X-Spam-Status: No, score=-100.383 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_50=0.001, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0sBV-eHn7zd for ; Mon, 9 Aug 2010 02:14:09 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 709CE3A6AB4 for ; Mon, 9 Aug 2010 02:14:09 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 26570C0002; Mon, 9 Aug 2010 11:14:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ssOcVhcojd85; Mon, 9 Aug 2010 11:14:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC626C0008; Mon, 9 Aug 2010 11:14:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8C48B1426952; Mon, 9 Aug 2010 11:14:38 +0200 (CEST) Date: Mon, 9 Aug 2010 11:14:38 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100809091438.GA11618@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , netconf References: <4C5D5A6E.2000505@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5D5A6E.2000505@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] status of the new NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 09:14:11 -0000 On Sat, Aug 07, 2010 at 03:06:54PM +0200, Bert (IETF) Wijnen wrote: > Based on comments from we have received from Dan, Juergen, > Andy, and a few others, we now have the following text. [...] > So we intend to send the formal request to him coming > Monday morning (Aug 9th). Some minor suggested edits after reading the charter once more (I can live with the charter as is as well - so feel free to ignore the comments if you feel like it): > - Is in principle transport-independent, but mandates the use of a > secure transport. Runs by default over SSH but currently also runs > over TLS, BEEP, and SOAP. I would replace this with the following (I believe this captures the important thing and avoid the vague "in principle transport-independent" phrase): - Runs by default over SSH but can currently also run over TLS, BEEP, and SOAP. > The NETCONF protocol is using XML for data encoding purposes. I would remove this sentence since this has already been stated before. Finally, unless the phrase "NETCONF specific YANG modules document" has been choosen on purpose in the milestones, I would call this "NETCONF specific notifications document" since this aligns more clearly with work item #4. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Mon Aug 9 04:43:51 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565A83A6834 for ; Mon, 9 Aug 2010 04:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LL2zFRD-J1uA for ; Mon, 9 Aug 2010 04:43:50 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id AF0023A68F2 for ; Mon, 9 Aug 2010 04:43:47 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OiQm7-0001sS-Ou; Mon, 09 Aug 2010 13:44:21 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-106.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OiQm7-00011c-MP; Mon, 09 Aug 2010 13:44:15 +0200 Message-ID: <4C5FEA0F.6040203@bwijnen.net> Date: Mon, 09 Aug 2010 13:44:15 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf References: <4C5D5A6E.2000505@bwijnen.net> <20100809091438.GA11618@elstar.local> In-Reply-To: <20100809091438.GA11618@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4bd39b7a4da66f87794210472468629ef X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4bd39b7a4da66f87794210472468629ef Subject: Re: [Netconf] status of the new NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 11:43:51 -0000 Juergen Schoenwaelder wrote: > On Sat, Aug 07, 2010 at 03:06:54PM +0200, Bert (IETF) Wijnen wrote: > >> Based on comments from we have received from Dan, Juergen, >> Andy, and a few others, we now have the following text. >> > > [...] > > >> So we intend to send the formal request to him coming >> Monday morning (Aug 9th). >> > > Some minor suggested edits after reading the charter once more (I can > live with the charter as is as well - so feel free to ignore the > comments if you feel like it): > > >> - Is in principle transport-independent, but mandates the use of a >> secure transport. Runs by default over SSH but currently also runs >> over TLS, BEEP, and SOAP. >> > > I would replace this with the following (I believe this captures the > important thing and avoid the vague "in principle > transport-independent" phrase): > > - Runs by default over SSH but can currently also run over TLS, > BEEP, and SOAP. > > Mmm... I do want to express that a secure transport is mandatory (or such is my understanding) How about: - Runs over a secure transport, by default over SSH but can currently also run over TLS, BEEP, and SOAP. I am also a bit worried of "default". We have made implementation ove SSH the mandatory one. But does that also means that it does so "by default". On some implemntation probably so, I could see that some other use another one by default, even though they do support ssh (at least if they want to claim compliance). >> The NETCONF protocol is using XML for data encoding purposes. >> > > I would remove this sentence since this has already been stated > before. > > I see that too now. Will remove it. > Finally, unless the phrase "NETCONF specific YANG modules document" > has been choosen on purpose in the milestones, I would call this > "NETCONF specific notifications document" since this aligns more > clearly with work item #4. > > I see what you want. Would you allow a few data nodes if such were to be used in those notifications? If so, then I can live with that. I guess you assume that if any non-notification stuff needs to be defined that we would do so by a revision to the monitoring document. I can live with that. Bert > /js > > From j.schoenwaelder@jacobs-university.de Mon Aug 9 04:57:27 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D88B28C0E3 for ; Mon, 9 Aug 2010 04:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEPA96UZjSMP for ; Mon, 9 Aug 2010 04:57:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 658FC28C0E0 for ; Mon, 9 Aug 2010 04:57:26 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AC80C0009; Mon, 9 Aug 2010 13:58:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zp8jRiOhDxqy; Mon, 9 Aug 2010 13:57:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0AC48C0002; Mon, 9 Aug 2010 13:57:59 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 562DF14273F2; Mon, 9 Aug 2010 13:57:54 +0200 (CEST) Date: Mon, 9 Aug 2010 13:57:54 +0200 From: Juergen Schoenwaelder To: "Bert (IETF) Wijnen" Message-ID: <20100809115754.GB12507@elstar.local> Mail-Followup-To: "Bert (IETF) Wijnen" , netconf References: <4C5D5A6E.2000505@bwijnen.net> <20100809091438.GA11618@elstar.local> <4C5FEA0F.6040203@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C5FEA0F.6040203@bwijnen.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] status of the new NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 11:57:27 -0000 On Mon, Aug 09, 2010 at 01:44:15PM +0200, Bert (IETF) Wijnen wrote: > > I would replace this with the following (I believe this captures the > > important thing and avoid the vague "in principle > > transport-independent" phrase): > > > > - Runs by default over SSH but can currently also run over TLS, > > BEEP, and SOAP. > > > > Mmm... I do want to express that a secure transport is mandatory (or > such is my understanding) > How about: > > - Runs over a secure transport, by default over SSH but can > currently also run over TLS, BEEP, and SOAP. > > I am also a bit worried of "default". We have made implementation > ove SSH the mandatory one. But does that also means that it does so > "by default". On some implemntation probably so, I could see that > some other use another one by default, even though they do support > ssh (at least if they want to claim compliance). The lets say what the facts are: - Runs over a secure transport; SSH is mandatory to implement while TLS, BEEP, and SOAP are optional transports. > I guess you assume that if any non-notification stuff needs to be > defined that we would do so by a revision to the monitoring > document. Yes. And the drafted WG charter allows to revise the monitoring document if that is deemed useful by the WG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From bertietf@bwijnen.net Mon Aug 9 05:32:49 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6521528C0DC for ; Mon, 9 Aug 2010 05:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-km6i-s9U90 for ; Mon, 9 Aug 2010 05:31:24 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id 21A363A6ACE for ; Mon, 9 Aug 2010 05:31:23 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OiRWB-00064y-BM; Mon, 09 Aug 2010 14:31:56 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=guest-106.ripe.net) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OiRWB-00035y-7H; Mon, 09 Aug 2010 14:31:51 +0200 Message-ID: <4C5FF537.9070600@bwijnen.net> Date: Mon, 09 Aug 2010 14:31:51 +0200 From: "Bert (IETF) Wijnen" User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Bert (IETF) Wijnen" , netconf References: <4C5D5A6E.2000505@bwijnen.net> <20100809091438.GA11618@elstar.local> <4C5FEA0F.6040203@bwijnen.net> <20100809115754.GB12507@elstar.local> In-Reply-To: <20100809115754.GB12507@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ccb356338a01defebd10a9e78be0516c X-RIPE-Spam-Level: -- X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ccb356338a01defebd10a9e78be0516c Subject: Re: [Netconf] status of the new NETCONF WG charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:32:50 -0000 My responses to Juergen inline. If anyone else has comments, you have time till approx 2pm Tuesday (Netherlands time, i.e. noon UTC). After that I have to hand it to Dan for IESG processing, so we can get it approved before the end of August. Bert Juergen Schoenwaelder wrote: > On Mon, Aug 09, 2010 at 01:44:15PM +0200, Bert (IETF) Wijnen wrote: > > >>> I would replace this with the following (I believe this captures the >>> important thing and avoid the vague "in principle >>> transport-independent" phrase): >>> >>> - Runs by default over SSH but can currently also run over TLS, >>> BEEP, and SOAP. >>> >>> >> Mmm... I do want to express that a secure transport is mandatory (or >> such is my understanding) >> How about: >> >> - Runs over a secure transport, by default over SSH but can >> currently also run over TLS, BEEP, and SOAP. >> >> I am also a bit worried of "default". We have made implementation >> ove SSH the mandatory one. But does that also means that it does so >> "by default". On some implemntation probably so, I could see that >> some other use another one by default, even though they do support >> ssh (at least if they want to claim compliance). >> > > The lets say what the facts are: > > - Runs over a secure transport; SSH is mandatory to implement > while TLS, BEEP, and SOAP are optional transports. > > Deal! >> I guess you assume that if any non-notification stuff needs to be >> defined that we would do so by a revision to the monitoring >> document. >> > > Yes. And the drafted WG charter allows to revise the monitoring > document if that is deemed useful by the WG. > > OK, changed accordingly. Bert > /js > > From ietfc@btconnect.com Tue Aug 10 02:22:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57B33A682D for ; Tue, 10 Aug 2010 02:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.558 X-Spam-Level: X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNHnOmy6zYHL for ; Tue, 10 Aug 2010 02:22:35 -0700 (PDT) Received: from c2bthomr13.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by core3.amsl.com (Postfix) with ESMTP id 9ED203A68DF for ; Tue, 10 Aug 2010 02:22:35 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2bthomr13.btconnect.com with SMTP id FTC52635; Tue, 10 Aug 2010 10:22:56 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C611A70.01A1, actions=tag Message-ID: <008101cb3864$9d4941a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert \(IETF\) Wijnen" , "netconf" References: <4C5D5A6E.2000505@bwijnen.net> Date: Tue, 10 Aug 2010 10:10:45 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B020A.4C611A7D.017E,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] status of with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 09:22:37 -0000 I am unclear where with-defaults got to. There was a Last Call which seemed to peter out, a new version appeared picking up some but not all of the comments and ... I still have problems of comprehension with this I-D, as perhaps Martin alluded to in his comments. Two areas. Data nodes. This I-D references the YANG I-D, and so users of it might know that a data node is part of the schema tree and nothing to do with the data tree. Which makes its use here potentially confusing to me since most if not all uses of it seem to refer to nodes/leaves in the data tree.. As (head-banging) Randy has pointed out, you cannot not have a meta-model of the data for an I-D like this one, and if it is different to YANG, then I think that that needs spelling out. A few years ago, I would have said that this was unnecessary but the YANG I-D with its different (to me) definition of data node has changed that. An allied problem is that this references RFC4741 for a definition of datastore and yet that term is not defined there. Rather, RFC4741 (almost) always uses configuration datastore so I think that this I-D should do so as well or else (re-)define datastore. And whatever is in that data node seems to be described in many ways; if these are the same, then I find that confusing, if different, I am confused. I see these thingies in the data tree having a 'match' or 'set' or 'contain' or 'has' or 'represent' or ... relationship to the default values e.g. have a large number of default values a data node that contains its schema default any data node set to its schema default value to be default data. represented by a schema default value they match the schema default value Whatever the relationship is, I think that only one verb should be used to portray it, unless a distinction is being drawn (which there could be in some but not all uses of 'set') ie we have a 'data tree', it consists of 'leaf (foo/ bar/ ...) nodes' and they 'have (/contain/ ...)' values. This probably seems trivial to you who have lived with this for several months, but to someone coming to it afresh, or coming back after a hiatus of some months, I think this a significant problem of comprehension. And it is not as if the semantics being described are familiar or easy to follow! Tom Petch From bertietf@bwijnen.net Tue Aug 10 03:06:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9C23A68AB; Tue, 10 Aug 2010 03:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.236 X-Spam-Level: X-Spam-Status: No, score=-99.236 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DMqSsK-13Cg; Tue, 10 Aug 2010 03:06:12 -0700 (PDT) Received: from relay.versatel.net (relay55.tele2.vuurwerk.nl [62.250.3.55]) by core3.amsl.com (Postfix) with ESMTP id D88213A68D0; Tue, 10 Aug 2010 03:06:11 -0700 (PDT) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1OiljJ-0006Er-0j; Tue, 10 Aug 2010 12:06:45 +0200 Message-ID: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Netconf" , "NETMOD Working Group" Date: Tue, 10 Aug 2010 12:05:55 +0200 Organization: Consultant 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 Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: [Netconf] Fw: "Recent Advances in IETF Standards" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:06:13 -0000 I would think that it might be good to write an article on NETCONF and YANG. But I do not have the time. So any (small set of) volunteers? Bert ----- Original Message ----- From: "Henning Schulzrinne" To: "IETF discussion list" Sent: Tuesday, August 10, 2010 11:57 AM Subject: CFP: "Recent Advances in IETF Standards" I wouldn't normally post a CFP here, but the topic is uniquely relevant to the list. Henning ================================================================== Call For Papers - IEEE Communications Magazine Feature Topic on "Recent Advances in IETF Standards" ================================================================== The mission of the Internet engineering Task Force (IETF) is to "make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet". This is a continuous process driving and driven by the rapid evolution of the Internet. Protocols and other technical standards developed by the IETF are fundamental building blocks of the networked society. This feature topic will give an overview of recent achievements in creating standards that soon will have an impact on design, use and management of the Internet. We welcome tutorial style papers that describe new IETF standards as well as research papers presenting results that had an impact on the standardization process or that investigate the expected impact of recent standards. All submissions should be written to be understandable and appealing to a general audience. Areas of Interest ================= Areas of interest include standards track work that has been completed recently or will be completed soon from all areas of the IETF including but not limited to - Emergency service - Location based services - Internationalization - Peer-to-peer communication - Network address translation - Congestion control - IP6 transition - Mobility and mobility management - Secure DNS - Routing security - Locator/Identifier Separation - MPLS Transport Profile - Better-than-nothing security - Network configuration with XML - Internet metrics and measurement Schedule ======== Full paper submission: October 1, 2010 Author notifications: December 17, 2010 Manuscripts in final form: January 27, 2011 Publication date: April 2011 Submission Instructions ======================= Articles should be tutorial in nature and should be written in a style comprehensible to readers outside the specialty of the field. Authors must follow the IEEE Communications Magazine's guidelines for preparation of the manuscript. Complete guidelines for prospective authors can be found at http://www.comsoc.org/livepubs/ci1/info/sub_guidelines.html. All articles to be considered for publication must be submitted through the IEEE Manuscript Central (http://commag-ieee.manuscriptcentral.com). Guest Editors ============= Juergen Quittek, NEC Europe Ltd., quittek@neclab.eu Henning Schulzrinne, Columbia University, hgs@cs.columbia.edu Joe Touch, Postel Center, USC/ISI, touch@isi.edu _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From j.schoenwaelder@jacobs-university.de Tue Aug 10 03:19:12 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0683A6807; Tue, 10 Aug 2010 03:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.692 X-Spam-Level: X-Spam-Status: No, score=-101.692 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWOYijh-eqhq; Tue, 10 Aug 2010 03:19:11 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 204413A686E; Tue, 10 Aug 2010 03:19:11 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6276C0008; Tue, 10 Aug 2010 12:19:45 +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 iP3jYg88Ra-9; Tue, 10 Aug 2010 12:19:45 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D798CC0006; Tue, 10 Aug 2010 12:19:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 96026142B2F1; Tue, 10 Aug 2010 12:19:41 +0200 (CEST) Date: Tue, 10 Aug 2010 12:19:41 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20100810101941.GB31333@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Netconf , NETMOD Working Group References: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ED2319ABA69470A9736F0F737146B09@BertLaptop> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Netconf , NETMOD Working Group Subject: Re: [Netconf] [netmod] Fw: "Recent Advances in IETF Standards" X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:19:12 -0000 On Tue, Aug 10, 2010 at 12:05:55PM +0200, Bert Wijnen (IETF) wrote: > I would think that it might be good to write an article on > NETCONF and YANG. > > But I do not have the time. So any (small set of) volunteers? This paper has already been written, likely to appear in the September issue (this was the last thing I heard - but they tend to reschedule papers sometimes and as long as YANG has no RFC number I won't complain ;-). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Tue Aug 10 07:11:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D417C3A69A5 for ; Tue, 10 Aug 2010 07:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQk8EmcBU40E for ; Tue, 10 Aug 2010 07:11:02 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by core3.amsl.com (Postfix) with ESMTP id 23C823A6405 for ; Tue, 10 Aug 2010 07:11:02 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7AEBaLM000317 for ; Tue, 10 Aug 2010 10:11:37 -0400 Authentication-Results: cm-omr2 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.126.228.107] ([173.126.228.107:50793] helo=[173.126.228.107]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 09/9F-21551-71E516C4; Tue, 10 Aug 2010 10:11:36 -0400 To: "=?utf-8?B?dC5wZXRjaA==?=" , "=?utf-8?B?QmVydCBcKElFVEZcKSBXaWpuZW4=?=" , "netconf" Message-ID: <09.9F.21551.71E516C4@cm-omr2> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 10 Aug 2010 07:11:50 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2_1281449510806" Subject: Re: [Netconf] =?utf-8?q?status_of_with-defaults?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:11:03 -0000 ------=_Part_2_1281449510806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpUaGVzZSBjb21tZW50cyBzZWVtIGxpa2UgbWlub3Igbml0cy4gIE5vdCBzdXJlIHdoYXQg eW91IHdhbnQgdG8gY2hhbmdlLiAgSSBkb24ndCB0aGluayB0aGUgdmVyYiB1c2FnZSBpcyBjb25m dXNpbmcsIGJ1dCBJIHdpbGwgbG9vayBhdCBhbGlnbmluZyBtb3JlIGNsb3NlbHkgd2l0aCA0NzQx IGFuZCB0aGUgWUFORyBkcmFmdC4KCkFuZHkKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJv bTogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPgpEYXRlOiBUdWUsIEF1ZyAxMCwgMjAx MCAwMToxMApTdWJqZWN0OiBbTmV0Y29uZl0gc3RhdHVzIG9mIHdpdGgtZGVmYXVsdHMKVG86ICJC ZXJ0IFwoSUVURlwpIFdpam5lbiIgPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PiwgIm5ldGNvbmYiIDxu ZXRjb25mQGlldGYub3JnPgoKSSBhbSB1bmNsZWFyIHdoZXJlIHdpdGgtZGVmYXVsdHMgZ290IHRv LiAgVGhlcmUgd2FzIGEgTGFzdCBDYWxsIHdoaWNoIHNlZW1lZCB0bwpwZXRlciBvdXQsIGEgbmV3 IHZlcnNpb24gYXBwZWFyZWQgcGlja2luZyB1cCBzb21lIGJ1dCBub3QgYWxsIG9mIHRoZSBjb21t ZW50cwphbmQgLi4uCgpJIHN0aWxsIGhhdmUgcHJvYmxlbXMgb2YgY29tcHJlaGVuc2lvbiB3aXRo IHRoaXMgSS1ELCBhcyBwZXJoYXBzIE1hcnRpbiBhbGx1ZGVkCnRvIGluIGhpcyBjb21tZW50cy4K ClR3byBhcmVhcy4KCkRhdGEgbm9kZXMuICBUaGlzIEktRCByZWZlcmVuY2VzIHRoZSBZQU5HIEkt RCwgYW5kIHNvIHVzZXJzIG9mIGl0IG1pZ2h0IGtub3cKdGhhdCBhIGRhdGEgbm9kZSBpcyBwYXJ0 IG9mIHRoZSBzY2hlbWEgdHJlZSBhbmQgbm90aGluZyB0byBkbyB3aXRoIHRoZSBkYXRhCnRyZWUu ICBXaGljaCBtYWtlcyBpdHMgdXNlIGhlcmUgcG90ZW50aWFsbHkgY29uZnVzaW5nIHRvIG1lIHNp bmNlIG1vc3QgaWYgbm90CmFsbCB1c2VzIG9mIGl0IHNlZW0gdG8gcmVmZXIgdG8gbm9kZXMvbGVh dmVzIGluIHRoZSBkYXRhIHRyZWUuLiAgQXMKKGhlYWQtYmFuZ2luZykgUmFuZHkgaGFzIHBvaW50 ZWQgb3V0LCB5b3UgY2Fubm90IG5vdCBoYXZlIGEgbWV0YS1tb2RlbCBvZiB0aGUKZGF0YSBmb3Ig YW4gSS1EIGxpa2UgdGhpcyBvbmUsIGFuZCBpZiBpdCBpcyBkaWZmZXJlbnQgdG8gWUFORywgdGhl biBJIHRoaW5rIHRoYXQKdGhhdCBuZWVkcyBzcGVsbGluZyBvdXQuICBBIGZldyB5ZWFycyBhZ28s IEkgd291bGQgaGF2ZSBzYWlkIHRoYXQgdGhpcyB3YXMKdW5uZWNlc3NhcnkgYnV0IHRoZSBZQU5H IEktRCB3aXRoIGl0cyBkaWZmZXJlbnQgKHRvIG1lKSBkZWZpbml0aW9uIG9mIGRhdGEgbm9kZQpo YXMgY2hhbmdlZCB0aGF0LgoKQW4gYWxsaWVkIHByb2JsZW0gaXMgdGhhdCB0aGlzIHJlZmVyZW5j ZXMgUkZDNDc0MSBmb3IgYSBkZWZpbml0aW9uIG9mIGRhdGFzdG9yZQphbmQgeWV0IHRoYXQgdGVy bSBpcyBub3QgZGVmaW5lZCB0aGVyZS4gIFJhdGhlciwgUkZDNDc0MSAoYWxtb3N0KSBhbHdheXMg dXNlcwpjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBzbyBJIHRoaW5rIHRoYXQgdGhpcyBJLUQgc2hv dWxkIGRvIHNvIGFzIHdlbGwgb3IgZWxzZQoocmUtKWRlZmluZSBkYXRhc3RvcmUuCgpBbmQgd2hh dGV2ZXIgaXMgaW4gdGhhdCBkYXRhIG5vZGUgc2VlbXMgdG8gYmUgZGVzY3JpYmVkIGluIG1hbnkg d2F5czsgaWYgdGhlc2UKYXJlIHRoZSBzYW1lLCB0aGVuIEkgZmluZCB0aGF0IGNvbmZ1c2luZywg aWYgZGlmZmVyZW50LCBJIGFtIGNvbmZ1c2VkLiAgSSBzZWUKdGhlc2UgdGhpbmdpZXMgaW4gdGhl IGRhdGEgdHJlZSBoYXZpbmcgYSAnbWF0Y2gnIG9yICdzZXQnIG9yICdjb250YWluJyBvciAnaGFz JwpvciAncmVwcmVzZW50JyBvciAuLi4gcmVsYXRpb25zaGlwIHRvIHRoZSBkZWZhdWx0IHZhbHVl cyBlLmcuCgogaGF2ZSBhIGxhcmdlIG51bWJlciBvZiBkZWZhdWx0IHZhbHVlcwogYSBkYXRhIG5v ZGUgdGhhdCBjb250YWlucyBpdHMgc2NoZW1hIGRlZmF1bHQKIGFueSBkYXRhIG5vZGUgc2V0IHRv IGl0cyBzY2hlbWEgZGVmYXVsdCB2YWx1ZSB0byBiZSBkZWZhdWx0IGRhdGEuCiByZXByZXNlbnRl ZCBieSBhIHNjaGVtYSBkZWZhdWx0IHZhbHVlCiAgdGhleSBtYXRjaCB0aGUgc2NoZW1hIGRlZmF1 bHQgdmFsdWUKCldoYXRldmVyIHRoZSByZWxhdGlvbnNoaXAgaXMsIEkgdGhpbmsgdGhhdCBvbmx5 IG9uZSB2ZXJiIHNob3VsZCBiZSB1c2VkIHRvCnBvcnRyYXkgaXQsIHVubGVzcyBhIGRpc3RpbmN0 aW9uIGlzIGJlaW5nIGRyYXduICh3aGljaCB0aGVyZSBjb3VsZCBiZSBpbiBzb21lCmJ1dCBub3Qg YWxsIHVzZXMgb2YgJ3NldCcpIGllIHdlIGhhdmUgYSAnZGF0YSB0cmVlJywgaXQgY29uc2lzdHMg b2YgJ2xlYWYgKGZvby8KYmFyLyAgLi4uKSBub2RlcycgYW5kIHRoZXkgJ2hhdmUgKC9jb250YWlu LyAuLi4pJyB2YWx1ZXMuCgpUaGlzIHByb2JhYmx5IHNlZW1zIHRyaXZpYWwgdG8geW91IHdobyBo YXZlIGxpdmVkIHdpdGggdGhpcyBmb3Igc2V2ZXJhbCBtb250aHMsCmJ1dCB0byBzb21lb25lIGNv bWluZyB0byBpdCBhZnJlc2gsIG9yIGNvbWluZyBiYWNrIGFmdGVyIGEgaGlhdHVzIG9mIHNvbWUK bW9udGhzLCBJIHRoaW5rIHRoaXMgYSBzaWduaWZpY2FudCBwcm9ibGVtIG9mIGNvbXByZWhlbnNp b24uICBBbmQgaXQgaXMgbm90IGFzCmlmIHRoZSBzZW1hbnRpY3MgYmVpbmcgZGVzY3JpYmVkIGFy ZSBmYW1pbGlhciBvciBlYXN5IHRvIGZvbGxvdyEKClRvbSBQZXRjaAoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0 Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYKCg== ------=_Part_2_1281449510806 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5UaGVzZSBjb21tZW50cyBzZWVtIGxpa2UgbWlub3Igbml0cy4gJm5ic3A7Tm90 IHN1cmUgd2hhdCB5b3Ugd2FudCB0byBjaGFuZ2UuICZuYnNwO0kgZG9uJiMzOTt0IHRoaW5rIHRo ZSB2ZXJiIHVzYWdlIGlzIGNvbmZ1c2luZywgYnV0IEkgd2lsbCBsb29rIGF0IGFsaWduaW5nIG1v cmUgY2xvc2VseSB3aXRoIDQ3NDEgYW5kIHRoZSBZQU5HIGRyYWZ0Ljxicj48YnI+QW5keTxicj48 YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDt0LnBldGNoJnF1b3Q7 ICZsdDtpZXRmY0BidGNvbm5lY3QuY29tJmd0Ozxicj5EYXRlOiBUdWUsIEF1ZyAxMCwgMjAxMCAw MToxMDxicj5TdWJqZWN0OiBbTmV0Y29uZl0gc3RhdHVzIG9mIHdpdGgtZGVmYXVsdHM8YnI+VG86 ICZxdW90O0JlcnQgXChJRVRGXCkgV2lqbmVuJnF1b3Q7ICZsdDtiZXJ0aWV0ZkBid2lqbmVuLm5l dCZndDssICZxdW90O25ldGNvbmYmcXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPjxi cj5JIGFtIHVuY2xlYXIgd2hlcmUgd2l0aC1kZWZhdWx0cyBnb3QgdG8uICZuYnNwO1RoZXJlIHdh cyBhIExhc3QgQ2FsbCB3aGljaCBzZWVtZWQgdG88YnI+cGV0ZXIgb3V0LCBhIG5ldyB2ZXJzaW9u IGFwcGVhcmVkIHBpY2tpbmcgdXAgc29tZSBidXQgbm90IGFsbCBvZiB0aGUgY29tbWVudHM8YnI+ YW5kIC4uLjxicj48YnI+SSBzdGlsbCBoYXZlIHByb2JsZW1zIG9mIGNvbXByZWhlbnNpb24gd2l0 aCB0aGlzIEktRCwgYXMgcGVyaGFwcyBNYXJ0aW4gYWxsdWRlZDxicj50byBpbiBoaXMgY29tbWVu dHMuPGJyPjxicj5Ud28gYXJlYXMuPGJyPjxicj5EYXRhIG5vZGVzLiAmbmJzcDtUaGlzIEktRCBy ZWZlcmVuY2VzIHRoZSBZQU5HIEktRCwgYW5kIHNvIHVzZXJzIG9mIGl0IG1pZ2h0IGtub3c8YnI+ dGhhdCBhIGRhdGEgbm9kZSBpcyBwYXJ0IG9mIHRoZSBzY2hlbWEgdHJlZSBhbmQgbm90aGluZyB0 byBkbyB3aXRoIHRoZSBkYXRhPGJyPnRyZWUuICZuYnNwO1doaWNoIG1ha2VzIGl0cyB1c2UgaGVy ZSBwb3RlbnRpYWxseSBjb25mdXNpbmcgdG8gbWUgc2luY2UgbW9zdCBpZiBub3Q8YnI+YWxsIHVz ZXMgb2YgaXQgc2VlbSB0byByZWZlciB0byBub2Rlcy9sZWF2ZXMgaW4gdGhlIGRhdGEgdHJlZS4u ICZuYnNwO0FzPGJyPihoZWFkLWJhbmdpbmcpIFJhbmR5IGhhcyBwb2ludGVkIG91dCwgeW91IGNh bm5vdCBub3QgaGF2ZSBhIG1ldGEtbW9kZWwgb2YgdGhlPGJyPmRhdGEgZm9yIGFuIEktRCBsaWtl IHRoaXMgb25lLCBhbmQgaWYgaXQgaXMgZGlmZmVyZW50IHRvIFlBTkcsIHRoZW4gSSB0aGluayB0 aGF0PGJyPnRoYXQgbmVlZHMgc3BlbGxpbmcgb3V0LiAmbmJzcDtBIGZldyB5ZWFycyBhZ28sIEkg d291bGQgaGF2ZSBzYWlkIHRoYXQgdGhpcyB3YXM8YnI+dW5uZWNlc3NhcnkgYnV0IHRoZSBZQU5H IEktRCB3aXRoIGl0cyBkaWZmZXJlbnQgKHRvIG1lKSBkZWZpbml0aW9uIG9mIGRhdGEgbm9kZTxi cj5oYXMgY2hhbmdlZCB0aGF0Ljxicj48YnI+QW4gYWxsaWVkIHByb2JsZW0gaXMgdGhhdCB0aGlz IHJlZmVyZW5jZXMgUkZDNDc0MSBmb3IgYSBkZWZpbml0aW9uIG9mIGRhdGFzdG9yZTxicj5hbmQg eWV0IHRoYXQgdGVybSBpcyBub3QgZGVmaW5lZCB0aGVyZS4gJm5ic3A7UmF0aGVyLCBSRkM0NzQx IChhbG1vc3QpIGFsd2F5cyB1c2VzPGJyPmNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIHNvIEkgdGhp bmsgdGhhdCB0aGlzIEktRCBzaG91bGQgZG8gc28gYXMgd2VsbCBvciBlbHNlPGJyPihyZS0pZGVm aW5lIGRhdGFzdG9yZS48YnI+PGJyPkFuZCB3aGF0ZXZlciBpcyBpbiB0aGF0IGRhdGEgbm9kZSBz ZWVtcyB0byBiZSBkZXNjcmliZWQgaW4gbWFueSB3YXlzOyBpZiB0aGVzZTxicj5hcmUgdGhlIHNh bWUsIHRoZW4gSSBmaW5kIHRoYXQgY29uZnVzaW5nLCBpZiBkaWZmZXJlbnQsIEkgYW0gY29uZnVz ZWQuICZuYnNwO0kgc2VlPGJyPnRoZXNlIHRoaW5naWVzIGluIHRoZSBkYXRhIHRyZWUgaGF2aW5n IGEgJiMzOTttYXRjaCYjMzk7IG9yICYjMzk7c2V0JiMzOTsgb3IgJiMzOTtjb250YWluJiMzOTsg b3IgJiMzOTtoYXMmIzM5Ozxicj5vciAmIzM5O3JlcHJlc2VudCYjMzk7IG9yIC4uLiByZWxhdGlv bnNoaXAgdG8gdGhlIGRlZmF1bHQgdmFsdWVzIGUuZy48YnI+PGJyPiBoYXZlIGEgbGFyZ2UgbnVt YmVyIG9mIGRlZmF1bHQgdmFsdWVzPGJyPiBhIGRhdGEgbm9kZSB0aGF0IGNvbnRhaW5zIGl0cyBz Y2hlbWEgZGVmYXVsdDxicj4gYW55IGRhdGEgbm9kZSBzZXQgdG8gaXRzIHNjaGVtYSBkZWZhdWx0 IHZhbHVlIHRvIGJlIGRlZmF1bHQgZGF0YS48YnI+IHJlcHJlc2VudGVkIGJ5IGEgc2NoZW1hIGRl ZmF1bHQgdmFsdWU8YnI+ICZuYnNwO3RoZXkgbWF0Y2ggdGhlIHNjaGVtYSBkZWZhdWx0IHZhbHVl PGJyPjxicj5XaGF0ZXZlciB0aGUgcmVsYXRpb25zaGlwIGlzLCBJIHRoaW5rIHRoYXQgb25seSBv bmUgdmVyYiBzaG91bGQgYmUgdXNlZCB0bzxicj5wb3J0cmF5IGl0LCB1bmxlc3MgYSBkaXN0aW5j dGlvbiBpcyBiZWluZyBkcmF3biAod2hpY2ggdGhlcmUgY291bGQgYmUgaW4gc29tZTxicj5idXQg bm90IGFsbCB1c2VzIG9mICYjMzk7c2V0JiMzOTspIGllIHdlIGhhdmUgYSAmIzM5O2RhdGEgdHJl ZSYjMzk7LCBpdCBjb25zaXN0cyBvZiAmIzM5O2xlYWYgKGZvby88YnI+YmFyLyAmbmJzcDsuLi4p IG5vZGVzJiMzOTsgYW5kIHRoZXkgJiMzOTtoYXZlICgvY29udGFpbi8gLi4uKSYjMzk7IHZhbHVl cy48YnI+PGJyPlRoaXMgcHJvYmFibHkgc2VlbXMgdHJpdmlhbCB0byB5b3Ugd2hvIGhhdmUgbGl2 ZWQgd2l0aCB0aGlzIGZvciBzZXZlcmFsIG1vbnRocyw8YnI+YnV0IHRvIHNvbWVvbmUgY29taW5n IHRvIGl0IGFmcmVzaCwgb3IgY29taW5nIGJhY2sgYWZ0ZXIgYSBoaWF0dXMgb2Ygc29tZTxicj5t b250aHMsIEkgdGhpbmsgdGhpcyBhIHNpZ25pZmljYW50IHByb2JsZW0gb2YgY29tcHJlaGVuc2lv bi4gJm5ic3A7QW5kIGl0IGlzIG5vdCBhczxicj5pZiB0aGUgc2VtYW50aWNzIGJlaW5nIGRlc2Ny aWJlZCBhcmUgZmFtaWxpYXIgb3IgZWFzeSB0byBmb2xsb3chPGJyPjxicj5Ub20gUGV0Y2g8YnI+ PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk5l dGNvbmYgbWFpbGluZyBsaXN0PGJyPk5ldGNvbmZAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJyPjxicj48YnI+PGJyPg== ------=_Part_2_1281449510806-- From ietfc@btconnect.com Tue Aug 10 09:58:27 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4744F3A68F3 for ; Tue, 10 Aug 2010 09:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsJrgI+1Htam for ; Tue, 10 Aug 2010 09:58:26 -0700 (PDT) Received: from c2bthomr07.btconnect.com (c2bthomr07.btconnect.com [213.123.20.125]) by core3.amsl.com (Postfix) with ESMTP id DB2A13A684B for ; Tue, 10 Aug 2010 09:58:25 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2bthomr07.btconnect.com with SMTP id GAT08967; Tue, 10 Aug 2010 17:58:54 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C61854E.0206, actions=tag Message-ID: <00b401cb38a4$485df420$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Martin Bjorklund" References: <20100715.223708.89993877.mbj@tail-f.com><80A0822C5E9A4440A5117C2F4CD36A64B5FA33@DEMUEXC006.nsn-intra.net><20100716160414.GA16609@elstar.local><20100721.112102.46225805.mbj@tail-f.com> <20100721132327.GB99067@elstar.local> Date: Tue, 10 Aug 2010 17:54:09 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0201.4C61854F.0198,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] network-wide NETCONF X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:58:27 -0000 A belated thought ... Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Martin Bjorklund" Cc: Sent: Wednesday, July 21, 2010 3:23 PM Subject: Re: [Netconf] network-wide NETCONF > On Wed, Jul 21, 2010 at 11:21:02AM +0200, Martin Bjorklund wrote: > > > > I agree with other speakers that we should not try to do the one and > > only uber-network model. Instead, I think we (i.e. IETF) should do > > concrete YANG models for our own areas. We have used OSPF as one > > example in the past - ideally there would be one YANG model for how to > > configure OSPF in devices, and one YANG model for how to configure > > OSPF in a network of devices. Realistically, the mapping between > > these models is defined in text. This would be a huge step forward > > compared to abstract UML models mapped to different CLI flavours. > > I understand a YANG model for devices running OSPF. I see value in a > description how the OSPF device model can be used to achieve robust > network-wide configuration. It still escapes me what a network wide > YANG model for OSPF would be. A device model for OSPF would say that a router has a 32 bit router id. A network wide model says that it is unique within a domain. A device model says that each interface has Hello/Dead timers (default!) A network wide model says that each interface on a link must have the same two values. A device model says that each interface is in a numbered area. A network wide model says that there the area number must come from a list which includes zero and that each interface on a link must share the same value. etc etc There are network (domain) wide rules without which OSPF will not work and which could be expressed in a modelling language You could do something similar for BGP, and for access control rules. > Lets face it, the IETF is crowded by device geeks, not by people who > have insights how real-world configuration databases look like and > those who have insights might not be willing to share those insights > for obvious business reasons. > > /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 ietfc@btconnect.com Tue Aug 10 10:08:21 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD7C13A68F3 for ; Tue, 10 Aug 2010 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tdoLzc2jUTx for ; Tue, 10 Aug 2010 10:08:20 -0700 (PDT) Received: from c2bthomr10.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by core3.amsl.com (Postfix) with ESMTP id 5B9CC3A685F for ; Tue, 10 Aug 2010 10:08:20 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2bthomr10.btconnect.com with SMTP id FYN13367; Tue, 10 Aug 2010 18:08:49 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0301.4C6187A0.02C6, actions=tag Message-ID: <010501cb38a5$ad02eb00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Bert \(IETF\) Wijnen" , "netconf" , "Andy Bierman" References: <09.9F.21551.71E516C4@cm-omr2> Date: Tue, 10 Aug 2010 18:04:02 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0202.4C6187A5.02EB,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] status of with-defaults X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:08:21 -0000 ----- Original Message ----- From: "Andy Bierman" To: "t.petch" ; "Bert (IETF) Wijnen" ; "netconf" Sent: Tuesday, August 10, 2010 4:11 PM > Hi, > > These comments seem like minor nits. Not sure what you want to change. I don't think the verb usage is confusing, but I will look at aligning more closely with 4741 and the YANG draft. Andy My comments are not intended to change the meaning, rather make it easier to see what it is, by using a (more) consistent terminology. I do think that some, perhaps many, I-Ds make perfect sense to those who have been immersed in them for a while, whereas someone coming afresh, or after a hiatus - me on this occasion - sees potential ambiguities or contradictions more clearly. I read those different verbs and wonder if I am missing a semantic difference; I like variety in my chick lit, I don't in my technical specifications! Tom Petch > Andy > > ----- Reply message ----- > From: "t.petch" > Date: Tue, Aug 10, 2010 01:10 > Subject: [Netconf] status of with-defaults > To: "Bert \(IETF\) Wijnen" , "netconf" > > I am unclear where with-defaults got to. There was a Last Call which seemed to > peter out, a new version appeared picking up some but not all of the comments > and ... > > I still have problems of comprehension with this I-D, as perhaps Martin alluded > to in his comments. > > Two areas. > > Data nodes. This I-D references the YANG I-D, and so users of it might know > that a data node is part of the schema tree and nothing to do with the data > tree. Which makes its use here potentially confusing to me since most if not > all uses of it seem to refer to nodes/leaves in the data tree.. As > (head-banging) Randy has pointed out, you cannot not have a meta-model of the > data for an I-D like this one, and if it is different to YANG, then I think that > that needs spelling out. A few years ago, I would have said that this was > unnecessary but the YANG I-D with its different (to me) definition of data node > has changed that. > > An allied problem is that this references RFC4741 for a definition of datastore > and yet that term is not defined there. Rather, RFC4741 (almost) always uses > configuration datastore so I think that this I-D should do so as well or else > (re-)define datastore. > > And whatever is in that data node seems to be described in many ways; if these > are the same, then I find that confusing, if different, I am confused. I see > these thingies in the data tree having a 'match' or 'set' or 'contain' or 'has' > or 'represent' or ... relationship to the default values e.g. > > have a large number of default values > a data node that contains its schema default > any data node set to its schema default value to be default data. > represented by a schema default value > they match the schema default value > > Whatever the relationship is, I think that only one verb should be used to > portray it, unless a distinction is being drawn (which there could be in some > but not all uses of 'set') ie we have a 'data tree', it consists of 'leaf (foo/ > bar/ ...) nodes' and they 'have (/contain/ ...)' values. > > This probably seems trivial to you who have lived with this for several months, > but to someone coming to it afresh, or coming back after a hiatus of some > months, I think this a significant problem of comprehension. And it is not as > if the semantics being described are familiar or easy to follow! > > Tom Petch > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From bwijnen@ripe.net Tue Aug 10 09:02:39 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 550FA3A695B for ; Tue, 10 Aug 2010 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, MIME_BAD_LINEBREAK=0.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IImD7yq6dSKC for ; Tue, 10 Aug 2010 09:02:37 -0700 (PDT) Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:610:240:11::c100:1342]) by core3.amsl.com (Postfix) with ESMTP id C7EF63A6995 for ; Tue, 10 Aug 2010 09:02:36 -0700 (PDT) Received: from dodo.ripe.net ([193.0.1.102]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1OirI8-0003IS-6M; Tue, 10 Aug 2010 18:03:10 +0200 Received: from vifa-1.office-lb-1.ripe.net ([193.0.1.5] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1OirI7-00060K-S7; Tue, 10 Aug 2010 18:03:04 +0200 Message-ID: <4C617837.6070208@ripe.net> Date: Tue, 10 Aug 2010 18:03:03 +0200 From: Bert Wijnen User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Content-Type: multipart/mixed; boundary="------------040003090900040700090403" X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e08968c077b2bb100ae8569bd06372ad9 X-RIPE-Spam-Level: -- X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e08968c077b2bb100ae8569bd06372ad9 X-Mailman-Approved-At: Tue, 10 Aug 2010 11:07:12 -0700 Cc: netconf Subject: [Netconf] Pls bring this new NETCONF WG charter to the IESG for approval. X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:02:39 -0000 This is a multi-part message in MIME format. --------------040003090900040700090403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The charter is also attached as an ASCIi txt file. Bert and Mehmet --------------- rquested approval for this new charter: Network Configuration (netconf) ------------------------------- Charter Current Status: Active Chairs: Bert Wijnen Mehmet Ersue Operations and Management Area Directors: Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu 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. 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. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work was started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). 2. A technical errata has been posted on rfc4742. The work on rfc4741bis also uncovered some additional fixes/clarifications that need to be made to rfc4742, the WG has been working on rfc4742bis and is nearly done with this work item. 3. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 4. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 5. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. Goals and Milestones: Aug 2010 - Send with-defaults to IESG for consideration as Proposed Standard Aug 2010 - WG Last Call on rfc4741bis Sep 2010 - rfc4741bis to IESG for consideration as Proposed Standard Sep 2010 - Send rfc4742bis to IESG for consideration as proposed Standard. Sep 2010 - first WG draft (rev 00) on NACM posted Sep 2010 - first WG draft (rev 00) on NETCONF specific YANG modules posted Jan 2011 - WGLC for NACM document Jan 2011 - WGLC for NETCONF specific notifications document Mar 2011 - (if needed last) WGLC for NACM document Mar 2011 - (if needed last) WGLC for NETCONF specific notifications document Apr 2011 - submit NACM document to IESG for consideration as Proposed Standard Apr 2011 - submit NETCONF specific notifications document to IESG for consideration as Proposed Standard --------------040003090900040700090403 Content-Type: text/plain; name="netconf-charter-2010-aug-10.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="netconf-charter-2010-aug-10.txt" TmV0d29yayBDb25maWd1cmF0aW9uIChuZXRjb25mKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCgogQ2hhcnRlcgoKIEN1cnJlbnQgU3RhdHVzOiBBY3RpdmUKCiBDaGFpcnM6 CiAgICAgQmVydCBXaWpuZW4gPGJlcnRpZXRmQGJ3aWpuZW4ubmV0PgogICAgIE1laG1ldCBF cnN1ZSA8bWVobWV0LmVyc3VlQG5zbi5jb20+CgogT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVu dCBBcmVhIERpcmVjdG9yczoKICAgICBEYW4gUm9tYXNjYW51IDxkcm9tYXNjYUBhdmF5YS5j b20+CiAgICAgUm9uYWxkIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4KCiBPcGVyYXRp b25zIGFuZCBNYW5hZ2VtZW50IEFyZWEgQWR2aXNvcjoKICAgICBEYW4gUm9tYXNjYW51IDxk cm9tYXNjYUBhdmF5YS5jb20+CgogTWFpbGluZyBMaXN0czoKICAgICBHZW5lcmFsIERpc2N1 c3Npb246IG5ldGNvbmZAaWV0Zi5vcmcKICAgICBUbyBTdWJzY3JpYmU6ICAgICAgIG5ldGNv bmYtcmVxdWVzdEBpZXRmLm9yZwogICAgICAgIG9yOiAgICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCiAgICAgQXJjaGl2ZTogICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi8K CkRlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXA6CgogIENvbmZpZ3VyYXRpb24gb2YgbmV0 d29ya3Mgb2YgZGV2aWNlcyBoYXMgYmVjb21lIGEgY3JpdGljYWwgcmVxdWlyZW1lbnQKICBm b3Igb3BlcmF0b3JzIGluIHRvZGF5J3MgaGlnaGx5IGludGVyb3BlcmFibGUgbmV0d29ya3Mu IE9wZXJhdG9ycyBmcm9tCiAgbGFyZ2UgdG8gc21hbGwgaGF2ZSBkZXZlbG9wZWQgdGhlaXIg b3duIG1lY2hhbmlzbXMgb3IgdXNlZCB2ZW5kb3IKICBzcGVjaWZpYyBtZWNoYW5pc21zIHRv IHRyYW5zZmVyIGNvbmZpZ3VyYXRpb24gZGF0YSB0byBhbmQgZnJvbSBhCiAgZGV2aWNlLCBh bmQgZm9yIGV4YW1pbmluZyBkZXZpY2Ugc3RhdGUgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGlt cGFjdAogIHRoZSBjb25maWd1cmF0aW9uLiBFYWNoIG9mIHRoZXNlIG1lY2hhbmlzbXMgbWF5 IGJlIGRpZmZlcmVudCBpbgogIHZhcmlvdXMgYXNwZWN0cywgc3VjaCBhcyBzZXNzaW9uIGVz dGFibGlzaG1lbnQsIHVzZXIgYXV0aGVudGljYXRpb24sCiAgY29uZmlndXJhdGlvbiBkYXRh IGV4Y2hhbmdlLCBhbmQgZXJyb3IgcmVzcG9uc2VzLgoKICBUaGUgTkVUQ09ORiBXb3JraW5n IEdyb3VwIGhhcyBwcm9kdWNlZCBhIHByb3RvY29sIHN1aXRhYmxlIGZvcgogIG5ldHdvcmsg Y29uZmlndXJhdGlvbiwgd2l0aCB0aGUgZm9sbG93aW5nIGNoYXJhY3RlcmlzdGljczoKCiAg LSBQcm92aWRlcyByZXRyaWV2YWwgbWVjaGFuaXNtcyB3aGljaCBjYW4gZGlmZmVyZW50aWF0 ZSBiZXR3ZWVuCiAgICBjb25maWd1cmF0aW9uIGRhdGEgYW5kIG5vbi1jb25maWd1cmF0aW9u IGRhdGEKICAtIElzIGV4dGVuc2libGUgZW5vdWdoIHNvIHRoYXQgdmVuZG9ycyBjYW4gcHJv dmlkZSBhY2Nlc3MgdG8gYWxsCiAgICBjb25maWd1cmF0aW9uIGRhdGEgb24gdGhlIGRldmlj ZSB1c2luZyBhIHNpbmdsZSBwcm90b2NvbAogIC0gSGFzIGEgcHJvZ3JhbW1hdGljIGludGVy ZmFjZSAoYXZvaWRzIHNjcmVlbiBzY3JhcGluZyBhbmQKICAgIGZvcm1hdHRpbmctcmVsYXRl ZCBjaGFuZ2VzIGJldHdlZW4gcmVsZWFzZXMpCiAgLSBVc2VzIGFuIFhNTC1iYXNlZCBkYXRh IHJlcHJlc2VudGF0aW9uLCB0aGF0IGNhbiBiZSBlYXNpbHkgbWFuaXB1bGF0ZWQNICAgIHVz aW5nIG5vbi1zcGVjaWFsaXplZCBYTUwgbWFuaXB1bGF0aW9uIHRvb2xzLg0KICAtIFN1cHBv cnRzIGludGVncmF0aW9uIHdpdGggZXhpc3RpbmcgdXNlciBhdXRoZW50aWNhdGlvbiBtZXRo b2RzCiAgLSBTdXBwb3J0cyBpbnRlZ3JhdGlvbiB3aXRoIGV4aXN0aW5nIGNvbmZpZ3VyYXRp b24gZGF0YWJhc2Ugc3lzdGVtcwogIC0gU3VwcG9ydHMgbXVsdGlwbGUgKGUuZy4gY2FuZGlk YXRlIGFuZCBydW5uaW5nKSBkYXRhLXN0b3JlcyB0bwogICAgb3B0aW1pemUgY29uZmlndXJh dGlvbiBwcmVwYXJhdGlvbiBhbmQgYWN0aXZhdGlvbiANCiAgLSBTdXBwb3J0cyBuZXR3b3Jr IHdpZGUgY29uZmlndXJhdGlvbiB0cmFuc2FjdGlvbnMgKHdpdGggZmVhdHVyZXMgc3VjaAog ICAgYXMgbG9ja2luZyBhbmQgcm9sbGJhY2sgY2FwYWJpbGl0eSkKICAtIFJ1bnMgb3ZlciBh IHNlY3VyZSB0cmFuc3BvcnQ7IFNTSCBpcyBtYW5kYXRvcnkgdG8gaW1wbGVtZW50DSAgICB3 aGlsZSBUTFMsIEJFRVAsIGFuZCBTT0FQIGFyZSBvcHRpb25hbCB0cmFuc3BvcnRzLg0gIC0g UHJvdmlkZXMgc3VwcG9ydCBmb3IgYXN5bmNocm9ub3VzIG5vdGlmaWNhdGlvbnMuCgogIFRo ZSBORVRDT05GIHByb3RvY29sIGhhcyBiZWVuIGRlc2lnbmVkIGluZGVwZW5kZW50IG9mIHRo ZSBkYXRhIA0gIG1vZGVsaW5nIGxhbmd1YWdlLiBUaGUgSUVURiByZWNvbW1lbmRzIHRvIHVz ZSBZQU5HIGFzIHRoZSBORVRDT05GDSAgbW9kZWxpbmcgbGFuZ3VhZ2UsIHdoaWNoIGludHJv ZHVjZXMgYWR2YW5jZWQgbGFuZ3VhZ2UgZmVhdHVyZXMgZm9yIA0gIGNvbmZpZ3VyYXRpb24g bWFuYWdlbWVudC4KCiAgSW4gdGhlIGN1cnJlbnQgcGhhc2Ugb2YgdGhlIGluY3JlbWVudGFs IGRldmVsb3BtZW50IG9mIE5FVENPTkYgdGhlCiAgd29ya2dyb3VwIHdpbGwgZm9jdXMgb24g Zm9sbG93aW5nIGl0ZW1zOgoKICAxLiBORVRDT05GIGltcGxlbWVudGF0aW9ucyBoYXZlIHNo b3duIHRoYXQgdGhlIHNwZWNpZmljYXRpb24gaW4gUkZDNDc0MQogICAgIGlzIG5vdCAxMDAl IGNsZWFyIGFuZCBoYXMgbGVhZCB0byBkaWZmZXJlbnQgaW50ZXJwcmV0YXRpb25zIGFuZAog ICAgIGltcGxlbWVudGF0aW9ucy4gQWxzbyBzb21lIGVycm9ycyBoYXZlIGJlZW4gdW5jb3Zl cmVkLiBTbyB0aGUgV0cKICAgICB3aWxsIGRvIGFuIHJmYzQ3NDFiaXMgd2l0aCBmb2xsb3dp bmcgY29uc3RyYWludHM6CgogICAgICAgLSBidWcgZml4ZXMgYXJlIHRvIGJlIGRvbmUKICAg ICAgIC0gY2xhcmlmaWNhdGlvbnMgY2FuIGJlIGRvbmUKICAgICAgIC0gZXh0ZW5zaW9ucyBj YW4gYmUgZG9uZSBvbmx5IHdoZW4gbmVlZGVkIHRvIGZpeCBidWdzCiAgICAgICAgIG9yIGlu Y29uc2lzdGVuY2llcyAoaS5lLiB3ZSBhcmUgbm90IGRvaW5nIGEgTkVUQ09ORiBWMikKICAg ICAgIC0gVGhlIHdvcmsgd2FzIHN0YXJ0ZWQgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gaW4g SUVURiAjNzMgKHNlZQogICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz LzA4bm92L3NsaWRlcy9uZXRjb25mLTMucGRmKS4KCiAgMi4gQSB0ZWNobmljYWwgZXJyYXRh IGhhcyBiZWVuIHBvc3RlZCBvbiByZmM0NzQyLiBUaGUgd29yayBvbiAKICAgICByZmM0NzQx YmlzIGFsc28gdW5jb3ZlcmVkIHNvbWUgYWRkaXRpb25hbCBmaXhlcy9jbGFyaWZpY2F0aW9u cyB0aGF0CiAgICAgbmVlZCB0byBiZSBtYWRlIHRvIHJmYzQ3NDIsIHRoZSBXRyBoYXMgYmVl biB3b3JraW5nIG9uIHJmYzQ3NDJiaXMKICAgICBhbmQgaXMgbmVhcmx5IGRvbmUgd2l0aCB0 aGlzIHdvcmsgaXRlbS4KCiAgMy4gTmV0Y29uZiBBY2Nlc3MgQ29udHJvbCBNb2RlbCAoTkFD TSkgUmVxdWlyZW1lbnRzIGFuZCBTb2x1dGlvbi4KICAKICAgICBUaGVyZSBpcyBhIG5lZWQg Zm9yIHN0YW5kYXJkIG1lY2hhbmlzbXMgdG8gcmVzdHJpY3QgCiAgICAgTkVUQ09ORiBwcm90 b2NvbCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNlcnMgdG8gYSBwcmUtICAKICAgICBjb25m aWd1cmVkIChieSBvcGVyYXRvcikgc3Vic2V0IG9mIGFsbCBhdmFpbGFibGUgTkVUQ09ORgog ICAgIG9wZXJhdGlvbnMgYW5kIGNvbnRlbnQuIAoKICAgICBUaGUgV0cgd2lsbCBwcm9kdWNl IGEgZG9jdW1lbnQgd2hpY2ggaWRlbnRpZmllcyB0aGUgYWNjZXNzIAogICAgIGNvbnRyb2wg cmVxdWlyZW1lbnRzIHNwZWNpZmljIHRvIHRoZSBORVRDT05GIHByb3RvY29sLCBhcyAKICAg ICBkZWZpbmVkIGluIFs0NzQxYmlzXS4gIFRoaXMgZG9jdW1lbnQgd2lsbCBhbHNvIHByb3Zp ZGUgYSAKICAgICBzdGFuZGFyZCBZQU5HIGRhdGEgbW9kZWwgd2hpY2ggYWRkcmVzc2VzIHRo ZXNlIAogICAgIHJlcXVpcmVtZW50cy4gCiAKICAgICBJdCBpcyBwb3NzaWJsZSB0aGF0IHRo ZSBXRyB3aWxsIG5vdCByZWFjaCBzb2x1dGlvbiBjb25zZW5zdXMKICAgICBvbiBldmVyeSBw b3NzaWJsZSByZXF1aXJlbWVudCBpZGVudGlmaWVkIGluIHRoZSBkb2N1bWVudC4KICAgICBJ biB0aGlzIGNhc2UsIGl0IGlzIGV4cGVjdGVkIHRoYXQgdGhlIHNvbHV0aW9uIHdpbGwgZXZv bHZlCiAgICAgb3ZlciB0aW1lIHRvIG1lZXQgdGhlIHRoZSByZW1haW5pbmcgdW5tZXQgcmVx dWlyZW1lbnRzLgoKICA0LiBUaGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IHdhbnQgdG8gbm90aWZ5 IGludGVyZXN0ZWQgY2xpZW50cyBhYm91dA0gICAgIHBhcnRpY3VsYXIgTkVUQ09ORiBwcm90 b2NvbC9zZXJ2ZXIgZXZlbnRzLiAgVGhlIFdHIHdpbGwgd29yayBvbg0gICAgIGEgTkVUQ09O RiBzcGVjaWZpYyBZQU5HIG1vZHVsZShzKSB0byBkZWZpbmUgc3VpdGFibGUNICAgICBub3Rp ZmljYXRpb25zLg0NICA1LiBBcyBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBleHBl cmllbmNlIGdhaW5lZCB3aXRoIHRoZQ0gICAgIE5FVENPTkYgbW9uaXRvcmluZyBkYXRhIG1v ZGVsLCB0aGUgV0cgbWF5IHJldmlzZSB0aGUgTkVUQ09ORg0gICAgIG1vbml0b3JpbmcgZGF0 YSBtb2RlbCB0byBhZGQgYWRkaXRpb25hbCBvYmplY3RzIHRoYXQgY2FuIGJlIHVzZWQNICAg ICB0byBjaGVjayB0aGUgc3RhdHVzIG9mIHRoZSBzZXJ2ZXIgYW5kIHRvIGRpc2NvdmVyIGFk ZGl0aW9uYWwNICAgICBpbmZvcm1hdGlvbiBhYm91dCB0aGUgc2VydmVyIGltcGxlbWVudGF0 aW9uLiBUaGUgV0cgbWF5IGNob29zZQ0gICAgIHRvIHJldmlzZSB0aGUgTkVUQ09ORiBtb25p dG9yaW5nIGRhdGEgbW9kZWwuCgpHb2FscyBhbmQgTWlsZXN0b25lczoKICBBdWcgMjAxMCAt IFNlbmQgd2l0aC1kZWZhdWx0cyB0byBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIFByb3Bv c2VkIFN0YW5kYXJkCiAgQXVnIDIwMTAgLSBXRyBMYXN0IENhbGwgb24gcmZjNDc0MWJpcwog IFNlcCAyMDEwIC0gcmZjNDc0MWJpcyB0byBJRVNHIGZvciBjb25zaWRlcmF0aW9uIGFzIFBy b3Bvc2VkIFN0YW5kYXJkCiAgU2VwIDIwMTAgLSBTZW5kIHJmYzQ3NDJiaXMgdG8gSUVTRyBm b3IgY29uc2lkZXJhdGlvbiBhcyBwcm9wb3NlZCBTdGFuZGFyZC4KICBTZXAgMjAxMCAtIGZp cnN0IFdHIGRyYWZ0IChyZXYgMDApIG9uIE5BQ00gcG9zdGVkCiAgU2VwIDIwMTAgLSBmaXJz dCBXRyBkcmFmdCAocmV2IDAwKSBvbiBORVRDT05GIHNwZWNpZmljIFlBTkcgbW9kdWxlcyBw b3N0ZWQKICBKYW4gMjAxMSAtIFdHTEMgZm9yIE5BQ00gZG9jdW1lbnQKICBKYW4gMjAxMSAt IFdHTEMgZm9yIE5FVENPTkYgc3BlY2lmaWMgbm90aWZpY2F0aW9ucyBkb2N1bWVudAogIE1h ciAyMDExIC0gKGlmIG5lZWRlZCBsYXN0KSBXR0xDIGZvciBOQUNNIGRvY3VtZW50CiAgTWFy IDIwMTEgLSAoaWYgbmVlZGVkIGxhc3QpIFdHTEMgZm9yIE5FVENPTkYgc3BlY2lmaWMgbm90 aWZpY2F0aW9ucyBkb2N1bWVudAogIEFwciAyMDExIC0gc3VibWl0IE5BQ00gZG9jdW1lbnQg dG8gSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZAogIEFwciAy MDExIC0gc3VibWl0IE5FVENPTkYgc3BlY2lmaWMgbm90aWZpY2F0aW9ucyAgZG9jdW1lbnQg dG8gSUVTRyBmb3IgY29uc2lkZXJhdGlvbiBhcyBQcm9wb3NlZCBTdGFuZGFyZAo= --------------040003090900040700090403-- From root@core3.amsl.com Wed Aug 11 13:15:01 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E99AE3A6A95; Wed, 11 Aug 2010 13:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100811201501.E99AE3A6A95@core3.amsl.com> Date: Wed, 11 Aug 2010 13:15:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-10.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-10.txt Pages : 31 Date : 2010-08-11 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF database or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-11131352.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Thu Aug 12 04:05:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDFAA3A6895 for ; Thu, 12 Aug 2010 04:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.414 X-Spam-Level: X-Spam-Status: No, score=-100.414 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_50=0.001, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGs6MFEwodgd for ; Thu, 12 Aug 2010 04:05:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A0EE93A67FE for ; Thu, 12 Aug 2010 04:05:38 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36413C0016 for ; Thu, 12 Aug 2010 13:06:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HgdGmfyJVOd7; Thu, 12 Aug 2010 13:06:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1FD9C0015; Thu, 12 Aug 2010 13:06:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8298514355F3; Thu, 12 Aug 2010 13:06:09 +0200 (CEST) Date: Thu, 12 Aug 2010 13:06:08 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20100812110607.GA40088@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 11:05:40 -0000 Hi, the term 'datastore' has been changed to 'database' in the latest with-defaults ID and I believe this is wrong. As far as I can tell, datastore or configuration datastore is the term we use in 4741 and YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 12 04:18:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD21B3A6982 for ; Thu, 12 Aug 2010 04:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQ2VRd1+StQG for ; Thu, 12 Aug 2010 04:18:17 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id BDA0F3A685A for ; Thu, 12 Aug 2010 04:18:17 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 3574561600F; Thu, 12 Aug 2010 13:18:53 +0200 (CEST) Date: Thu, 12 Aug 2010 13:18:49 +0200 (CEST) Message-Id: <20100812.131849.110444198.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100812110607.GA40088@elstar.local> References: <20100812110607.GA40088@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 11:18:18 -0000 Juergen Schoenwaelder wrote: > Hi, > > the term 'datastore' has been changed to 'database' in the latest > with-defaults ID and I believe this is wrong. As far as I can tell, > datastore or configuration datastore is the term we use in 4741 and > YANG. +1. I think Tom's comment was that the term "configuration datastore" should be used, which would be fine with me. /martin From j.schoenwaelder@jacobs-university.de Thu Aug 12 04:50:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C944B3A69FE for ; Thu, 12 Aug 2010 04:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.699 X-Spam-Level: X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD47LlKRcU6h for ; Thu, 12 Aug 2010 04:50:38 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 953DF3A6866 for ; Thu, 12 Aug 2010 04:50:38 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 42081C0016; Thu, 12 Aug 2010 13:51:15 +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 bXM2cYE10Q5n; Thu, 12 Aug 2010 13:51:14 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4954CC0015; Thu, 12 Aug 2010 13:51:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 24B961435942; Thu, 12 Aug 2010 13:51:09 +0200 (CEST) Date: Thu, 12 Aug 2010 13:51:09 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100812115109.GA40283@elstar.local> Mail-Followup-To: Martin Bjorklund , "netconf@ietf.org" References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812.131849.110444198.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 11:50:40 -0000 On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > Hi, > > > > the term 'datastore' has been changed to 'database' in the latest > > with-defaults ID and I believe this is wrong. As far as I can tell, > > datastore or configuration datastore is the term we use in 4741 and > > YANG. > > +1. I think Tom's comment was that the term "configuration datastore" > should be used, which would be fine with me. If we talk about the configuration datastore. Where does state data reside? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 12 05:01:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5585F3A67F1 for ; Thu, 12 Aug 2010 05:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3vwxebajFkE for ; Thu, 12 Aug 2010 05:01:57 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 648043A6359 for ; Thu, 12 Aug 2010 05:01:57 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id DC6B1616002; Thu, 12 Aug 2010 14:02:33 +0200 (CEST) Date: Thu, 12 Aug 2010 14:02:33 +0200 (CEST) Message-Id: <20100812.140233.136344826.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100812115109.GA40283@elstar.local> References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:01:58 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > the term 'datastore' has been changed to 'database' in the latest > > > with-defaults ID and I believe this is wrong. As far as I can tell, > > > datastore or configuration datastore is the term we use in 4741 and > > > YANG. > > > > +1. I think Tom's comment was that the term "configuration datastore" > > should be used, which would be fine with me. > > If we talk about the configuration datastore. Where does state data > reside? It is separate, as defined in 4741. There are three configuration datastores defined, and state data. /martin From j.schoenwaelder@jacobs-university.de Thu Aug 12 05:12:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD913A6866 for ; Thu, 12 Aug 2010 05:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.71 X-Spam-Level: X-Spam-Status: No, score=-101.71 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Obl9UR6N40wT for ; Thu, 12 Aug 2010 05:12:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2A6513A6403 for ; Thu, 12 Aug 2010 05:12:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D1FC7C0016; Thu, 12 Aug 2010 14:12:53 +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 lqhGbUwp6uvE; Thu, 12 Aug 2010 14:12:52 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A37FC0015; Thu, 12 Aug 2010 14:12:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F0B7E1435AC5; Thu, 12 Aug 2010 14:12:47 +0200 (CEST) Date: Thu, 12 Aug 2010 14:12:47 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100812121244.GA40401@elstar.local> Mail-Followup-To: Martin Bjorklund , "netconf@ietf.org" References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <20100812.140233.136344826.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812.140233.136344826.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:12:18 -0000 On Thu, Aug 12, 2010 at 02:02:33PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > Hi, > > > > > > > > the term 'datastore' has been changed to 'database' in the latest > > > > with-defaults ID and I believe this is wrong. As far as I can tell, > > > > datastore or configuration datastore is the term we use in 4741 and > > > > YANG. > > > > > > +1. I think Tom's comment was that the term "configuration datastore" > > > should be used, which would be fine with me. > > > > If we talk about the configuration datastore. Where does state data > > reside? > > It is separate, as defined in 4741. There are three configuration > datastores defined, and state data. So this place where state data resides is also a datastore? If I write datastore I mean both state datastore and configuration datastore? Perhaps we need to add a terminology section to 4741bis to make sure we understand our terms. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 12 05:16:20 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A7D3A6948 for ; Thu, 12 Aug 2010 05:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2fR05FKeidh for ; Thu, 12 Aug 2010 05:16:20 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1A7C43A6403 for ; Thu, 12 Aug 2010 05:16:19 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 72247616002; Thu, 12 Aug 2010 14:16:56 +0200 (CEST) Date: Thu, 12 Aug 2010 14:16:55 +0200 (CEST) Message-Id: <20100812.141655.207347069.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100812121244.GA40401@elstar.local> References: <20100812115109.GA40283@elstar.local> <20100812.140233.136344826.mbj@tail-f.com> <20100812121244.GA40401@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:16:21 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 12, 2010 at 02:02:33PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > Hi, > > > > > > > > > > the term 'datastore' has been changed to 'database' in the latest > > > > > with-defaults ID and I believe this is wrong. As far as I can tell, > > > > > datastore or configuration datastore is the term we use in 4741 and > > > > > YANG. > > > > > > > > +1. I think Tom's comment was that the term "configuration datastore" > > > > should be used, which would be fine with me. > > > > > > If we talk about the configuration datastore. Where does state data > > > reside? > > > > It is separate, as defined in 4741. There are three configuration > > datastores defined, and state data. > > So this place where state data resides is also a datastore? If I write > datastore I mean both state datastore and configuration datastore? I do not think so. I think 'datastore' is used as a shorthand for 'configuration datastore' in a few places in 4741. > Perhaps we need to add a terminology section to 4741bis to make sure > we understand our terms. Yes, and s/database/datastore/ in a couple of places. /martin From lhotka@cesnet.cz Thu Aug 12 05:16:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21103A6A1E for ; Thu, 12 Aug 2010 05:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xNl6SIK9gcB for ; Thu, 12 Aug 2010 05:16:36 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) by core3.amsl.com (Postfix) with ESMTP id 277D83A6A1F for ; Thu, 12 Aug 2010 05:16:36 -0700 (PDT) Received: from [IPv6:2001:718:1:6:215:60ff:fead:16dc] (unknown [IPv6:2001:718:1:6:215:60ff:fead:16dc]) by office2.cesnet.cz (Postfix) with ESMTPSA id 1B7912CDE058; Thu, 12 Aug 2010 14:17:12 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20100812115109.GA40283@elstar.local> References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> Content-Type: text/plain; charset="UTF-8" Organization: CESNET Date: Thu, 12 Aug 2010 14:17:11 +0200 Message-ID: <1281615431.2322.43.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:16:37 -0000 Juergen Schoenwaelder píše v Čt 12. 08. 2010 v 13:51 +0200: > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > Hi, > > > > > > the term 'datastore' has been changed to 'database' in the latest > > > with-defaults ID and I believe this is wrong. As far as I can tell, > > > datastore or configuration datastore is the term we use in 4741 and > > > YANG. > > > > +1. I think Tom's comment was that the term "configuration datastore" > > should be used, which would be fine with me. > > If we talk about the configuration datastore. Where does state data > reside? YANG uses "data tree" for instantiated configuration + state data, perhaps this could be adopted universally. Lada > > /js > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Aug 12 05:35:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D612A3A6A18 for ; Thu, 12 Aug 2010 05:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.72 X-Spam-Level: X-Spam-Status: No, score=-101.72 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QOCznIQnLmT for ; Thu, 12 Aug 2010 05:35:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id AA2F73A6950 for ; Thu, 12 Aug 2010 05:35:25 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 551B7C001C; Thu, 12 Aug 2010 14:36:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vd1-zBoIZ3bg; Thu, 12 Aug 2010 14:36:01 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24943C0015; Thu, 12 Aug 2010 14:36:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 61B701435C79; Thu, 12 Aug 2010 14:35:57 +0200 (CEST) Date: Thu, 12 Aug 2010 14:35:57 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100812123556.GA40555@elstar.local> Mail-Followup-To: Martin Bjorklund , "netconf@ietf.org" References: <20100812115109.GA40283@elstar.local> <20100812.140233.136344826.mbj@tail-f.com> <20100812121244.GA40401@elstar.local> <20100812.141655.207347069.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100812.141655.207347069.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:35:26 -0000 On Thu, Aug 12, 2010 at 02:16:55PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Aug 12, 2010 at 02:02:33PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > > > > > Juergen Schoenwaelder wrote: > > > > > > Hi, > > > > > > > > > > > > the term 'datastore' has been changed to 'database' in the latest > > > > > > with-defaults ID and I believe this is wrong. As far as I can tell, > > > > > > datastore or configuration datastore is the term we use in 4741 and > > > > > > YANG. > > > > > > > > > > +1. I think Tom's comment was that the term "configuration datastore" > > > > > should be used, which would be fine with me. > > > > > > > > If we talk about the configuration datastore. Where does state data > > > > reside? > > > > > > It is separate, as defined in 4741. There are three configuration > > > datastores defined, and state data. > > > > So this place where state data resides is also a datastore? If I write > > datastore I mean both state datastore and configuration datastore? > > I do not think so. I think 'datastore' is used as a shorthand for > 'configuration datastore' in a few places in 4741. We should then avoid the shorthand and be explicit. > > Perhaps we need to add a terminology section to 4741bis to make sure > > we understand our terms. > > Yes, and s/database/datastore/ in a couple of places. Yep /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 12 05:54:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79C693A6A1F for ; Thu, 12 Aug 2010 05:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqZcdMDApPyY for ; Thu, 12 Aug 2010 05:54:49 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A52423A6807 for ; Thu, 12 Aug 2010 05:54:49 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E476616002 for ; Thu, 12 Aug 2010 14:55:25 +0200 (CEST) Date: Thu, 12 Aug 2010 14:55:24 +0200 (CEST) Message-Id: <20100812.145524.70210866.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 7.0.50 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:54:50 -0000 Hi, In Maastricht, we discussed what the server should do if it receives broken XML. I suggest the following change: OLD: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. NEW: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives a message that is not well-formed XML, it MUST close the NETCONF session. Comments? /martin From ietf@andybierman.com Thu Aug 12 08:19:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2CF3A6900 for ; Thu, 12 Aug 2010 08:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9tT8olWNwpP for ; Thu, 12 Aug 2010 08:19:06 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 012753A68CB for ; Thu, 12 Aug 2010 08:19:05 -0700 (PDT) Received: (qmail 80966 invoked from network); 12 Aug 2010 15:19:41 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 08:19:41 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: 0k3YWoUVM1k.ugXTHRF9.6_puZeFY1R2X0RODD0xP0Z_JGz a2upBLnikLXZIVxB3jaZcIfbo4KsWKahWqitgmJpYTOsxntTDzN7XzWUmMGZ QAkuNVjWQ8sa4U7KiF3CGgjejVJvx6t3sdTremHMdCdCFOTUeMWkzyjeXoOO k99uM.s0BTn1CUow_BG7aln1afRSe.8N6wtGU1OKuETHodwNKZHoZMTHd4dA g1ajQjqdW2LYcHqwjomc2OMs3rJFXxwXzyw_eu6r._QDFnFkDJSW17I973Ur FajN_6jLXpTPRJ7.b X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C64110F.8060703@andybierman.com> Date: Thu, 12 Aug 2010 08:19:43 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ladislav Lhotka References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <1281615431.2322.43.camel@missotis> In-Reply-To: <1281615431.2322.43.camel@missotis> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 15:19:06 -0000 On 08/12/2010 05:17 AM, Ladislav Lhotka wrote: > Juergen Schoenwaelder píše v Čt 12. 08. 2010 v 13:51 +0200: >> On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>>> Hi, >>>> >>>> the term 'datastore' has been changed to 'database' in the latest >>>> with-defaults ID and I believe this is wrong. As far as I can tell, >>>> datastore or configuration datastore is the term we use in 4741 and >>>> YANG. >>> >>> +1. I think Tom's comment was that the term "configuration datastore" >>> should be used, which would be fine with me. >> >> If we talk about the configuration datastore. Where does state data >> reside? > > YANG uses "data tree" for instantiated configuration + state data, > perhaps this could be adopted universally. > Maybe you are right. YANG clearly allows configuration and non-configuration data nodes to exist as sibling nodes at any level of the conceptual data tree. NETCONF seems to ignore this fact, even though the content layer is supposed to be independent of the other layers. The term 'configuration datastore' is really just a conceptual subset of the data tree, to refer to the config=true nodes. Oops -- it is a conceptual tree only if the node is treated as the root, even though non-config nodes use this as the root as well. The operation is somewhat broken because it returns config=true nodes under root. BTW, NETCONF/YANG does not allow for dual-role (config and operational state), such as a leaf that would magically change its value from 'auto' to 'full' on its own. There is no text that would suggest this is supported, therefore a data model designer MUST choose 2 YANG leafs. This is just a bad SMIv2 practice that should not apply to YANG. > Lada > >> >> /js >> > Andy From ietf@andybierman.com Thu Aug 12 11:13:10 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4C33A6A09 for ; Thu, 12 Aug 2010 11:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZ6TQ+22kz3V for ; Thu, 12 Aug 2010 11:13:09 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id B1CA33A6A04 for ; Thu, 12 Aug 2010 11:13:09 -0700 (PDT) Received: (qmail 79070 invoked from network); 12 Aug 2010 18:13:44 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 12 Aug 2010 11:13:44 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: tegL30gVM1k3byQjC9FU1Z2YnKTsuuTHAwyAq83fN3_bkas J1CE.74n_OSw.ECc.VXbIhIbdrekH5iDwTtsrO9t27.5eDi6xH7b3PV_N6l1 FThy.yEtcDi0nwQcbBgQN3WS7NJG4f4XdKpxVyMw_e9S4oQnm9toX08Yjmji zOqk.ZE6x2jb.ofnCOLm.RFXXUNENcV8rx5_UlesmTUJfc76amYrmqj1.qJu vP7NP66sKoRowSWu8UkFCGeF5mp40CSOn7ThKYw5LIXQVTje.fH5IHEPah2e kXVXxKFLLufdeqkXP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6439DA.5020409@andybierman.com> Date: Thu, 12 Aug 2010 11:13:46 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund , "netconf@ietf.org" References: <20100812110607.GA40088@elstar.local> <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> In-Reply-To: <20100812115109.GA40283@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:13:10 -0000 On 08/12/2010 04:51 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> Hi, >>> >>> the term 'datastore' has been changed to 'database' in the latest >>> with-defaults ID and I believe this is wrong. As far as I can tell, >>> datastore or configuration datastore is the term we use in 4741 and >>> YANG. >> >> +1. I think Tom's comment was that the term "configuration datastore" >> should be used, which would be fine with me. > > If we talk about the configuration datastore. Where does state data > reside? > Let's try to resolve this once and for all. The NETCONF content layer is somewhat confusing wrt/ the operation. YANG clearly allows any number of config=false subtrees at any point in the conceptual data tree. NETCONF must support this data modeling capability. A is clear -- it identifies all the top-level config=true subtrees internally associated with the requested , and gathers them into a container. Any config=false descendant subtrees are excluded from the response. A is also clear. It returns all the running config=true nodes plus all the top-level config=false nodes and any descendant config=false nodes within a config=true list or container. It gathers all these nodes into a container. The 'datastore' terminology is not clear because the architecture is not clear. Why do the conceptual data tree operations work this way? If the did not include config=true nodes then could any descendant config=false nodes ever be accessed? If just returned config=false leaf/leaf-lists/anyxml, and any container/list ancestor nodes as needed, then the vs. conceptual container in the would make more sense to me. But that would be a big change in base:1.1. And the terminology issue still needs to be solved. Should I do 's/database/datastore/' and call it done, or do something else in the with-defaults draft? > /js > Andy From mbj@tail-f.com Thu Aug 12 12:54:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C91B3A6903 for ; Thu, 12 Aug 2010 12:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.195 X-Spam-Level: X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYGlOwtalB7x for ; Thu, 12 Aug 2010 12:54:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 0768D3A67C3 for ; Thu, 12 Aug 2010 12:54:07 -0700 (PDT) Received: from localhost (78-70-162-131-no181.tbcn.telia.com [78.70.162.131]) by mail.tail-f.com (Postfix) with ESMTPSA id 3D005616002; Thu, 12 Aug 2010 21:54:43 +0200 (CEST) Date: Thu, 12 Aug 2010 21:54:41 +0200 (CEST) Message-Id: <20100812.215441.11624768.mbj@tail-f.com> To: ietf@andybierman.com From: Martin Bjorklund In-Reply-To: <4C6439DA.5020409@andybierman.com> References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:54:09 -0000 Andy Bierman wrote: > On 08/12/2010 04:51 AM, Juergen Schoenwaelder wrote: > > On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: > >>> Hi, > >>> > >>> the term 'datastore' has been changed to 'database' in the latest > >>> with-defaults ID and I believe this is wrong. As far as I can tell, > >>> datastore or configuration datastore is the term we use in 4741 and > >>> YANG. > >> > >> +1. I think Tom's comment was that the term "configuration datastore" > >> should be used, which would be fine with me. > > > > If we talk about the configuration datastore. Where does state data > > reside? > > > > Let's try to resolve this once and for all. > The NETCONF content layer is somewhat confusing wrt/ the operation. > > YANG clearly allows any number of config=false subtrees at any point > in the conceptual data tree. NETCONF must support this data modeling > capability. > > A is clear -- it identifies all the top-level config=true > subtrees internally associated with the requested , and gathers > them into a container. No, the reply to a is sent in . > Any config=false descendant subtrees > are excluded from the response. > > A is also clear. It returns all the running config=true nodes plus > all the top-level config=false nodes and any descendant config=false nodes > within a config=true list or container. It gathers all these nodes > into a container. > > The 'datastore' terminology is not clear because the architecture is not clear. > Why do the conceptual data tree operations work this way? > If the did not include config=true nodes then could any > descendant config=false nodes ever be accessed? Maybe this could be made to work, but that's not how it currently works, and I see no reason to do any changes here... > Should I do 's/database/datastore/' and call it done, Yes. Make sure the term is 'configuration datastore'. /martin From ietf@andybierman.com Thu Aug 12 13:36:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C2203A696F for ; Thu, 12 Aug 2010 13:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFYah+273Lt4 for ; Thu, 12 Aug 2010 13:36:17 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id B40E33A68CF for ; Thu, 12 Aug 2010 13:36:17 -0700 (PDT) Received: (qmail 32964 invoked from network); 12 Aug 2010 20:36:53 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 13:36:53 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: fz3dkZsVM1kvFM0yZ2ctXVxxQSOUcX_2iABgodIsrSPKOE8 7KtrgrPuZ.kMJ.Bq_CAMDiNXOfcD0c9ef30NjGFi3fn5JLmiwtoGAAGqTQjk UZYN2kUdyYeRBrqSbGXtSG9padcXNsgs_ewz69axHGN0wVq7klZgIElhZcpP 7ErjXmzcft4Ec0Mc5ELaUfWnXpYugTnfekXOmp09OX5AAcOKk8KoTy.qo4Tj an_YS_gLVWU0SIDVG6bKb6A_HyChd0Adb3gp4DtA42MYcWjRsMZvpqhd9K4g 5W3UvIL6NNNPvdPdq9k6UO4rx_OcxGypEIujAEkvg1364wSLcWW_I X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C645B67.2060303@andybierman.com> Date: Thu, 12 Aug 2010 13:36:55 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> In-Reply-To: <20100812.215441.11624768.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 20:36:18 -0000 On 08/12/2010 12:54 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On 08/12/2010 04:51 AM, Juergen Schoenwaelder wrote: >>> On Thu, Aug 12, 2010 at 01:18:49PM +0200, Martin Bjorklund wrote: >>>> Juergen Schoenwaelder wrote: >>>>> Hi, >>>>> >>>>> the term 'datastore' has been changed to 'database' in the latest >>>>> with-defaults ID and I believe this is wrong. As far as I can tell, >>>>> datastore or configuration datastore is the term we use in 4741 and >>>>> YANG. >>>> >>>> +1. I think Tom's comment was that the term "configuration datastore" >>>> should be used, which would be fine with me. >>> >>> If we talk about the configuration datastore. Where does state data >>> reside? >>> >> >> Let's try to resolve this once and for all. >> The NETCONF content layer is somewhat confusing wrt/ the operation. >> >> YANG clearly allows any number of config=false subtrees at any point >> in the conceptual data tree. NETCONF must support this data modeling >> capability. >> >> A is clear -- it identifies all the top-level config=true >> subtrees internally associated with the requested , and gathers >> them into a container. > > No, the reply to a is sent in . > >> Any config=false descendant subtrees >> are excluded from the response. >> >> A is also clear. It returns all the running config=true nodes plus >> all the top-level config=false nodes and any descendant config=false nodes >> within a config=true list or container. It gathers all these nodes >> into a container. >> >> The 'datastore' terminology is not clear because the architecture is not clear. >> Why do the conceptual data tree operations work this way? >> If the did not include config=true nodes then could any >> descendant config=false nodes ever be accessed? > > Maybe this could be made to work, but that's not how it currently > works, and I see no reason to do any changes here... > >> Should I do 's/database/datastore/' and call it done, > > Yes. Make sure the term is 'configuration datastore'. > > but that excludes config=false nodes, so I think I like data tree better. > /martin > > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 12 14:50:56 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77763A6899 for ; Thu, 12 Aug 2010 14:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.43 X-Spam-Level: X-Spam-Status: No, score=-101.43 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFAmrdL9Lm-Z for ; Thu, 12 Aug 2010 14:50:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 45E3C3A67B1 for ; Thu, 12 Aug 2010 14:50:53 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB79AC000F; Thu, 12 Aug 2010 23:51:29 +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 rzOSmzcfXJGw; Thu, 12 Aug 2010 23:51:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 893F6C0015; Thu, 12 Aug 2010 23:51:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 74A891437828; Thu, 12 Aug 2010 23:51:24 +0200 (CEST) Date: Thu, 12 Aug 2010 23:51:24 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100812215123.GA42040@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C645B67.2060303@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 21:50:57 -0000 On Thu, Aug 12, 2010 at 10:36:55PM +0200, Andy Bierman wrote: > but that excludes config=false nodes, so I think I like data tree better. My understanding so far was that the configuration datastore is an abstrace place to store configuration. The format of the storage is irrelevant. The data tree is defined as "the instantiated tree of configuration and state data on a device." This definitions says it is a tree. My interpretation was that this refers to the XML tree, that is the serialization of data from a datastore into an XML infoset. That is, in the case of processing a operation: config state datastore datastore | | V | data <--------------+ tree | v XML serialization Sure, one can discuss whether state resides in a datastore or is just there, or whether even a different term is needed. If we would call it state datastore, we could refer to any datastore by the term datastore. Anyway, the point I am trying to make is that for me there is a difference between a datastore and a data tree. So depending on the context, the right term should be picked. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 12 18:00:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59E03A6842 for ; Thu, 12 Aug 2010 18:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1btFggpZhGJ for ; Thu, 12 Aug 2010 18:00:26 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 1E4573A68AD for ; Thu, 12 Aug 2010 18:00:26 -0700 (PDT) Received: (qmail 75605 invoked from network); 13 Aug 2010 01:01:01 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 18:01:00 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: x7NoZOgVM1lQRK75Da4o3qO3mlDDbkTzquMUcm6c_efK7I9 Nt8rdvVMInLOiCgGqxSGWqlF7rXAN_i6Cw9JuCsnFoHGA7E._8.u1Jn9pgxE Yxa2x.VPIHn0vbaIgd4sq.Eor8wLujaIWdfDwBbyrNzsgjmTE91AVsZI7Y1r xJDxFSlO7bQWh5z.2lSeW9j58WmL00d9jQiMyfrT.bqhdnSRfIKr.0bQSkUc TiqyQd62ijDGbvDHILe6JkDZLDHKN X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C64994F.1040506@andybierman.com> Date: Thu, 12 Aug 2010 18:01:03 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> In-Reply-To: <20100812215123.GA42040@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 01:00:26 -0000 On 08/12/2010 02:51 PM, Juergen Schoenwaelder wrote: > On Thu, Aug 12, 2010 at 10:36:55PM +0200, Andy Bierman wrote: > >> but that excludes config=false nodes, so I think I like data tree better. > > My understanding so far was that the configuration datastore is an > abstrace place to store configuration. The format of the storage is > irrelevant. > > The data tree is defined as "the instantiated tree of configuration > and state data on a device." This definitions says it is a tree. My > interpretation was that this refers to the XML tree, that is the > serialization of data from a datastore into an XML infoset. That is, > in the case of processing a operation: > > config state > datastore datastore > | | > V | > data <--------------+ > tree > | > v > XML > serialization > > Sure, one can discuss whether state resides in a datastore or is just > there, or whether even a different term is needed. If we would call it > state datastore, we could refer to any datastore by the term > datastore. Anyway, the point I am trying to make is that for me there > is a difference between a datastore and a data tree. So depending on > the context, the right term should be picked. I will use the generic 'datastore' -- back to the way it was before this change. If the sentence refers to only config=true or config=false nodes, then configuration or state will be prepended to the term. Your picture does not account for config=false nodes within config=true ancestors. container foo { list bar { config false; ... } } > > /js > Andy From ietf@andybierman.com Thu Aug 12 19:52:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEDDD3A6A55 for ; Thu, 12 Aug 2010 19:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLeLnz1F5HoZ for ; Thu, 12 Aug 2010 19:52:13 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 0CBE33A6A33 for ; Thu, 12 Aug 2010 19:52:12 -0700 (PDT) Received: (qmail 54014 invoked from network); 13 Aug 2010 02:52:47 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 19:52:47 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: ZTbrlGQVM1lkxVN46WJKfWcEpph_k2bDmreY4VqG1WGG2Qp SHXhyHVY5lzPqmSMzcCY9w_F_2MRUIf1yvPX6x5TvjbhXEE.xzmmKN8xU7IU guMWOObDSh1Ah6lr2vmzBJfzVi2fQWOatKrClmXNs9mIm6buspHsiywrU_Wn PNFeaYZs9dwgjCfy6Q938LWynrL6QonRXa769DEME.K.ZbtoyWoSoLoTC6xF sd_lsMn0wAwyV8qNLYRMPFuF_aXioocZkz3cSyKvNcEg_phIQTWpas6visTw 97YSP X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C64B382.7020601@andybierman.com> Date: Thu, 12 Aug 2010 19:52:50 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> In-Reply-To: <20100812215123.GA42040@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 02:52:13 -0000 On 08/12/2010 02:51 PM, Juergen Schoenwaelder wrote: > On Thu, Aug 12, 2010 at 10:36:55PM +0200, Andy Bierman wrote: > >> but that excludes config=false nodes, so I think I like data tree better. > > My understanding so far was that the configuration datastore is an > abstrace place to store configuration. The format of the storage is > irrelevant. > OK -- also, the context (input, output, notification, datastore) is irrelevant. The use-case for a default for config=false or output, or notification is simple -- to save bandwidth. If there is a default value for a status leaf (quite likely), then why waste bytes on the wire reporting it? So what term applies to all the 'places' a default can be applied, where a default is the value that is used when the leaf is not present. There should be no need to have different meanings of a default for different NETCONF content. Andy > The data tree is defined as "the instantiated tree of configuration > and state data on a device." This definitions says it is a tree. My > interpretation was that this refers to the XML tree, that is the > serialization of data from a datastore into an XML infoset. That is, > in the case of processing a operation: > > config state > datastore datastore > | | > V | > data <--------------+ > tree > | > v > XML > serialization > > Sure, one can discuss whether state resides in a datastore or is just > there, or whether even a different term is needed. If we would call it > state datastore, we could refer to any datastore by the term > datastore. Anyway, the point I am trying to make is that for me there > is a difference between a datastore and a data tree. So depending on > the context, the right term should be picked. > > /js > From root@core3.amsl.com Thu Aug 12 20:30:20 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6CB343A68B8; Thu, 12 Aug 2010 20:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100813033005.6CB343A68B8@core3.amsl.com> Date: Thu, 12 Aug 2010 20:30:03 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 03:30:20 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : With-defaults capability for NETCONF Author(s) : A. Bierman, B. Lengyel Filename : draft-ietf-netconf-with-defaults-11.txt Pages : 31 Date : 2010-08-12 The NETCONF protocol defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-12201519.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Fri Aug 13 00:05:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F303D3A68E6 for ; Fri, 13 Aug 2010 00:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.134 X-Spam-Level: X-Spam-Status: No, score=-101.134 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+CLjh1mlN3m for ; Fri, 13 Aug 2010 00:05:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 796853A67A7 for ; Fri, 13 Aug 2010 00:05:52 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9516C000F; Fri, 13 Aug 2010 09:06:28 +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 fXe6U23-6mr4; Fri, 13 Aug 2010 09:06:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51695C000D; Fri, 13 Aug 2010 09:06:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E7840143860D; Fri, 13 Aug 2010 09:06:23 +0200 (CEST) Date: Fri, 13 Aug 2010 09:06:23 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100813070623.GC42831@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> <4C64994F.1040506@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C64994F.1040506@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 07:05:54 -0000 On Fri, Aug 13, 2010 at 03:01:03AM +0200, Andy Bierman wrote: > I will use the generic 'datastore' -- back to the way it was before > this change. If the sentence refers to only config=true or config=false > nodes, then configuration or state will be prepended to the term. > > Your picture does not account for config=false nodes within config=true > ancestors. > > container foo { > list bar { config false; ... } > } Not sure I can follow. If you take my picture, then these nesting issues are relevant only for the data tree, not for the datastores. A config false piece will never be in an configuration datastore. So if a document discusses these nesting issues, it is likely that data tree is the term it should be using for discussing the issue. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfc@btconnect.com Fri Aug 13 03:28:42 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96DD73A67AF for ; Fri, 13 Aug 2010 03:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.906 X-Spam-Level: X-Spam-Status: No, score=-0.906 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_05=-1.11, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WvTdy0sHB5t for ; Fri, 13 Aug 2010 03:28:41 -0700 (PDT) Received: from c2bthomr06.btconnect.com (c2bthomr06.btconnect.com [213.123.20.124]) by core3.amsl.com (Postfix) with ESMTP id D31303A698F for ; Fri, 13 Aug 2010 03:28:40 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2bthomr06.btconnect.com with SMTP id FZB88348; Fri, 13 Aug 2010 11:29:07 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C651E73.00C6, actions=tag Message-ID: <01a101cb3ac9$53eefd80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Juergen Schoenwaelder" , "Andy Bierman" References: <20100812.131849.110444198.mbj@tail-f.com><20100812115109.GA40283@elstar.local><4C6439DA.5020409@andybierman.com><20100812.215441.11624768.mbj@tail-f.com><4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> Date: Fri, 13 Aug 2010 11:24:20 +0200 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-Junkmail-Status: score=10/50, host=c2bthomr06.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0205.4C651E79.0061,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:28:42 -0000 ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Andy Bierman" Cc: Sent: Thursday, August 12, 2010 11:51 PM Subject: Re: [Netconf] datastore vs. database > On Thu, Aug 12, 2010 at 10:36:55PM +0200, Andy Bierman wrote: > > > but that excludes config=false nodes, so I think I like data tree better. > > My understanding so far was that the configuration datastore is an > abstrace place to store configuration. The format of the storage is > irrelevant. > > The data tree is defined as "the instantiated tree of configuration > and state data on a device." This definitions says it is a tree. My > interpretation was that this refers to the XML tree, that is the > serialization of data from a datastore into an XML infoset. That is, > in the case of processing a operation: > > config state > datastore datastore > | | > V | > data <--------------+ > tree > | > v > XML > serialization > > Sure, one can discuss whether state resides in a datastore or is just > there, or whether even a different term is needed. If we would call it > state datastore, we could refer to any datastore by the term > datastore. Anyway, the point I am trying to make is that for me there > is a difference between a datastore and a data tree. So depending on > the context, the right term should be picked. The other point is that data tree is defined by YANG and not by Netconf. It is ok for me to have differences between the two if one is needed - for example, YANG explicitly says that the schema tree is a tree and so the data tree must be a tree as well. Netconf I do not think does so, although the filtering mechanisms come close to implying a tree structure, so if Netconf is to cater for non-tree data, then data tree would be wrong. As you have rightly said, my original comment was on the mismatch between the I-Ds, that datastore is not defined. Netconf talks of 'configuration and state data' or 'configuration datastore'. 'State datastore' works for me but I don't have strong feelings as long as it all hangs together, which for me at present it does not. The other related issue is the YANG defines 'data node' as part of the schema tree and so is the wrong term for whatever it is that has or has not a default value in the configuration datastore. Again, Netconf could redefine data node for its purposes (but I would rather it did not). Tom Petch > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Fri Aug 13 03:49:02 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22CB3A6998 for ; Fri, 13 Aug 2010 03:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.433 X-Spam-Level: X-Spam-Status: No, score=-101.433 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bodl7jUf+9cE for ; Fri, 13 Aug 2010 03:49:02 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CDDE93A693F for ; Fri, 13 Aug 2010 03:49:01 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 918CBC0007; Fri, 13 Aug 2010 12:49:38 +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 RFPhG9MumXl7; Fri, 13 Aug 2010 12:49:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACDF7C000D; Fri, 13 Aug 2010 12:49:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 050571438F1E; Fri, 13 Aug 2010 12:49:26 +0200 (CEST) Date: Fri, 13 Aug 2010 12:49:26 +0200 From: Juergen Schoenwaelder To: "t.petch" Message-ID: <20100813104926.GA44048@elstar.local> Mail-Followup-To: "t.petch" , Andy Bierman , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> <01a101cb3ac9$53eefd80$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01a101cb3ac9$53eefd80$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 10:49:03 -0000 On Fri, Aug 13, 2010 at 11:24:20AM +0200, t.petch wrote: > It is ok for me to have differences between the two if one is needed > - for example, YANG explicitly says that the schema tree is a tree > and so the data tree must be a tree as well. Netconf I do not think > does so, although the filtering mechanisms come close to implying a > tree structure, so if Netconf is to cater for non-tree data, then > data tree would be wrong. NETCONF says the content payload is XML and thus the content payload has a tree structure. That, of course, does not imply that the datastore necessarily has a tree structure. In other words, the requirement that the data tree is a tree is hard wired in NETCONF and not falling out of YANG. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Fri Aug 13 06:49:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D06333A68FA for ; Fri, 13 Aug 2010 06:49:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqW3BCfNuKYt for ; Fri, 13 Aug 2010 06:49:18 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id DA0133A6403 for ; Fri, 13 Aug 2010 06:49:17 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 3AB759816F; Fri, 13 Aug 2010 06:49:54 -0700 (PDT) From: Wes Hardaker To: Martin Bjorklund Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> Date: Fri, 13 Aug 2010 06:49:54 -0700 In-Reply-To: <20100812.145524.70210866.mbj@tail-f.com> (Martin Bjorklund's message of "Thu, 12 Aug 2010 14:55:24 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 13:49:18 -0000 >>>>> On Thu, 12 Aug 2010 14:55:24 +0200 (CEST), Martin Bjorklund said: MB> NEW: MB> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If MB> a peer receives a message that is not well-formed XML, it MUST MB> close the NETCONF session. MB> Comments? Count me in for "I like it". I think this is a much safer approach to parsing. -- Wes Hardaker Cobham Analytic Solutions From mehmet.ersue@nsn.com Thu Aug 12 11:18:25 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98593A6A04; Thu, 12 Aug 2010 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7d8dq8jF+me; Thu, 12 Aug 2010 11:18:24 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id C389D3A69F4; Thu, 12 Aug 2010 11:18:23 -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 o7CIIqbn003972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Aug 2010 20:18:52 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7CIIpSZ019323; Thu, 12 Aug 2010 20:18:51 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 20:18: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, 12 Aug 2010 20:18:49 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network-wide Configuration - TM Forum View thread-index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564A= From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Phil Shafer" , "ext Martin Bjorklund" , "ext Bert (IETF) Wijnen" , , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , "Juergen Schoenwaelder" , "ext Ladislav Lhotka" , "ext Davis, Nigel" X-OriginalArrivalTime: 12 Aug 2010 18:18:51.0748 (UTC) FILETIME=[D0EE9A40:01CB3A4A] X-Mailman-Approved-At: Fri, 13 Aug 2010 09:07:44 -0700 Cc: netconf@ietf.org, NETMOD Working Group Subject: [Netconf] Network-wide Configuration - TM Forum View X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:18:25 -0000 Hi All, as discussed in the Network-wide configuration BarBof in Maastricht Nigel Davis from TM Forum volunteered to=20 give us an overview on the TMF network model, NE-Mediation- EMS as well as the modeling and tooling framework at TMF.=20 Following is a draft agenda: - Level set on purpose of meeting with respect to the bar BoF discussion - Briefly discuss NE-Mediation-EMS approach to dealing with normalisation - Examine the TMF network model and documentation structure/locations - Discuss next step, possible liaison and ongoing work approach Please let Nigel know if you would like to have additional=20 agenda points.=20 The proposed date for a conf call (1.5 hours) is next=20 Thursday (8/19) or Friday (8/20). Please check the doodle=20 below and enter your preferred time. http://www.doodle.com/4gq3niupbev3vg6m PS: We hope 8/19 or 8/20 does work for a conf call. If not we can arrange another date. Cheers, Mehmet From ietf@andybierman.com Thu Aug 12 11:45:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ACB028C144 for ; Thu, 12 Aug 2010 11:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3kj3TklOtg6i for ; Thu, 12 Aug 2010 11:45:36 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 8681428C142 for ; Thu, 12 Aug 2010 11:45:36 -0700 (PDT) Received: (qmail 78773 invoked from network); 12 Aug 2010 18:46:11 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 12 Aug 2010 11:46:11 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: HVVBLogVM1ngzLvc1GkWXhgrVYKBp7b8lIkHgtNFxGy5tVO HYQO0oNjdxZjIj7SDThsDg5r91.Vjj.Iyb0NTu1dNgRBfsFrWs3aNUfBRu26 t7.CenXhQW0GxUC.n_I5nYPJZtqmLe8198EvwSxEyhI.ABJQt2TdfTlB3Lm2 VU56iKuMDF2daEj1M4o5Dr0_FMK8DqBtdbMG6Mu3CIpDBejwgdGvYDc3Kjsg zFk4QKJajQYd8JHD6.rFeno2hBtPUF3pRvOCMJe65fgld.QpSOAJPVsciyys pbMs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C644174.3000605@andybierman.com> Date: Thu, 12 Aug 2010 11:46:12 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Ersue, Mehmet \(NSN - DE/Munich\)" References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 13 Aug 2010 09:07:44 -0700 Cc: NETMOD Working Group , "Linowski, Bernd \(EXT-Other - DE\)" , netconf@ietf.org, "ext Davis, Nigel" , "Kessens, David \(NSN - US/Mountain View\)" Subject: Re: [Netconf] Network-wide Configuration - TM Forum View X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 18:45:37 -0000 On 08/12/2010 11:18 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > as discussed in the Network-wide configuration BarBof > in Maastricht Nigel Davis from TM Forum volunteered to > give us an overview on the TMF network model, NE-Mediation- > EMS as well as the modeling and tooling framework at TMF. > > Following is a draft agenda: > > - Level set on purpose of meeting with respect to the bar BoF discussion > - Briefly discuss NE-Mediation-EMS approach to dealing with > normalisation > - Examine the TMF network model and documentation structure/locations > - Discuss next step, possible liaison and ongoing work approach > > Please let Nigel know if you would like to have additional > agenda points. > I am very interested in understanding how we are going to build on what we already have. We have network devices that contain NETCONF servers (and possibly SSH for CLI, SNMP for SMIv2 data and notifications and SYSLOG for system events). We also have a new data modeling language called YANG, so a client can understand how to access/control the content layer for a NETCONF server. Getting from a high-level SID (or other) model to a NETCONF client managing NETCONF servers with standard YANG data models looks like a lot of hand-waving to me so far. I want to understand what work is needed, why this is the best approach, and how the network model translates/maps to the device-level NETCONF/YANG interface. I am hoping people will write drafts on this topic for a real BoF at the next IETF. > The proposed date for a conf call (1.5 hours) is next > Thursday (8/19) or Friday (8/20). Please check the doodle > below and enter your preferred time. > > http://www.doodle.com/4gq3niupbev3vg6m > > PS: We hope 8/19 or 8/20 does work for a conf call. > If not we can arrange another date. > > Cheers, > Mehmet > > > Andy From ndavis@ciena.com Fri Aug 13 05:42:22 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4938F3A696F; Fri, 13 Aug 2010 05:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVvJZbXIp-Ic; Fri, 13 Aug 2010 05:42:20 -0700 (PDT) Received: from ripley.ciena.com (ripley.ciena.com [63.118.34.24]) by core3.amsl.com (Postfix) with ESMTP id E16D03A68CC; Fri, 13 Aug 2010 05:42:19 -0700 (PDT) From: "Davis, Nigel" To: "Ersue, Mehmet (NSN - DE/Munich)" , ext Andy Bierman , Phil Shafer , ext Martin Bjorklund , "ext Bert (IETF) Wijnen" , "dromasca@avaya.com" , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , Juergen Schoenwaelder , ext Ladislav Lhotka Date: Fri, 13 Aug 2010 08:41:07 -0400 Thread-Topic: Network-wide Configuration - TM Forum View Thread-Index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564AAL5BE8A== Message-ID: <08F15C31754FA341A7B1A106DF42FDB8702DED81@ONWEXGMB01.ciena.com> References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Aug 2010 09:07:44 -0700 Cc: "netconf@ietf.org" , NETMOD Working Group Subject: Re: [Netconf] Network-wide Configuration - TM Forum View X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 12:42:22 -0000 Hi, If you do want to attend this session please do use the doodle link to high= light your availability as we can then try our best to ensure that your cal= endar challenges can be accommodated (and when you get to the link you will= notice that my browser generously applied my availability twice :) ). Nigel -----Original Message----- From: Ersue, Mehmet (NSN - DE/Munich) [mailto:mehmet.ersue@nsn.com]=20 Sent: 12 August 2010 19:19 To: ext Andy Bierman; Phil Shafer; ext Martin Bjorklund; ext Bert (IETF) Wi= jnen; dromasca@avaya.com; Linowski, Bernd (EXT-Other - DE); Kessens, David = (NSN - US/Mountain View); Juergen Schoenwaelder; ext Ladislav Lhotka; Davis= , Nigel Cc: netconf@ietf.org; NETMOD Working Group Subject: Network-wide Configuration - TM Forum View Hi All, as discussed in the Network-wide configuration BarBof in Maastricht Nigel D= avis from TM Forum volunteered to give us an overview on the TMF network mo= del, NE-Mediation- EMS as well as the modeling and tooling framework at TMF= .=20 Following is a draft agenda: - Level set on purpose of meeting with respect to the bar BoF discussion - Briefly discuss NE-Mediation-EMS approach to dealing with normalisation - Examine the TMF network model and documentation structure/locations - Discuss next step, possible liaison and ongoing work approach Please let Nigel know if you would like to have additional agenda points.=20 The proposed date for a conf call (1.5 hours) is next Thursday (8/19) or Fr= iday (8/20). Please check the doodle below and enter your preferred time. http://www.doodle.com/4gq3niupbev3vg6m PS: We hope 8/19 or 8/20 does work for a conf call. If not we can arrange another date. Cheers, Mehmet From ietf@andybierman.com Fri Aug 13 09:08:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 311713A6A29 for ; Fri, 13 Aug 2010 09:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.459 X-Spam-Level: X-Spam-Status: No, score=-1.459 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+qPZ+o48NLG for ; Fri, 13 Aug 2010 09:08:49 -0700 (PDT) Received: from smtp106.sbc.mail.gq1.yahoo.com (smtp106.sbc.mail.gq1.yahoo.com [67.195.14.109]) by core3.amsl.com (Postfix) with SMTP id 559653A69F7 for ; Fri, 13 Aug 2010 09:08:49 -0700 (PDT) Received: (qmail 95504 invoked from network); 13 Aug 2010 16:09:23 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp106.sbc.mail.gq1.yahoo.com with SMTP; 13 Aug 2010 09:09:23 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: EHsF5KoVM1l_c3q2tMRTch7FiqdyXI7XLsFahSv9oj4nYl0 1K0tfceBJ4VOYzmrSiqKQKzR6ke3KhLVI18Yx3AuKAO59IzG6KVx65qoz28z k6Mmem_3C8Gk87LIXfonBaTEAVyOlH361zOu7u4G2G0IPTIi1arp1.553BuI 4O4TPj2HnNzGTdJlYnnRW22W1.xlNu_ONWKGaxToM2ihS_Y.t6B7pbRvUHTq qNLQFtmmcPyRAtyeCR2WsHZsENTBmJTjK2rlQL08RltLe4fzYIjRKEV94QHO 3sXMo X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C656E37.1080609@andybierman.com> Date: Fri, 13 Aug 2010 09:09:27 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: "t.petch" , "netconf@ietf.org" References: <20100812.131849.110444198.mbj@tail-f.com> <20100812115109.GA40283@elstar.local> <4C6439DA.5020409@andybierman.com> <20100812.215441.11624768.mbj@tail-f.com> <4C645B67.2060303@andybierman.com> <20100812215123.GA42040@elstar.local> <01a101cb3ac9$53eefd80$4001a8c0@gateway.2wire.net> <20100813104926.GA44048@elstar.local> In-Reply-To: <20100813104926.GA44048@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] datastore vs. database X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 16:08:50 -0000 On 08/13/2010 03:49 AM, Juergen Schoenwaelder wrote: > On Fri, Aug 13, 2010 at 11:24:20AM +0200, t.petch wrote: > >> It is ok for me to have differences between the two if one is needed >> - for example, YANG explicitly says that the schema tree is a tree >> and so the data tree must be a tree as well. Netconf I do not think >> does so, although the filtering mechanisms come close to implying a >> tree structure, so if Netconf is to cater for non-tree data, then >> data tree would be wrong. > > NETCONF says the content payload is XML and thus the content payload > has a tree structure. That, of course, does not imply that the > datastore necessarily has a tree structure. In other words, the > requirement that the data tree is a tree is hard wired in NETCONF and > not falling out of YANG. > I changed the term 'database' to 'configuration datastore' or 'datastore'. I understand that the terminology needs to be as consistent as possible, but we should be more concerned with client/server interactions. The YANG spec clearly allows the default-stmt to apply to any context in which a data-def-stmt is allowed: 1 - rpc/input 2 - rpc/output 3 - datastore (data tree root) 4 - notification/event-type The document is heavily biased towards the configuration subset of (3), but any missing leaf can have a default-stmt applied in its absence. One of the biggest complaints I keep hearing about NETCONF is that XML sucks because it is too verbose ( --> slow). Pruning all 'normal' status leafs from a notification or rpc/output addresses this problem. The draft does not cover the server behavior for (2) or (4). Does a client assume it is the basic-mode behavior? Or assume there is no predictable behavior and just add in the default if the leaf is missing? > /js > Andy From ietf@andybierman.com Fri Aug 13 13:08:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB5D3A6852 for ; Fri, 13 Aug 2010 13:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CMgUEQA5iuO for ; Fri, 13 Aug 2010 13:08:30 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 5FF5A3A63D3 for ; Fri, 13 Aug 2010 13:08:30 -0700 (PDT) Received: (qmail 47830 invoked from network); 13 Aug 2010 20:09:05 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2010 13:09:05 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: RIHEULAVM1mbVDY9TIKAjCz7evYAWbaOJWiiHtSHJR0wNYM XvsLQrieJCG1sME_eHZAx9_8UB4hZ9BVEAX1aDsUEivYKQR6mUcAA2NVFz_a Jg9bk8uEZ1x0qx9dKZSYl2tQQYZdCcXSG5ghiWHGmSfJLVRTVz8IO8rm59gj W8OxGTBSMge3FCTAq8YTo9ArP_SoAIoHPD.DzlyVKxgts_zKEfI6LbYrSvmt 6oqQslaZFcOHSLjx.0nrSZpLYe.J_GTlJK9fbfYPkr_jb2mkSBM0A65C_SMs jvz8Qu1px9Sx6r_8WRBBtyvLMxygBMqmE7eKL9CHoNYYW3GV8YfSGC9kxn_B owCgcAsrh6ZNDgw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C65A665.8030304@andybierman.com> Date: Fri, 13 Aug 2010 13:09:09 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Wes Hardaker References: <20100812.145524.70210866.mbj@tail-f.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 20:08:31 -0000 On 08/13/2010 06:49 AM, Wes Hardaker wrote: >>>>>> On Thu, 12 Aug 2010 14:55:24 +0200 (CEST), Martin Bjorklund said: > > MB> NEW: > > MB> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If > MB> a peer receives a message that is not well-formed XML, it MUST > MB> close the NETCONF session. > > MB> Comments? > > Count me in for "I like it". I think this is a much safer approach to parsing. I do not like it. It is too fragile. This was not the intent of the WG when 4741 and 4742 were written. The intent was that the message framing sequence used in each of the transports would allow a server to resynch to the next XML document in the input stream. If the server cannot resynch and understand that a new XML document is starting, then it MUST shut down the session. Otherwise, it MAY send the appropriate rpc-error and continue instead of shutting down the session. Andy From ietf@andybierman.com Sun Aug 15 11:05:52 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C583A68AC for ; Sun, 15 Aug 2010 11:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG18O-Byu-Tr for ; Sun, 15 Aug 2010 11:05:51 -0700 (PDT) Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id 794CF3A6403 for ; Sun, 15 Aug 2010 11:05:51 -0700 (PDT) Received: (qmail 4500 invoked from network); 15 Aug 2010 18:06:23 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 15 Aug 2010 11:06:22 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: PfbWsY4VM1mkvhrM63yn4qiT_BWkYdBtGYp4vaQ_NIiYp_c _Aedw_5Fgcx7x7PXMcSt7hcOE1dTFoGAJHFSJA74YPmb4ZxzG5V.QX07Ktv_ OQM4_KpG2a_lwsdwJol6ckhqxPBTPBLeFBC2J5s9bbZYA.gF.GPLaLc7z809 BSfsaP8TpaVyAtwRJbX471EeKxdqFaQuuKrbDKEzJm2CJsQgSwMDHp2Bx.ss BlFm9MgeYNvMektezYUcnm60pDZO2b74zcHzHej49pT2vpWH18IauNZDhxOt H X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C682CA6.2040703@andybierman.com> Date: Sun, 15 Aug 2010 11:06:30 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Wes Hardaker References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> In-Reply-To: <4C65A665.8030304@andybierman.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 18:05:52 -0000 On 08/13/2010 01:09 PM, Andy Bierman wrote: > On 08/13/2010 06:49 AM, Wes Hardaker wrote: >>>>>>> On Thu, 12 Aug 2010 14:55:24 +0200 (CEST), Martin Bjorklund said: >> >> MB> NEW: >> >> MB> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If >> MB> a peer receives a message that is not well-formed XML, it MUST >> MB> close the NETCONF session. >> >> MB> Comments? >> >> Count me in for "I like it". I think this is a much safer approach to parsing. OK -- I see what Wes is trying to do -- close the security hole that exists, because the 'EOM' marker in SSH is actually allowed in content, so it is an unsafe marker. Any attempt by a hacker to truncate the message in progress and inject a new one will fail because the truncated message will cause the session to terminate. (Unless the hacker is clever enough to truncate the current message in a way that is valid XML, which is completely possible, but much harder to do.) Applications which are buggy and forget an end tag (for example) should probably be fixed ASAP and not allowed to continue. So I remove my objection, and that means there should be no open issues and 4741bis can go to the IESG right away. Andy > I do not like it. It is too fragile. > This was not the intent of the WG when 4741 and 4742 were written. > The intent was that the message framing sequence used in each of the > transports would allow a server to resynch to the next XML document > in the input stream. > > If the server cannot resynch and understand that a new XML document > is starting, then it MUST shut down the session. Otherwise, it MAY > send the appropriate rpc-error and continue instead of shutting down the session. > > > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > From ietfc@btconnect.com Mon Aug 16 08:33:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50A773A67AF for ; Mon, 16 Aug 2010 08:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=-0.915, BAYES_50=0.001, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTZRP54f+tpW for ; Mon, 16 Aug 2010 08:33:00 -0700 (PDT) Received: from c2beaomr04.btconnect.com (c2beaomr04.btconnect.com [213.123.26.182]) by core3.amsl.com (Postfix) with ESMTP id 221063A63C9 for ; Mon, 16 Aug 2010 08:32:59 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2beaomr04.btconnect.com with SMTP id CIW15243; Mon, 16 Aug 2010 16:33:25 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C695A45.01F5, actions=tag Message-ID: <001701cb3d4f$55653d40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Andy Bierman" References: <20100813033005.6CB343A68B8@core3.amsl.com> Date: Mon, 16 Aug 2010 16:27:35 +0200 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-Junkmail-Status: score=10/50, host=c2beaomr04.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0207.4C695A4D.0273,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Cc: netconf@ietf.org Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 15:33:01 -0000 OK, so we now have configuration datastore (mostly). I still want " The following terms are defined in [RFC4741]: o client o configuration datastore .... " for consistency plus, perhaps, datastore: Configuration datastore(s?) and state information collectively lifting that in part from from RFC4741 s7.7 Which then leaves data node (instance) and Juergen's point about (non-)existence of defaults outstanding. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Friday, August 13, 2010 5:30 AM Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Configuration Working Group of the IETF. > > > Title : With-defaults capability for NETCONF > Author(s) : A. Bierman, B. Lengyel > Filename : draft-ietf-netconf-with-defaults-11.txt > Pages : 31 > Date : 2010-08-12 > > The NETCONF protocol defines ways to read and edit configuration data > from a NETCONF server. In some cases, part of this data may not be > set by the NETCONF client, but rather a default value known to the > server is used instead. In many situations the NETCONF client has a > priori knowledge about default data, so the NETCONF server does not > need to save it in a NETCONF configuration datastore or send it to > the client in a retrieval operation reply. In other situations the > NETCONF client will need this data from the server. Not all server > implementations treat this default data the same way. This document > defines a capability-based extension to the NETCONF protocol that > allows the NETCONF client to identify how defaults are processed by > the server, and also defines new mechanisms for client control of > server processing of default data. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From ietf@andybierman.com Mon Aug 16 10:08:46 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0C53A686C for ; Mon, 16 Aug 2010 10:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_91=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrXX43NIkIUu for ; Mon, 16 Aug 2010 10:08:45 -0700 (PDT) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by core3.amsl.com (Postfix) with ESMTP id F11C43A6846 for ; Mon, 16 Aug 2010 10:08:44 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7GH9Gm4013791 for ; Mon, 16 Aug 2010 13:09:16 -0400 Authentication-Results: cm-omr6 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [173.147.58.163] ([173.147.58.163:53000] helo=[173.147.58.163]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 57/70-16497-AB0796C4; Mon, 16 Aug 2010 13:09:16 -0400 To: "=?utf-8?B?dC5wZXRjaA==?=" Message-ID: <57.70.16497.AB0796C4@cm-omr6> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Mon, 16 Aug 2010 10:09:29 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5_1281978569536" Cc: netconf@ietf.org Subject: Re: [Netconf] =?utf-8?q?I-D_Action=3Adraft-ietf-netconf-with-defaults?= =?utf-8?q?-11=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 17:08:46 -0000 ------=_Part_5_1281978569536 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCBjaGFuZ2VzIGFyZSB5b3UgcmVxdWVzdGluZy4KUHJvdmlkZSBlZGl0cyBpbiByZmMgZWRp dG9yIGZvcm1hdAoKCkFuZHkKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogInQucGV0 Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPgpEYXRlOiBNb24sIEF1ZyAxNiwgMjAxMCAwNzoyNwpT dWJqZWN0OiBbTmV0Y29uZl0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZh dWx0cy0xMS50eHQKVG86ICJBbmR5IEJpZXJtYW4iIDxpZXRmQGFuZHliaWVybWFuLmNvbT4KQ2M6 IDxuZXRjb25mQGlldGYub3JnPgoKCk9LLCBzbyB3ZSBub3cgaGF2ZSBjb25maWd1cmF0aW9uIGRh dGFzdG9yZSAobW9zdGx5KS4KCkkgc3RpbGwgd2FudAoiIFRoZSBmb2xsb3dpbmcgdGVybXMgYXJl IGRlZmluZWQgaW4gW1JGQzQ3NDFdOgogICBvICBjbGllbnQKICAgbyAgY29uZmlndXJhdGlvbiBk YXRhc3RvcmUKICAuLi4uICIKZm9yIGNvbnNpc3RlbmN5IHBsdXMsIHBlcmhhcHMsCgpkYXRhc3Rv cmU6IENvbmZpZ3VyYXRpb24gZGF0YXN0b3JlKHM/KSBhbmQgc3RhdGUgaW5mb3JtYXRpb24gY29s bGVjdGl2ZWx5CgpsaWZ0aW5nIHRoYXQgaW4gcGFydCBmcm9tIGZyb20gUkZDNDc0MSBzNy43CgpX aGljaCB0aGVuIGxlYXZlcyBkYXRhIG5vZGUgKGluc3RhbmNlKSBhbmQgSnVlcmdlbidzIHBvaW50 IGFib3V0IChub24tKWV4aXN0ZW5jZQpvZiBkZWZhdWx0cyBvdXRzdGFuZGluZy4KClRvbSBQZXRj aAoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiA8SW50ZXJuZXQtRHJhZnRzQGll dGYub3JnPgpUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4KQ2M6IDxuZXRjb25mQGlldGYub3Jn PgpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMywgMjAxMCA1OjMwIEFNClN1YmplY3Q6IFtOZXRjb25m XSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dAoKCj4g QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzCmRpcmVjdG9yaWVzLgo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl IE5ldHdvcmsgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9mIHRoZQpJRVRGLgo+Cj4KPiBU aXRsZSAgICAgICAgICAgOiBXaXRoLWRlZmF1bHRzIGNhcGFiaWxpdHkgZm9yIE5FVENPTkYKPiBB dXRob3IocykgICAgICAgOiBBLiBCaWVybWFuLCBCLiBMZW5neWVsCj4gRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0Cj4gUGFnZXMgICAgICAg ICAgIDogMzEKPiBEYXRlICAgICAgICAgICAgOiAyMDEwLTA4LTEyCj4KPiBUaGUgTkVUQ09ORiBw cm90b2NvbCBkZWZpbmVzIHdheXMgdG8gcmVhZCBhbmQgZWRpdCBjb25maWd1cmF0aW9uIGRhdGEK PiBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIuICBJbiBzb21lIGNhc2VzLCBwYXJ0IG9mIHRoaXMgZGF0 YSBtYXkgbm90IGJlCj4gc2V0IGJ5IHRoZSBORVRDT05GIGNsaWVudCwgYnV0IHJhdGhlciBhIGRl ZmF1bHQgdmFsdWUga25vd24gdG8gdGhlCj4gc2VydmVyIGlzIHVzZWQgaW5zdGVhZC4gIEluIG1h bnkgc2l0dWF0aW9ucyB0aGUgTkVUQ09ORiBjbGllbnQgaGFzIGEKPiBwcmlvcmkga25vd2xlZGdl IGFib3V0IGRlZmF1bHQgZGF0YSwgc28gdGhlIE5FVENPTkYgc2VydmVyIGRvZXMgbm90Cj4gbmVl ZCB0byBzYXZlIGl0IGluIGEgTkVUQ09ORiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBvciBzZW5k IGl0IHRvCj4gdGhlIGNsaWVudCBpbiBhIHJldHJpZXZhbCBvcGVyYXRpb24gcmVwbHkuICBJbiBv dGhlciBzaXR1YXRpb25zIHRoZQo+IE5FVENPTkYgY2xpZW50IHdpbGwgbmVlZCB0aGlzIGRhdGEg ZnJvbSB0aGUgc2VydmVyLiAgTm90IGFsbCBzZXJ2ZXIKPiBpbXBsZW1lbnRhdGlvbnMgdHJlYXQg dGhpcyBkZWZhdWx0IGRhdGEgdGhlIHNhbWUgd2F5LiAgVGhpcyBkb2N1bWVudAo+IGRlZmluZXMg YSBjYXBhYmlsaXR5LWJhc2VkIGV4dGVuc2lvbiB0byB0aGUgTkVUQ09ORiBwcm90b2NvbCB0aGF0 Cj4gYWxsb3dzIHRoZSBORVRDT05GIGNsaWVudCB0byBpZGVudGlmeSBob3cgZGVmYXVsdHMgYXJl IHByb2Nlc3NlZCBieQo+IHRoZSBzZXJ2ZXIsIGFuZCBhbHNvIGRlZmluZXMgbmV3IG1lY2hhbmlz bXMgZm9yIGNsaWVudCBjb250cm9sIG9mCj4gc2VydmVyIHByb2Nlc3Npbmcgb2YgZGVmYXVsdCBk YXRhLgo+Cj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6Cj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMt MTEudHh0Cj4KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KPgo+IEJlbG93 IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFk ZXIKPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2 ZXJzaW9uIG9mIHRoZQo+IEludGVybmV0LURyYWZ0Lgo+CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KCgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g TmV0Y29uZiBtYWlsaW5nIGxpc3QKPiBOZXRjb25mQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mCj4KCgo= ------=_Part_5_1281978569536 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline V2hhdCBjaGFuZ2VzIGFyZSB5b3UgcmVxdWVzdGluZy48YnI+UHJvdmlkZSBlZGl0cyBpbiByZmMg ZWRpdG9yIGZvcm1hdDxicj48YnI+PGJyPkFuZHk8YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2Ug LS0tLS08YnI+RnJvbTogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7aWV0ZmNAYnRjb25uZWN0LmNv bSZndDs8YnI+RGF0ZTogTW9uLCBBdWcgMTYsIDIwMTAgMDc6Mjc8YnI+U3ViamVjdDogW05ldGNv bmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PGJy PlRvOiAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5keWJpZXJtYW4uY29tJmd0 Ozxicj5DYzogJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+T0ssIHNvIHdlIG5v dyBoYXZlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIChtb3N0bHkpLjxicj48YnI+SSBzdGlsbCB3 YW50PGJyPiZxdW90OyBUaGUgZm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtSRkM0NzQx XTo8YnI+ICZuYnNwOyBvICZuYnNwO2NsaWVudDxicj4gJm5ic3A7IG8gJm5ic3A7Y29uZmlndXJh dGlvbiBkYXRhc3RvcmU8YnI+ICZuYnNwOy4uLi4gJnF1b3Q7PGJyPmZvciBjb25zaXN0ZW5jeSBw bHVzLCBwZXJoYXBzLDxicj48YnI+ZGF0YXN0b3JlOiBDb25maWd1cmF0aW9uIGRhdGFzdG9yZShz PykgYW5kIHN0YXRlIGluZm9ybWF0aW9uIGNvbGxlY3RpdmVseTxicj48YnI+bGlmdGluZyB0aGF0 IGluIHBhcnQgZnJvbSBmcm9tIFJGQzQ3NDEgczcuNzxicj48YnI+V2hpY2ggdGhlbiBsZWF2ZXMg ZGF0YSBub2RlIChpbnN0YW5jZSkgYW5kIEp1ZXJnZW4mIzM5O3MgcG9pbnQgYWJvdXQgKG5vbi0p ZXhpc3RlbmNlPGJyPm9mIGRlZmF1bHRzIG91dHN0YW5kaW5nLjxicj48YnI+VG9tIFBldGNoPGJy Pjxicj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPkZyb206ICZsdDtJbnRlcm5ldC1E cmFmdHNAaWV0Zi5vcmcmZ3Q7PGJyPlRvOiAmbHQ7aS1kLWFubm91bmNlQGlldGYub3JnJmd0Ozxi cj5DYzogJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPlNlbnQ6IEZyaWRheSwgQXVndXN0IDEz LCAyMDEwIDU6MzAgQU08YnI+U3ViamVjdDogW05ldGNvbmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0 Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PGJyPjxicj48YnI+Jmd0OyBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8 YnI+ZGlyZWN0b3JpZXMuPGJyPiZndDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg TmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhlPGJyPklFVEYuPGJyPiZn dDs8YnI+Jmd0Ozxicj4mZ3Q7IFRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgOiBXaXRoLWRlZmF1bHRzIGNhcGFiaWxpdHkgZm9yIE5FVENPTkY8YnI+Jmd0OyBBdXRob3Io cykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBBLiBCaWVybWFuLCBCLiBMZW5neWVsPGJyPiZndDsg RmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBkcmFmdC1pZXRmLW5ldGNvbmYt d2l0aC1kZWZhdWx0cy0xMS50eHQ8YnI+Jmd0OyBQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDogMzE8YnI+Jmd0OyBEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiAyMDEwLTA4LTEyPGJyPiZndDs8YnI+Jmd0OyBUaGUgTkVUQ09ORiBw cm90b2NvbCBkZWZpbmVzIHdheXMgdG8gcmVhZCBhbmQgZWRpdCBjb25maWd1cmF0aW9uIGRhdGE8 YnI+Jmd0OyBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIuICZuYnNwO0luIHNvbWUgY2FzZXMsIHBhcnQg b2YgdGhpcyBkYXRhIG1heSBub3QgYmU8YnI+Jmd0OyBzZXQgYnkgdGhlIE5FVENPTkYgY2xpZW50 LCBidXQgcmF0aGVyIGEgZGVmYXVsdCB2YWx1ZSBrbm93biB0byB0aGU8YnI+Jmd0OyBzZXJ2ZXIg aXMgdXNlZCBpbnN0ZWFkLiAmbmJzcDtJbiBtYW55IHNpdHVhdGlvbnMgdGhlIE5FVENPTkYgY2xp ZW50IGhhcyBhPGJyPiZndDsgcHJpb3JpIGtub3dsZWRnZSBhYm91dCBkZWZhdWx0IGRhdGEsIHNv IHRoZSBORVRDT05GIHNlcnZlciBkb2VzIG5vdDxicj4mZ3Q7IG5lZWQgdG8gc2F2ZSBpdCBpbiBh IE5FVENPTkYgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgb3Igc2VuZCBpdCB0bzxicj4mZ3Q7IHRo ZSBjbGllbnQgaW4gYSByZXRyaWV2YWwgb3BlcmF0aW9uIHJlcGx5LiAmbmJzcDtJbiBvdGhlciBz aXR1YXRpb25zIHRoZTxicj4mZ3Q7IE5FVENPTkYgY2xpZW50IHdpbGwgbmVlZCB0aGlzIGRhdGEg ZnJvbSB0aGUgc2VydmVyLiAmbmJzcDtOb3QgYWxsIHNlcnZlcjxicj4mZ3Q7IGltcGxlbWVudGF0 aW9ucyB0cmVhdCB0aGlzIGRlZmF1bHQgZGF0YSB0aGUgc2FtZSB3YXkuICZuYnNwO1RoaXMgZG9j dW1lbnQ8YnI+Jmd0OyBkZWZpbmVzIGEgY2FwYWJpbGl0eS1iYXNlZCBleHRlbnNpb24gdG8gdGhl IE5FVENPTkYgcHJvdG9jb2wgdGhhdDxicj4mZ3Q7IGFsbG93cyB0aGUgTkVUQ09ORiBjbGllbnQg dG8gaWRlbnRpZnkgaG93IGRlZmF1bHRzIGFyZSBwcm9jZXNzZWQgYnk8YnI+Jmd0OyB0aGUgc2Vy dmVyLCBhbmQgYWxzbyBkZWZpbmVzIG5ldyBtZWNoYW5pc21zIGZvciBjbGllbnQgY29udHJvbCBv Zjxicj4mZ3Q7IHNlcnZlciBwcm9jZXNzaW5nIG9mIGRlZmF1bHQgZGF0YS48YnI+Jmd0Ozxicj4m Z3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4mZ3Q7IDxhIGhyZWY9Imh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi13aXRo LWRlZmF1bHRzLTExLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PC9hPjxicj4mZ3Q7PGJyPiZndDsg SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxi cj4mZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPiZndDs8YnI+Jmd0 OyBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1h aWwgcmVhZGVyPGJyPiZndDsgaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+Jmd0OyBJbnRlcm5ldC1EcmFmdC48YnI+Jmd0 Ozxicj48YnI+PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPjxicj48YnI+Jmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IE5ldGNv bmYgbWFpbGluZyBsaXN0PGJyPiZndDsgTmV0Y29uZkBpZXRmLm9yZzxicj4mZ3Q7IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4mZ3Q7PGJyPjxicj48 YnI+PGJyPjxicj4= ------=_Part_5_1281978569536-- From mehmet.ersue@nsn.com Mon Aug 16 10:12:46 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5283A68A5 for ; Mon, 16 Aug 2010 10:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_91=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gr49nrSjEci for ; Mon, 16 Aug 2010 10:12:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id BDDBF3A67FB for ; Mon, 16 Aug 2010 10:12:44 -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 o7GHDGLd026031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Aug 2010 19:13:17 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7GHDGc5025103; Mon, 16 Aug 2010 19:13:16 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 19:13:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3D66.50C4C65E" Date: Mon, 16 Aug 2010 19:13:15 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D63295@DEMUEXC006.nsn-intra.net> In-Reply-To: <57.70.16497.AB0796C4@cm-omr6> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf]I-D Action:draft-ietf-netconf-with-defaults-11.txt thread-index: Acs9ZchOmgmKQ9lzR5K7N5SUoCk5lAAAFcfg References: <57.70.16497.AB0796C4@cm-omr6> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "t.petch" , X-OriginalArrivalTime: 16 Aug 2010 17:13:16.0448 (UTC) FILETIME=[50F67A00:01CB3D66] Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 17:12:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3D66.50C4C65E Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB3aXRoIEFuZHkuIA0KDQpXZSBuZWVkIG1vcmUgY29uY3JldGUgcHJvcG9zYWxzIGF0 IHRoaXMgbGF0ZSBzdGFnZS4NCg0KIA0KDQpNZWhtZXQgDQoNCiANCg0KRnJvbTogbmV0Y29uZi1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZXh0IEFuZHkgQmllcm1hbg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMTYsIDIwMTAgNzow OSBQTQ0KVG86IHQucGV0Y2gNCkNjOiBuZXRjb25mQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW05l dGNvbmZdSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMS50eHQN Cg0KIA0KDQpXaGF0IGNoYW5nZXMgYXJlIHlvdSByZXF1ZXN0aW5nLg0KUHJvdmlkZSBlZGl0cyBp biByZmMgZWRpdG9yIGZvcm1hdA0KDQoNCkFuZHkNCg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0t LQ0KRnJvbTogInQucGV0Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPg0KRGF0ZTogTW9uLCBBdWcg MTYsIDIwMTAgMDc6MjcNClN1YmplY3Q6IFtOZXRjb25mXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYt bmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dA0KVG86ICJBbmR5IEJpZXJtYW4iIDxpZXRmQGFu ZHliaWVybWFuLmNvbT4NCkNjOiA8bmV0Y29uZkBpZXRmLm9yZz4NCg0KDQpPSywgc28gd2Ugbm93 IGhhdmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgKG1vc3RseSkuDQoNCkkgc3RpbGwgd2FudA0K IiBUaGUgZm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtSRkM0NzQxXToNCiAgbyAgY2xp ZW50DQogIG8gIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlDQogLi4uLiAiDQpmb3IgY29uc2lzdGVu Y3kgcGx1cywgcGVyaGFwcywNCg0KZGF0YXN0b3JlOiBDb25maWd1cmF0aW9uIGRhdGFzdG9yZShz PykgYW5kIHN0YXRlIGluZm9ybWF0aW9uIGNvbGxlY3RpdmVseQ0KDQpsaWZ0aW5nIHRoYXQgaW4g cGFydCBmcm9tIGZyb20gUkZDNDc0MSBzNy43DQoNCldoaWNoIHRoZW4gbGVhdmVzIGRhdGEgbm9k ZSAoaW5zdGFuY2UpIGFuZCBKdWVyZ2VuJ3MgcG9pbnQgYWJvdXQgKG5vbi0pZXhpc3RlbmNlDQpv ZiBkZWZhdWx0cyBvdXRzdGFuZGluZy4NCg0KVG9tIFBldGNoDQoNCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0NCkZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+DQpUbzogPGktZC1h bm5vdW5jZUBpZXRmLm9yZz4NCkNjOiA8bmV0Y29uZkBpZXRmLm9yZz4NClNlbnQ6IEZyaWRheSwg QXVndXN0IDEzLCAyMDEwIDU6MzAgQU0NClN1YmplY3Q6IFtOZXRjb25mXSBJLUQgQWN0aW9uOmRy YWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dA0KDQoNCj4gQSBOZXcgSW50ZXJu ZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQpk aXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBD b25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhlDQpJRVRGLg0KPg0KPg0KPiBUaXRsZSAg ICAgICAgICAgOiBXaXRoLWRlZmF1bHRzIGNhcGFiaWxpdHkgZm9yIE5FVENPTkYNCj4gQXV0aG9y KHMpICAgICAgIDogQS4gQmllcm1hbiwgQi4gTGVuZ3llbA0KPiBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMS50eHQNCj4gUGFnZXMgICAgICAgICAg IDogMzENCj4gRGF0ZSAgICAgICAgICAgIDogMjAxMC0wOC0xMg0KPg0KPiBUaGUgTkVUQ09ORiBw cm90b2NvbCBkZWZpbmVzIHdheXMgdG8gcmVhZCBhbmQgZWRpdCBjb25maWd1cmF0aW9uIGRhdGEN Cj4gZnJvbSBhIE5FVENPTkYgc2VydmVyLiAgSW4gc29tZSBjYXNlcywgcGFydCBvZiB0aGlzIGRh dGEgbWF5IG5vdCBiZQ0KPiBzZXQgYnkgdGhlIE5FVENPTkYgY2xpZW50LCBidXQgcmF0aGVyIGEg ZGVmYXVsdCB2YWx1ZSBrbm93biB0byB0aGUNCj4gc2VydmVyIGlzIHVzZWQgaW5zdGVhZC4gIElu IG1hbnkgc2l0dWF0aW9ucyB0aGUgTkVUQ09ORiBjbGllbnQgaGFzIGENCj4gcHJpb3JpIGtub3ds ZWRnZSBhYm91dCBkZWZhdWx0IGRhdGEsIHNvIHRoZSBORVRDT05GIHNlcnZlciBkb2VzIG5vdA0K PiBuZWVkIHRvIHNhdmUgaXQgaW4gYSBORVRDT05GIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIG9y IHNlbmQgaXQgdG8NCj4gdGhlIGNsaWVudCBpbiBhIHJldHJpZXZhbCBvcGVyYXRpb24gcmVwbHku ICBJbiBvdGhlciBzaXR1YXRpb25zIHRoZQ0KPiBORVRDT05GIGNsaWVudCB3aWxsIG5lZWQgdGhp cyBkYXRhIGZyb20gdGhlIHNlcnZlci4gIE5vdCBhbGwgc2VydmVyDQo+IGltcGxlbWVudGF0aW9u cyB0cmVhdCB0aGlzIGRlZmF1bHQgZGF0YSB0aGUgc2FtZSB3YXkuICBUaGlzIGRvY3VtZW50DQo+ IGRlZmluZXMgYSBjYXBhYmlsaXR5LWJhc2VkIGV4dGVuc2lvbiB0byB0aGUgTkVUQ09ORiBwcm90 b2NvbCB0aGF0DQo+IGFsbG93cyB0aGUgTkVUQ09ORiBjbGllbnQgdG8gaWRlbnRpZnkgaG93IGRl ZmF1bHRzIGFyZSBwcm9jZXNzZWQgYnkNCj4gdGhlIHNlcnZlciwgYW5kIGFsc28gZGVmaW5lcyBu ZXcgbWVjaGFuaXNtcyBmb3IgY2xpZW50IGNvbnRyb2wgb2YNCj4gc2VydmVyIHByb2Nlc3Npbmcg b2YgZGVmYXVsdCBkYXRhLg0KPg0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1uZXRjb25m LXdpdGgtZGVmYXVsdHMtMTEudHh0DQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8NCj4NCj4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1F IGNvbXBsaWFudCBtYWlsIHJlYWRlcg0KPiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5 IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPiBJbnRlcm5ldC1EcmFmdC4NCj4N Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0 Y29uZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCj4NCg0KDQoNCg0KDQo= ------_=_NextPart_001_01CB3D66.50C4C65E Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT4N CjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICov DQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0 ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuU2VjdGlvbjEN Cgl7cGFnZTpTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9REUg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1TZWN0aW9uMT4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJW ZXJkYW5hIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz5JIGFncmVlIHdpdGggQW5keS4gPG86 cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1H QiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6Ymx1ZSc+V2UgbmVlZCBtb3JlIGNvbmNyZXRlIHByb3Bvc2FscyBhdCB0aGlz IGxhdGUgc3RhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVmVy ZGFuYSIsInNhbnMtc2VyaWYiOw0KY29sb3I6Ymx1ZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOmJsdWUnPk1laG1ldDwv c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymx1ZSc+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7DQpjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gbmV0Y29uZi1i b3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24g QmVoYWxmIE9mIDwvYj5leHQgQW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg QXVndXN0IDE2LCAyMDEwIDc6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+IHQucGV0Y2g8YnI+DQo8Yj5D Yzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25m XUktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLUdCPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+V2hhdCBjaGFuZ2VzIGFy ZSB5b3UNCnJlcXVlc3RpbmcuPGJyPg0KUHJvdmlkZSBlZGl0cyBpbiByZmMgZWRpdG9yIGZvcm1h dDxicj4NCjxicj4NCjxicj4NCkFuZHk8YnI+DQo8YnI+DQotLS0tLSBSZXBseSBtZXNzYWdlIC0t LS0tPGJyPg0KRnJvbTogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7aWV0ZmNAYnRjb25uZWN0LmNv bSZndDs8YnI+DQpEYXRlOiBNb24sIEF1ZyAxNiwgMjAxMCAwNzoyNzxicj4NClN1YmplY3Q6IFtO ZXRjb25mXSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4 dDxicj4NClRvOiAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5keWJpZXJtYW4u Y29tJmd0Ozxicj4NCkNjOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8YnI+DQo8YnI+ DQpPSywgc28gd2Ugbm93IGhhdmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgKG1vc3RseSkuPGJy Pg0KPGJyPg0KSSBzdGlsbCB3YW50PGJyPg0KJnF1b3Q7IFRoZSBmb2xsb3dpbmcgdGVybXMgYXJl IGRlZmluZWQgaW4gW1JGQzQ3NDFdOjxicj4NCiZuYnNwOyBvICZuYnNwO2NsaWVudDxicj4NCiZu YnNwOyBvICZuYnNwO2NvbmZpZ3VyYXRpb24gZGF0YXN0b3JlPGJyPg0KJm5ic3A7Li4uLiAmcXVv dDs8YnI+DQpmb3IgY29uc2lzdGVuY3kgcGx1cywgcGVyaGFwcyw8YnI+DQo8YnI+DQpkYXRhc3Rv cmU6IENvbmZpZ3VyYXRpb24gZGF0YXN0b3JlKHM/KSBhbmQgc3RhdGUgaW5mb3JtYXRpb24gY29s bGVjdGl2ZWx5PGJyPg0KPGJyPg0KbGlmdGluZyB0aGF0IGluIHBhcnQgZnJvbSBmcm9tIFJGQzQ3 NDEgczcuNzxicj4NCjxicj4NCldoaWNoIHRoZW4gbGVhdmVzIGRhdGEgbm9kZSAoaW5zdGFuY2Up IGFuZCBKdWVyZ2VuJ3MgcG9pbnQgYWJvdXQNCihub24tKWV4aXN0ZW5jZTxicj4NCm9mIGRlZmF1 bHRzIG91dHN0YW5kaW5nLjxicj4NCjxicj4NClRvbSBQZXRjaDxicj4NCjxicj4NCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQpGcm9tOiAmbHQ7SW50ZXJuZXQtRHJhZnRzQGlldGYu b3JnJmd0Ozxicj4NClRvOiAmbHQ7aS1kLWFubm91bmNlQGlldGYub3JnJmd0Ozxicj4NCkNjOiAm bHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQpTZW50OiBGcmlkYXksIEF1Z3VzdCAxMywgMjAx MCA1OjMwIEFNPGJyPg0KU3ViamVjdDogW05ldGNvbmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1u ZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHM8YnI+DQpkaXJlY3Rvcmllcy48YnI+DQomZ3Q7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBXb3JraW5nIEdyb3VwIG9mDQp0aGU8YnI+DQpJ RVRGLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaXRsZSAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDogV2l0aC1kZWZhdWx0cyBjYXBhYmlsaXR5IGZvcg0KTkVUQ09O Rjxicj4NCiZndDsgQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogQS4gQmllcm1hbiwg Qi4gTGVuZ3llbDxicj4NCiZndDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 OiBkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0xMS50eHQ8YnI+DQomZ3Q7IFBhZ2Vz ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAzMTxicj4NCiZndDsgRGF0ZSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogMjAxMC0wOC0xMjxicj4N CiZndDs8YnI+DQomZ3Q7IFRoZSBORVRDT05GIHByb3RvY29sIGRlZmluZXMgd2F5cyB0byByZWFk IGFuZCBlZGl0IGNvbmZpZ3VyYXRpb24gZGF0YTxicj4NCiZndDsgZnJvbSBhIE5FVENPTkYgc2Vy dmVyLiAmbmJzcDtJbiBzb21lIGNhc2VzLCBwYXJ0IG9mIHRoaXMgZGF0YSBtYXkgbm90IGJlPGJy Pg0KJmd0OyBzZXQgYnkgdGhlIE5FVENPTkYgY2xpZW50LCBidXQgcmF0aGVyIGEgZGVmYXVsdCB2 YWx1ZSBrbm93biB0byB0aGU8YnI+DQomZ3Q7IHNlcnZlciBpcyB1c2VkIGluc3RlYWQuICZuYnNw O0luIG1hbnkgc2l0dWF0aW9ucyB0aGUgTkVUQ09ORiBjbGllbnQgaGFzIGE8YnI+DQomZ3Q7IHBy aW9yaSBrbm93bGVkZ2UgYWJvdXQgZGVmYXVsdCBkYXRhLCBzbyB0aGUgTkVUQ09ORiBzZXJ2ZXIg ZG9lcyBub3Q8YnI+DQomZ3Q7IG5lZWQgdG8gc2F2ZSBpdCBpbiBhIE5FVENPTkYgY29uZmlndXJh dGlvbiBkYXRhc3RvcmUgb3Igc2VuZCBpdCB0bzxicj4NCiZndDsgdGhlIGNsaWVudCBpbiBhIHJl dHJpZXZhbCBvcGVyYXRpb24gcmVwbHkuICZuYnNwO0luIG90aGVyIHNpdHVhdGlvbnMgdGhlPGJy Pg0KJmd0OyBORVRDT05GIGNsaWVudCB3aWxsIG5lZWQgdGhpcyBkYXRhIGZyb20gdGhlIHNlcnZl ci4gJm5ic3A7Tm90IGFsbCBzZXJ2ZXI8YnI+DQomZ3Q7IGltcGxlbWVudGF0aW9ucyB0cmVhdCB0 aGlzIGRlZmF1bHQgZGF0YSB0aGUgc2FtZSB3YXkuICZuYnNwO1RoaXMgZG9jdW1lbnQ8YnI+DQom Z3Q7IGRlZmluZXMgYSBjYXBhYmlsaXR5LWJhc2VkIGV4dGVuc2lvbiB0byB0aGUgTkVUQ09ORiBw cm90b2NvbCB0aGF0PGJyPg0KJmd0OyBhbGxvd3MgdGhlIE5FVENPTkYgY2xpZW50IHRvIGlkZW50 aWZ5IGhvdyBkZWZhdWx0cyBhcmUgcHJvY2Vzc2VkIGJ5PGJyPg0KJmd0OyB0aGUgc2VydmVyLCBh bmQgYWxzbyBkZWZpbmVzIG5ldyBtZWNoYW5pc21zIGZvciBjbGllbnQgY29udHJvbCBvZjxicj4N CiZndDsgc2VydmVyIHByb2Nlc3Npbmcgb2YgZGVmYXVsdCBkYXRhLjxicj4NCiZndDs8YnI+DQom Z3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4NCiZndDsgPGENCmhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi13 aXRoLWRlZmF1bHRzLTExLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PC9hPjxicj4NCiZndDs8YnI+ DQomZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDo8YnI+DQomZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPGJyPg0K Jmd0Ozxicj4NCiZndDsgQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1F IGNvbXBsaWFudCBtYWlsIHJlYWRlcjxicj4NCiZndDsgaW1wbGVtZW50YXRpb24gdG8gYXV0b21h dGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQomZ3Q7IEludGVy bmV0LURyYWZ0Ljxicj4NCiZndDs8YnI+DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCjxicj4NCjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KJmd0 OyBOZXRjb25mQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZjwvYT48YnI+DQomZ3Q7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo= ------_=_NextPart_001_01CB3D66.50C4C65E-- From kwatsen@juniper.net Mon Aug 16 11:03:12 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0769C3A69FB for ; Mon, 16 Aug 2010 11:03:12 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIF4i0TfRN-K for ; Mon, 16 Aug 2010 11:03:11 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id 0913F3A6807 for ; Mon, 16 Aug 2010 11:03:11 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTGl9gCcxXW7uU5AS2KatFg5ra6dPXncy@postini.com; Mon, 16 Aug 2010 11:03:47 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, 16 Aug 2010 10:45:26 -0700 From: Kent Watsen To: Andy Bierman , Wes Hardaker Date: Mon, 16 Aug 2010 10:45:25 -0700 Thread-Topic: [Netconf] how to handle XML parse errors Thread-Index: Acs8pJeGFF1+Hj8UT+aA4Mq5D2Tk4AAw68lQ Message-ID: <84600D05C20FF943918238042D7670FD36D7087EF1@EMBX01-HQ.jnpr.net> References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> In-Reply-To: <4C682CA6.2040703@andybierman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:03:12 -0000 AB> So I remove my objection, and that means there should be AB> no open issues and 4741bis can go to the IESG right away. I may be missing the subtleties in this, but it seems that closing the sess= ion is a bit heavy handed. First, I don't view this as a security issue. If security is a concern, th= en a proper transport should be used (i.e. SSH, TLS, etc.). Second, the proposed modification says "if a peer receives...", but it seem= s that more appropriate actions can account for which side of the connectio= n the peer is on. For instance, a server can return an rpc-error while a c= lient might execute the RPC again, assuming that the RPC is safe and/or ide= mpotent... Thanks, Kent From randy_presuhn@mindspring.com Mon Aug 16 11:15:38 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE35C3A6A0F for ; Mon, 16 Aug 2010 11:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.866 X-Spam-Level: X-Spam-Status: No, score=-100.866 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ywHPGBfFrQa for ; Mon, 16 Aug 2010 11:15:35 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 59D3D3A6A18 for ; Mon, 16 Aug 2010 11:15:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Hez1LnYiXuEAkLxf5giRhLLGDSeOl+hbs761naPHj+YtU5PDFyXKlYdQOZhRzoWb; 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.55.172.34] (helo=oemcomputer) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Ol4EE-0002Y4-Sv for netconf@ietf.org; Mon, 16 Aug 2010 14:16:11 -0400 Message-ID: <000801cb3d6f$25d3e8e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com><4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D7087EF1@EMBX01-HQ.jnpr.net> Date: Mon, 16 Aug 2010 11:16:27 -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: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fee42c712a715b42804a2b951f9ad07ee1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.55.172.34 Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:15:38 -0000 Hi - > From: "Kent Watsen" > To: "Andy Bierman" ; "Wes Hardaker" > Cc: > Sent: Monday, August 16, 2010 10:45 AM > Subject: Re: [Netconf] how to handle XML parse errors ... > I may be missing the subtleties in this, but it seems that closing the session is a bit heavy handed. > > First, I don't view this as a security issue. If security is a concern, then a proper > transport should be used (i.e. SSH, TLS, etc.). > > Second, the proposed modification says "if a peer receives...", but it seems > that more appropriate actions can account for which side of the connection > the peer is on. For instance, a server can return an rpc-error while a client > might execute the RPC again, assuming that the RPC is safe and/or idempotent... If the bad XML was generated by software, there is little hope that re-trying the operation might somehow produce a different result. The only use case I can think of where it would make sense to try to second-guess broken XML by attempting to re-synchronize would be where there is a human at the other end of the connection, manually typing in Netconf PDUs. Supporting that use case would have been in keeping with the spirit of the discussion at the IAB workshop, but as the Netconf protocol has evolved it seems like it might be more trouble than it would be worth. Randy From wjhns1@hardakers.net Mon Aug 16 12:50:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53193A6A7D for ; Mon, 16 Aug 2010 12:50:50 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX3TqO8s3wD4 for ; Mon, 16 Aug 2010 12:50:50 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D57F13A6A2B for ; Mon, 16 Aug 2010 12:50:49 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 298A4980D7; Mon, 16 Aug 2010 12:51:25 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> Date: Mon, 16 Aug 2010 12:51:23 -0700 In-Reply-To: <4C682CA6.2040703@andybierman.com> (Andy Bierman's message of "Sun, 15 Aug 2010 11:06:30 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 19:50:51 -0000 >>>>> On Sun, 15 Aug 2010 11:06:30 -0700, Andy Bierman said: AB> OK -- I see what Wes is trying to do -- close the security hole that AB> exists, because the 'EOM' marker in SSH is actually allowed in AB> content, so it is an unsafe marker. FYI, I agree that was one and the primary goal in my mind. After thinking about it a lot since that original issue came up, I'm not sure it's ever wise to accept a series of management requests over a stream when one in the middle is broken. If you get three messages A, B, and C and can't parse B it's certainly likely that C shouldn't be executed if it is highly dependent on the message B succeeding. Yes, the manager SHOULD wait for a positive response before sending C but in many networks this may not be easily possible (see the DTN RG for examples). -- Wes Hardaker Cobham Analytic Solutions From ietfc@btconnect.com Mon Aug 16 13:06:17 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE413A6A53 for ; Mon, 16 Aug 2010 13:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_20=-0.74, J_CHICKENPOX_15=0.6, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfD+CTkpIpx1 for ; Mon, 16 Aug 2010 13:06:16 -0700 (PDT) Received: from c2beaomr01.btconnect.com (c2beaomr01.btconnect.com [213.123.26.179]) by core3.amsl.com (Postfix) with ESMTP id 6736F3A6A81 for ; Mon, 16 Aug 2010 13:06:16 -0700 (PDT) Received: from pc6 (host81-156-71-186.range81-156.btcentralplus.com [81.156.71.186]) by c2beaomr01.btconnect.com with SMTP id FPY65179; Mon, 16 Aug 2010 21:06:47 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C699A57.0114, actions=tag Message-ID: <00dd01cb3d75$81dcf2c0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Ersue, Mehmet \(NSN - DE/Munich\)" , References: <57.70.16497.AB0796C4@cm-omr6> <80A0822C5E9A4440A5117C2F4CD36A64D63295@DEMUEXC006.nsn-intra.net> Date: Mon, 16 Aug 2010 21:01:56 +0200 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-Junkmail-Status: score=10/50, host=c2beaomr01.btconnect.com X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A0B0201.4C699A58.01F6,ss=1,fgs=0, ip=0.0.0.0, so=2009-07-20 21:54:04, dmn=5.7.1/2009-08-27, mode=single engine X-Junkmail-IWF: false Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 20:06:18 -0000 ----- Original Message ----- From: "Ersue, Mehmet (NSN - DE/Munich)" To: "t.petch" ; Sent: Monday, August 16, 2010 7:13 PM > I agree with Andy. > > We need more concrete proposals at this late stage. > > Mehmet > > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Andy Bierman > Sent: Monday, August 16, 2010 7:09 PM > To: t.petch > Cc: netconf@ietf.org > > What changes are you requesting. > Provide edits in rfc editor format Sorry, I am not familiar with RFC Editor format but I am proposing that where section 1.1 currently contains " The following terms are defined in [RFC4741]: o client o datastore" that that should be amended to " The following terms are defined in [RFC4741]: o client o configuration datastore" on the grounds (as I said before) that it is configuration datastore that is defined in RFC4741 and not datastore. Following on from the introduction of 'configuration datastore', I believe that the usage of 'datastore' (unqualified) in the definition of 'default data' is intended to include state as well as configuration data and as such needs defining ; hence I suggest adding a definition for it to section 1.1, namely datastore: Configuration datastore(s?) and state information collectively (not sure if that should be singular or plural) Of course, if I am misconstruing the definition of 'default data' then this does not apply. Those are the two changes that I am proposing. Tom Petch > > Andy > > ----- Reply message ----- > From: "t.petch" > Date: Mon, Aug 16, 2010 07:27 > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt > To: "Andy Bierman" > Cc: > > > OK, so we now have configuration datastore (mostly). > > I still want > " The following terms are defined in [RFC4741]: > o client > o configuration datastore > .... " > for consistency plus, perhaps, > > datastore: Configuration datastore(s?) and state information collectively > > lifting that in part from from RFC4741 s7.7 > > Which then leaves data node (instance) and Juergen's point about (non-)existence > of defaults outstanding. > > Tom Petch > > ----- Original Message ----- > From: > To: > Cc: > Sent: Friday, August 13, 2010 5:30 AM > Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Network Configuration Working Group of the > IETF. > > > > > > Title : With-defaults capability for NETCONF > > Author(s) : A. Bierman, B. Lengyel > > Filename : draft-ietf-netconf-with-defaults-11.txt > > Pages : 31 > > Date : 2010-08-12 > > > > The NETCONF protocol defines ways to read and edit configuration data > > from a NETCONF server. In some cases, part of this data may not be > > set by the NETCONF client, but rather a default value known to the > > server is used instead. In many situations the NETCONF client has a > > priori knowledge about default data, so the NETCONF server does not > > need to save it in a NETCONF configuration datastore or send it to > > the client in a retrieval operation reply. In other situations the > > NETCONF client will need this data from the server. Not all server > > implementations treat this default data the same way. This document > > defines a capability-based extension to the NETCONF protocol that > > allows the NETCONF client to identify how defaults are processed by > > the server, and also defines new mechanisms for client control of > > server processing of default data. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-11.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ------------------------------------------------------------------------------ -- > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > From kwatsen@juniper.net Mon Aug 16 13:29:05 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD363A6A90 for ; Mon, 16 Aug 2010 13:29:05 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bct9oqOVw+vY for ; Mon, 16 Aug 2010 13:29:04 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 44F213A6AA5 for ; Mon, 16 Aug 2010 13:29:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTGmfshi20zV+EqvSIya/sORDJR8Yn0sm@postini.com; Mon, 16 Aug 2010 13:29:40 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, 16 Aug 2010 13:12:03 -0700 From: Kent Watsen To: Wes Hardaker , Andy Bierman Date: Mon, 16 Aug 2010 13:12:01 -0700 Thread-Topic: [Netconf] how to handle XML parse errors Thread-Index: Acs9fGyzu9ibR921S/uNLcWJGQZqVQAAYRYg Message-ID: <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 20:29:05 -0000 I'm wondering if this is an academic exercise or if there is an actual prob= lem being solved here. I'm having a hard time believing that an attacker c= ould stage a successful man in the middle when the transport is either SSH = or SSL/TLS...and, if they were that sophisticated, surely they would termin= ate the XML correctly. Is this only an issue for when the transport is not encrypted? Thanks, Kent From ietf@andybierman.com Mon Aug 16 13:48:59 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8473A68DC for ; Mon, 16 Aug 2010 13:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, J_CHICKENPOX_91=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwPLDDI6HT2C for ; Mon, 16 Aug 2010 13:48:57 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by core3.amsl.com (Postfix) with ESMTP id 02E3E3A684B for ; Mon, 16 Aug 2010 13:48:48 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7GKnO8p013564 for ; Mon, 16 Aug 2010 16:49:24 -0400 Authentication-Results: cm-omr4 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.112.59.129] ([108.112.59.129:60526] helo=[108.112.59.129]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id BC/81-05353-054A96C4; Mon, 16 Aug 2010 16:49:24 -0400 To: "=?utf-8?B?dC5wZXRjaA==?=" , "=?utf-8?B?RXJzdWUsIE1laG1ldCBcKE5TTiAtIERFL011bmljaFwp?=" , netconf@ietf.org Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Mon, 16 Aug 2010 13:49:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_1281991778215" Subject: Re: [Netconf] =?utf-8?q?I-D_Action=3Adraft-ietf-netconf-with-defaults?= =?utf-8?q?-11=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 20:48:59 -0000 ------=_Part_7_1281991778215 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UmZjIGVkaXRvciBmb3JtYXQgaXMKT0xEOgoKTkVXOgoKClRoaXMgZG9jdW1lbnQgZG9lcyBub3Qg bmVlZCB0byBkZWZpbmUgc3RhdGUgZGF0YS4gIElmIHRoZSBnZXQgb3AgaXMgZ2l2ZW4gd2l0aCB0 aGUgdy1kIGxlYWYsIHRoZW4gdGhlIHNlcnZlciBuZWVkcyB0byBmaWx0ZXIgb3V0IGRlZmF1bHRz IGFzIHJlcXVlc3RlZC4gIFRoZSBzY2hlbWEgZGVmYXVsdCB2YWx1ZSBpcyBub3QgcmVsYXRlZCB0 byBjb25maWctc3RtdC4KCkl0IGlzIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbCBob3cgdGhlIHNl cnZlciBjb21iaW5lcyBzdGF0ZSBhbmQgY29uZmlnIGludG8gYW4gWE1MIG1lc3NhZ2UuCgpBbmR5 CgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAidC5wZXRjaCIgPGlldGZjQGJ0Y29u bmVjdC5jb20+CkRhdGU6IE1vbiwgQXVnIDE2LCAyMDEwIDEyOjAxClN1YmplY3Q6IFtOZXRjb25m XUktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0ClRvOiAi RXJzdWUsIE1laG1ldCBcKE5TTiAtIERFL011bmljaFwpIiA8bWVobWV0LmVyc3VlQG5zbi5jb20+ LCA8bmV0Y29uZkBpZXRmLm9yZz4KQ2M6ICJleHQgQW5keSBCaWVybWFuIiA8aWV0ZkBhbmR5Ymll cm1hbi5jb20+CgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiAiRXJzdWUsIE1l aG1ldCAoTlNOIC0gREUvTXVuaWNoKSIgPG1laG1ldC5lcnN1ZUBuc24uY29tPgpUbzogInQucGV0 Y2giIDxpZXRmY0BidGNvbm5lY3QuY29tPjsgPG5ldGNvbmZAaWV0Zi5vcmc+ClNlbnQ6IE1vbmRh eSwgQXVndXN0IDE2LCAyMDEwIDc6MTMgUE0KCj4gSSBhZ3JlZSB3aXRoIEFuZHkuCj4KPiBXZSBu ZWVkIG1vcmUgY29uY3JldGUgcHJvcG9zYWxzIGF0IHRoaXMgbGF0ZSBzdGFnZS4KPgo+IE1laG1l dAo+Cj4gRnJvbTogbmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YKZXh0IEFuZHkgQmllcm1hbgo+IFNlbnQ6IE1vbmRh eSwgQXVndXN0IDE2LCAyMDEwIDc6MDkgUE0KPiBUbzogdC5wZXRjaAo+IENjOiBuZXRjb25mQGll dGYub3JnCj4KPiBXaGF0IGNoYW5nZXMgYXJlIHlvdSByZXF1ZXN0aW5nLgo+IFByb3ZpZGUgZWRp dHMgaW4gcmZjIGVkaXRvciBmb3JtYXQKClNvcnJ5LCBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIFJG QyBFZGl0b3IgZm9ybWF0IGJ1dCBJIGFtIHByb3Bvc2luZyB0aGF0IHdoZXJlCnNlY3Rpb24gMS4x IGN1cnJlbnRseSBjb250YWlucwoiICAgVGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgZGVmaW5lZCBp biBbUkZDNDc0MV06CiAgIG8gIGNsaWVudAogICBvICBkYXRhc3RvcmUiCnRoYXQgdGhhdCBzaG91 bGQgYmUgYW1lbmRlZCB0bwogIiBUaGUgZm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtS RkM0NzQxXToKICAgbyAgY2xpZW50CiAgIG8gIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIgpvbiB0 aGUgZ3JvdW5kcyAoYXMgSSBzYWlkIGJlZm9yZSkgdGhhdCBpdCBpcyBjb25maWd1cmF0aW9uIGRh dGFzdG9yZSB0aGF0IGlzCmRlZmluZWQgaW4gUkZDNDc0MSBhbmQgbm90IGRhdGFzdG9yZS4KCkZv bGxvd2luZyBvbiBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24gb2YgJ2NvbmZpZ3VyYXRpb24gZGF0YXN0 b3JlJywgIEkgYmVsaWV2ZSB0aGF0CnRoZSB1c2FnZSBvZiAnZGF0YXN0b3JlJyAodW5xdWFsaWZp ZWQpIGluIHRoZSBkZWZpbml0aW9uIG9mICdkZWZhdWx0IGRhdGEnIGlzCmludGVuZGVkIHRvIGlu Y2x1ZGUgc3RhdGUgYXMgd2VsbCBhcyBjb25maWd1cmF0aW9uIGRhdGEgYW5kIGFzIHN1Y2ggbmVl ZHMKZGVmaW5pbmcgOyBoZW5jZSBJIHN1Z2dlc3QgYWRkaW5nIGEgZGVmaW5pdGlvbiBmb3IgaXQg dG8gc2VjdGlvbiAxLjEsIG5hbWVseQogZGF0YXN0b3JlOiBDb25maWd1cmF0aW9uIGRhdGFzdG9y ZShzPykgYW5kIHN0YXRlIGluZm9ybWF0aW9uIGNvbGxlY3RpdmVseQoobm90IHN1cmUgaWYgdGhh dCBzaG91bGQgYmUgc2luZ3VsYXIgb3IgcGx1cmFsKQpPZiBjb3Vyc2UsIGlmIEkgYW0gbWlzY29u c3RydWluZyB0aGUgZGVmaW5pdGlvbiBvZiAnZGVmYXVsdCBkYXRhJyB0aGVuIHRoaXMgZG9lcwpu b3QgYXBwbHkuCgpUaG9zZSBhcmUgdGhlIHR3byBjaGFuZ2VzIHRoYXQgSSBhbSBwcm9wb3Npbmcu CgpUb20gUGV0Y2gKPgo+IEFuZHkKPgo+IC0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KPiBGcm9t OiAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+Cj4gRGF0ZTogTW9uLCBBdWcgMTYsIDIw MTAgMDc6MjcKPiBTdWJqZWN0OiBbTmV0Y29uZl0gSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNv bmYtd2l0aC1kZWZhdWx0cy0xMS50eHQKPiBUbzogIkFuZHkgQmllcm1hbiIgPGlldGZAYW5keWJp ZXJtYW4uY29tPgo+IENjOiA8bmV0Y29uZkBpZXRmLm9yZz4KPgo+Cj4gT0ssIHNvIHdlIG5vdyBo YXZlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIChtb3N0bHkpLgo+Cj4gSSBzdGlsbCB3YW50Cj4g IiBUaGUgZm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGluIFtSRkM0NzQxXToKPiAgIG8gIGNs aWVudAo+ICAgbyAgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUKPiAgLi4uLiAiCj4gZm9yIGNvbnNp c3RlbmN5IHBsdXMsIHBlcmhhcHMsCj4KPiBkYXRhc3RvcmU6IENvbmZpZ3VyYXRpb24gZGF0YXN0 b3JlKHM/KSBhbmQgc3RhdGUgaW5mb3JtYXRpb24gY29sbGVjdGl2ZWx5Cj4KPiBsaWZ0aW5nIHRo YXQgaW4gcGFydCBmcm9tIGZyb20gUkZDNDc0MSBzNy43Cj4KPiBXaGljaCB0aGVuIGxlYXZlcyBk YXRhIG5vZGUgKGluc3RhbmNlKSBhbmQgSnVlcmdlbidzIHBvaW50IGFib3V0Cihub24tKWV4aXN0 ZW5jZQo+IG9mIGRlZmF1bHRzIG91dHN0YW5kaW5nLgo+Cj4gVG9tIFBldGNoCj4KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogPEludGVybmV0LURyYWZ0c0BpZXRmLm9yZz4K PiBUbzogPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4KPiBDYzogPG5ldGNvbmZAaWV0Zi5vcmc+Cj4g U2VudDogRnJpZGF5LCBBdWd1c3QgMTMsIDIwMTAgNTozMCBBTQo+IFN1YmplY3Q6IFtOZXRjb25m XSBJLUQgQWN0aW9uOmRyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dAo+Cj4K PiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu dGVybmV0LURyYWZ0cwo+IGRpcmVjdG9yaWVzLgo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRl bSBvZiB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFdvcmtpbmcgR3JvdXAgb2YgdGhlCj4gSUVU Ri4KPiA+Cj4gPgo+ID4gVGl0bGUgICAgICAgICAgIDogV2l0aC1kZWZhdWx0cyBjYXBhYmlsaXR5 IGZvciBORVRDT05GCj4gPiBBdXRob3IocykgICAgICAgOiBBLiBCaWVybWFuLCBCLiBMZW5neWVs Cj4gPiBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZhdWx0cy0x MS50eHQKPiA+IFBhZ2VzICAgICAgICAgICA6IDMxCj4gPiBEYXRlICAgICAgICAgICAgOiAyMDEw LTA4LTEyCj4gPgo+ID4gVGhlIE5FVENPTkYgcHJvdG9jb2wgZGVmaW5lcyB3YXlzIHRvIHJlYWQg YW5kIGVkaXQgY29uZmlndXJhdGlvbiBkYXRhCj4gPiBmcm9tIGEgTkVUQ09ORiBzZXJ2ZXIuICBJ biBzb21lIGNhc2VzLCBwYXJ0IG9mIHRoaXMgZGF0YSBtYXkgbm90IGJlCj4gPiBzZXQgYnkgdGhl IE5FVENPTkYgY2xpZW50LCBidXQgcmF0aGVyIGEgZGVmYXVsdCB2YWx1ZSBrbm93biB0byB0aGUK PiA+IHNlcnZlciBpcyB1c2VkIGluc3RlYWQuICBJbiBtYW55IHNpdHVhdGlvbnMgdGhlIE5FVENP TkYgY2xpZW50IGhhcyBhCj4gPiBwcmlvcmkga25vd2xlZGdlIGFib3V0IGRlZmF1bHQgZGF0YSwg c28gdGhlIE5FVENPTkYgc2VydmVyIGRvZXMgbm90Cj4gPiBuZWVkIHRvIHNhdmUgaXQgaW4gYSBO RVRDT05GIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIG9yIHNlbmQgaXQgdG8KPiA+IHRoZSBjbGll bnQgaW4gYSByZXRyaWV2YWwgb3BlcmF0aW9uIHJlcGx5LiAgSW4gb3RoZXIgc2l0dWF0aW9ucyB0 aGUKPiA+IE5FVENPTkYgY2xpZW50IHdpbGwgbmVlZCB0aGlzIGRhdGEgZnJvbSB0aGUgc2VydmVy LiAgTm90IGFsbCBzZXJ2ZXIKPiA+IGltcGxlbWVudGF0aW9ucyB0cmVhdCB0aGlzIGRlZmF1bHQg ZGF0YSB0aGUgc2FtZSB3YXkuICBUaGlzIGRvY3VtZW50Cj4gPiBkZWZpbmVzIGEgY2FwYWJpbGl0 eS1iYXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgdGhhdAo+ID4gYWxsb3dz IHRoZSBORVRDT05GIGNsaWVudCB0byBpZGVudGlmeSBob3cgZGVmYXVsdHMgYXJlIHByb2Nlc3Nl ZCBieQo+ID4gdGhlIHNlcnZlciwgYW5kIGFsc28gZGVmaW5lcyBuZXcgbWVjaGFuaXNtcyBmb3Ig Y2xpZW50IGNvbnRyb2wgb2YKPiA+IHNlcnZlciBwcm9jZXNzaW5nIG9mIGRlZmF1bHQgZGF0YS4K PiA+Cj4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoKPiA+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRz LTExLnR4dAo+ID4KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoKPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4g Pgo+ID4gQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFu dCBtYWlsIHJlYWRlcgo+ID4gaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUKPiA+IEludGVybmV0LURyYWZ0Lgo+ID4KPgo+Cj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCi0tCj4KPgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+IE5ldGNvbmYgbWFpbGluZyBsaXN0Cj4gPiBOZXRj b25mQGlldGYub3JnCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYKPiA+Cj4KPgo+Cj4KPgo+CgoK ------=_Part_7_1281991778215 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UmZjIGVkaXRvciBmb3JtYXQgaXM8YnI+T0xEOjxicj48YnI+TkVXOjxicj48YnI+PGJyPlRoaXMg ZG9jdW1lbnQgZG9lcyBub3QgbmVlZCB0byBkZWZpbmUgc3RhdGUgZGF0YS4gJm5ic3A7SWYgdGhl IGdldCBvcCBpcyBnaXZlbiB3aXRoIHRoZSB3LWQgbGVhZiwgdGhlbiB0aGUgc2VydmVyIG5lZWRz IHRvIGZpbHRlciBvdXQgZGVmYXVsdHMgYXMgcmVxdWVzdGVkLiAmbmJzcDtUaGUgc2NoZW1hIGRl ZmF1bHQgdmFsdWUgaXMgbm90IHJlbGF0ZWQgdG8gY29uZmlnLXN0bXQuPGJyPjxicj5JdCBpcyBh biBpbXBsZW1lbnRhdGlvbiBkZXRhaWwgaG93IHRoZSBzZXJ2ZXIgY29tYmluZXMgc3RhdGUgYW5k IGNvbmZpZyBpbnRvIGFuIFhNTCBtZXNzYWdlLjxicj48YnI+QW5keTxicj48YnI+PGJyPi0tLS0t IFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTogJnF1b3Q7dC5wZXRjaCZxdW90OyAmbHQ7aWV0 ZmNAYnRjb25uZWN0LmNvbSZndDs8YnI+RGF0ZTogTW9uLCBBdWcgMTYsIDIwMTAgMTI6MDE8YnI+ U3ViamVjdDogW05ldGNvbmZdSS1EIEFjdGlvbjpkcmFmdC1pZXRmLW5ldGNvbmYtd2l0aC1kZWZh dWx0cy0xMS50eHQ8YnI+VG86ICZxdW90O0Vyc3VlLCBNZWhtZXQgXChOU04gLSBERS9NdW5pY2hc KSZxdW90OyAmbHQ7bWVobWV0LmVyc3VlQG5zbi5jb20mZ3Q7LCAmbHQ7bmV0Y29uZkBpZXRmLm9y ZyZndDs8YnI+Q2M6ICZxdW90O2V4dCBBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5keWJp ZXJtYW4uY29tJmd0Ozxicj48YnI+PGJyPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+ RnJvbTogJnF1b3Q7RXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKSZxdW90OyAmbHQ7bWVo bWV0LmVyc3VlQG5zbi5jb20mZ3Q7PGJyPlRvOiAmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDtpZXRm Y0BidGNvbm5lY3QuY29tJmd0OzsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPlNlbnQ6IE1v bmRheSwgQXVndXN0IDE2LCAyMDEwIDc6MTMgUE08YnI+PGJyPiZndDsgSSBhZ3JlZSB3aXRoIEFu ZHkuPGJyPiZndDs8YnI+Jmd0OyBXZSBuZWVkIG1vcmUgY29uY3JldGUgcHJvcG9zYWxzIGF0IHRo aXMgbGF0ZSBzdGFnZS48YnI+Jmd0Ozxicj4mZ3Q7IE1laG1ldDxicj4mZ3Q7PGJyPiZndDsgRnJv bTogbmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2Y8YnI+ZXh0IEFuZHkgQmllcm1hbjxicj4mZ3Q7IFNlbnQ6IE1vbmRh eSwgQXVndXN0IDE2LCAyMDEwIDc6MDkgUE08YnI+Jmd0OyBUbzogdC5wZXRjaDxicj4mZ3Q7IENj OiBuZXRjb25mQGlldGYub3JnPGJyPiZndDs8YnI+Jmd0OyBXaGF0IGNoYW5nZXMgYXJlIHlvdSBy ZXF1ZXN0aW5nLjxicj4mZ3Q7IFByb3ZpZGUgZWRpdHMgaW4gcmZjIGVkaXRvciBmb3JtYXQ8YnI+ PGJyPlNvcnJ5LCBJIGFtIG5vdCBmYW1pbGlhciB3aXRoIFJGQyBFZGl0b3IgZm9ybWF0IGJ1dCBJ IGFtIHByb3Bvc2luZyB0aGF0IHdoZXJlPGJyPnNlY3Rpb24gMS4xIGN1cnJlbnRseSBjb250YWlu czxicj4mcXVvdDsgJm5ic3A7IFRoZSBmb2xsb3dpbmcgdGVybXMgYXJlIGRlZmluZWQgaW4gW1JG QzQ3NDFdOjxicj4gJm5ic3A7IG8gJm5ic3A7Y2xpZW50PGJyPiAmbmJzcDsgbyAmbmJzcDtkYXRh c3RvcmUmcXVvdDs8YnI+dGhhdCB0aGF0IHNob3VsZCBiZSBhbWVuZGVkIHRvPGJyPiAmcXVvdDsg VGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgZGVmaW5lZCBpbiBbUkZDNDc0MV06PGJyPiAmbmJzcDsg byAmbmJzcDtjbGllbnQ8YnI+ICZuYnNwOyBvICZuYnNwO2NvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl JnF1b3Q7PGJyPm9uIHRoZSBncm91bmRzIChhcyBJIHNhaWQgYmVmb3JlKSB0aGF0IGl0IGlzIGNv bmZpZ3VyYXRpb24gZGF0YXN0b3JlIHRoYXQgaXM8YnI+ZGVmaW5lZCBpbiBSRkM0NzQxIGFuZCBu b3QgZGF0YXN0b3JlLjxicj48YnI+Rm9sbG93aW5nIG9uIGZyb20gdGhlIGludHJvZHVjdGlvbiBv ZiAmIzM5O2NvbmZpZ3VyYXRpb24gZGF0YXN0b3JlJiMzOTssICZuYnNwO0kgYmVsaWV2ZSB0aGF0 PGJyPnRoZSB1c2FnZSBvZiAmIzM5O2RhdGFzdG9yZSYjMzk7ICh1bnF1YWxpZmllZCkgaW4gdGhl IGRlZmluaXRpb24gb2YgJiMzOTtkZWZhdWx0IGRhdGEmIzM5OyBpczxicj5pbnRlbmRlZCB0byBp bmNsdWRlIHN0YXRlIGFzIHdlbGwgYXMgY29uZmlndXJhdGlvbiBkYXRhIGFuZCBhcyBzdWNoIG5l ZWRzPGJyPmRlZmluaW5nIDsgaGVuY2UgSSBzdWdnZXN0IGFkZGluZyBhIGRlZmluaXRpb24gZm9y IGl0IHRvIHNlY3Rpb24gMS4xLCBuYW1lbHk8YnI+IGRhdGFzdG9yZTogQ29uZmlndXJhdGlvbiBk YXRhc3RvcmUocz8pIGFuZCBzdGF0ZSBpbmZvcm1hdGlvbiBjb2xsZWN0aXZlbHk8YnI+KG5vdCBz dXJlIGlmIHRoYXQgc2hvdWxkIGJlIHNpbmd1bGFyIG9yIHBsdXJhbCk8YnI+T2YgY291cnNlLCBp ZiBJIGFtIG1pc2NvbnN0cnVpbmcgdGhlIGRlZmluaXRpb24gb2YgJiMzOTtkZWZhdWx0IGRhdGEm IzM5OyB0aGVuIHRoaXMgZG9lczxicj5ub3QgYXBwbHkuPGJyPjxicj5UaG9zZSBhcmUgdGhlIHR3 byBjaGFuZ2VzIHRoYXQgSSBhbSBwcm9wb3NpbmcuPGJyPjxicj5Ub20gUGV0Y2g8YnI+Jmd0Ozxi cj4mZ3Q7IEFuZHk8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+ Jmd0OyBGcm9tOiAmcXVvdDt0LnBldGNoJnF1b3Q7ICZsdDtpZXRmY0BidGNvbm5lY3QuY29tJmd0 Ozxicj4mZ3Q7IERhdGU6IE1vbiwgQXVnIDE2LCAyMDEwIDA3OjI3PGJyPiZndDsgU3ViamVjdDog W05ldGNvbmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEu dHh0PGJyPiZndDsgVG86ICZxdW90O0FuZHkgQmllcm1hbiZxdW90OyAmbHQ7aWV0ZkBhbmR5Ymll cm1hbi5jb20mZ3Q7PGJyPiZndDsgQ2M6ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0OyBPSywgc28gd2Ugbm93IGhhdmUgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmUgKG1vc3RseSkuPGJyPiZndDs8YnI+Jmd0OyBJIHN0aWxsIHdhbnQ8YnI+Jmd0OyAmcXVvdDsg VGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUgZGVmaW5lZCBpbiBbUkZDNDc0MV06PGJyPiZndDsgJm5i c3A7IG8gJm5ic3A7Y2xpZW50PGJyPiZndDsgJm5ic3A7IG8gJm5ic3A7Y29uZmlndXJhdGlvbiBk YXRhc3RvcmU8YnI+Jmd0OyAmbmJzcDsuLi4uICZxdW90Ozxicj4mZ3Q7IGZvciBjb25zaXN0ZW5j eSBwbHVzLCBwZXJoYXBzLDxicj4mZ3Q7PGJyPiZndDsgZGF0YXN0b3JlOiBDb25maWd1cmF0aW9u IGRhdGFzdG9yZShzPykgYW5kIHN0YXRlIGluZm9ybWF0aW9uIGNvbGxlY3RpdmVseTxicj4mZ3Q7 PGJyPiZndDsgbGlmdGluZyB0aGF0IGluIHBhcnQgZnJvbSBmcm9tIFJGQzQ3NDEgczcuNzxicj4m Z3Q7PGJyPiZndDsgV2hpY2ggdGhlbiBsZWF2ZXMgZGF0YSBub2RlIChpbnN0YW5jZSkgYW5kIEp1 ZXJnZW4mIzM5O3MgcG9pbnQgYWJvdXQ8YnI+KG5vbi0pZXhpc3RlbmNlPGJyPiZndDsgb2YgZGVm YXVsdHMgb3V0c3RhbmRpbmcuPGJyPiZndDs8YnI+Jmd0OyBUb20gUGV0Y2g8YnI+Jmd0Ozxicj4m Z3Q7IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyBGcm9tOiAmbHQ7SW50ZXJu ZXQtRHJhZnRzQGlldGYub3JnJmd0Ozxicj4mZ3Q7IFRvOiAmbHQ7aS1kLWFubm91bmNlQGlldGYu b3JnJmd0Ozxicj4mZ3Q7IENjOiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+Jmd0OyBTZW50 OiBGcmlkYXksIEF1Z3VzdCAxMywgMjAxMCA1OjMwIEFNPGJyPiZndDsgU3ViamVjdDogW05ldGNv bmZdIEktRCBBY3Rpb246ZHJhZnQtaWV0Zi1uZXRjb25mLXdpdGgtZGVmYXVsdHMtMTEudHh0PGJy PiZndDs8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPiZndDsgZGlyZWN0b3JpZXMu PGJyPiZndDsgJmd0OyBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBOZXR3b3JrIENv bmZpZ3VyYXRpb24gV29ya2luZyBHcm91cCBvZiB0aGU8YnI+Jmd0OyBJRVRGLjxicj4mZ3Q7ICZn dDs8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyBUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IDogV2l0aC1kZWZhdWx0cyBjYXBhYmlsaXR5IGZvciBORVRDT05GPGJyPiZn dDsgJmd0OyBBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBBLiBCaWVybWFuLCBCLiBM ZW5neWVsPGJyPiZndDsgJmd0OyBGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IGRyYWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dDxicj4mZ3Q7ICZndDsgUGFn ZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDMxPGJyPiZndDsgJmd0OyBE YXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAyMDEwLTA4LTEy PGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgVGhlIE5FVENPTkYgcHJvdG9jb2wgZGVmaW5lcyB3 YXlzIHRvIHJlYWQgYW5kIGVkaXQgY29uZmlndXJhdGlvbiBkYXRhPGJyPiZndDsgJmd0OyBmcm9t IGEgTkVUQ09ORiBzZXJ2ZXIuICZuYnNwO0luIHNvbWUgY2FzZXMsIHBhcnQgb2YgdGhpcyBkYXRh IG1heSBub3QgYmU8YnI+Jmd0OyAmZ3Q7IHNldCBieSB0aGUgTkVUQ09ORiBjbGllbnQsIGJ1dCBy YXRoZXIgYSBkZWZhdWx0IHZhbHVlIGtub3duIHRvIHRoZTxicj4mZ3Q7ICZndDsgc2VydmVyIGlz IHVzZWQgaW5zdGVhZC4gJm5ic3A7SW4gbWFueSBzaXR1YXRpb25zIHRoZSBORVRDT05GIGNsaWVu dCBoYXMgYTxicj4mZ3Q7ICZndDsgcHJpb3JpIGtub3dsZWRnZSBhYm91dCBkZWZhdWx0IGRhdGEs IHNvIHRoZSBORVRDT05GIHNlcnZlciBkb2VzIG5vdDxicj4mZ3Q7ICZndDsgbmVlZCB0byBzYXZl IGl0IGluIGEgTkVUQ09ORiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBvciBzZW5kIGl0IHRvPGJy PiZndDsgJmd0OyB0aGUgY2xpZW50IGluIGEgcmV0cmlldmFsIG9wZXJhdGlvbiByZXBseS4gJm5i c3A7SW4gb3RoZXIgc2l0dWF0aW9ucyB0aGU8YnI+Jmd0OyAmZ3Q7IE5FVENPTkYgY2xpZW50IHdp bGwgbmVlZCB0aGlzIGRhdGEgZnJvbSB0aGUgc2VydmVyLiAmbmJzcDtOb3QgYWxsIHNlcnZlcjxi cj4mZ3Q7ICZndDsgaW1wbGVtZW50YXRpb25zIHRyZWF0IHRoaXMgZGVmYXVsdCBkYXRhIHRoZSBz YW1lIHdheS4gJm5ic3A7VGhpcyBkb2N1bWVudDxicj4mZ3Q7ICZndDsgZGVmaW5lcyBhIGNhcGFi aWxpdHktYmFzZWQgZXh0ZW5zaW9uIHRvIHRoZSBORVRDT05GIHByb3RvY29sIHRoYXQ8YnI+Jmd0 OyAmZ3Q7IGFsbG93cyB0aGUgTkVUQ09ORiBjbGllbnQgdG8gaWRlbnRpZnkgaG93IGRlZmF1bHRz IGFyZSBwcm9jZXNzZWQgYnk8YnI+Jmd0OyAmZ3Q7IHRoZSBzZXJ2ZXIsIGFuZCBhbHNvIGRlZmlu ZXMgbmV3IG1lY2hhbmlzbXMgZm9yIGNsaWVudCBjb250cm9sIG9mPGJyPiZndDsgJmd0OyBzZXJ2 ZXIgcHJvY2Vzc2luZyBvZiBkZWZhdWx0IGRhdGEuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsg QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJyPiZndDsgJmd0OyA8YSBocmVmPSJo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW5ldGNvbmYtd2l0 aC1kZWZhdWx0cy0xMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtbmV0Y29uZi13aXRoLWRlZmF1bHRzLTExLnR4dDwvYT48YnI+Jmd0OyAmZ3Q7PGJy PiZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6PGJyPiZndDsgJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lzxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IEJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwg ZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXI8YnI+Jmd0OyAmZ3Q7IGltcGxlbWVu dGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhl PGJyPiZndDsgJmd0OyBJbnRlcm5ldC1EcmFmdC48YnI+Jmd0OyAmZ3Q7PGJyPiZndDs8YnI+Jmd0 Ozxicj4mZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4tLTxicj4mZ3Q7PGJyPiZndDs8YnI+ Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPiZndDsgJmd0OyBOZXRjb25mIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgTmV0Y29uZkBp ZXRmLm9yZzxicj4mZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmY8L2E+PGJyPiZndDsgJmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7 PGJyPiZndDs8YnI+Jmd0Ozxicj48YnI+PGJyPjxicj48YnI+ ------=_Part_7_1281991778215-- From j.schoenwaelder@jacobs-university.de Mon Aug 16 14:17:24 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72793A67B5 for ; Mon, 16 Aug 2010 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.746 X-Spam-Level: X-Spam-Status: No, score=-101.746 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Rytf5nyFPqQ for ; Mon, 16 Aug 2010 14:17:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id EBBB63A66B4 for ; Mon, 16 Aug 2010 14:17:19 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DB6EC000D; Mon, 16 Aug 2010 23:17:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 0qmWnkA4Bbuo; Mon, 16 Aug 2010 23:17:54 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9B69C0009; Mon, 16 Aug 2010 23:17:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F15D61448909; Mon, 16 Aug 2010 23:17:44 +0200 (CEST) Date: Mon, 16 Aug 2010 23:17:44 +0200 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20100816211742.GA26012@elstar.local> Mail-Followup-To: Kent Watsen , Wes Hardaker , Andy Bierman , "netconf@ietf.org" References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 16 Aug 2010 21:17:25 -0000 On Mon, Aug 16, 2010 at 10:12:01PM +0200, Kent Watsen wrote: > I'm wondering if this is an academic exercise or if there is an > actual problem being solved here. I'm having a hard time believing > that an attacker could stage a successful man in the middle when the > transport is either SSH or SSL/TLS...and, if they were that > sophisticated, surely they would terminate the XML correctly. > > Is this only an issue for when the transport is not encrypted? I agree that a man-in-the-middle scenario or protection of unsecure transports is not a convincing argument. My understanding is that the issue is more related to injection attacks where a client is accepting user input and not properly doing the XML encoding with the effect that a user can somehow inject an end of message marker followed by an XML snipped for a subsequent NETCONF operation. If this happens, the user might do things the client should have prevented and the client has of course failed to do its job properly. There is some empirical evidence that web apps have a tendency to sometimes not properly check user data (e.g. see all the SQL injection attacks). Of course, terminating the session is rather drastic if someone tries to use NETCONF in a manual cut'n'paste mode. And if a nasty user is smart enough to figure out how to make the client still finish a valid message with code injection, then we are in bad shape anyway. These are the arguments I think I have seen and understood. Am I missing something? /js PS: I did not list Wes' argument for pipelined sequences of operations. If a client sends multiple operations and does not care about error checking, the client gets what it asked for. There are many reasons why operations can fail. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From kwatsen@juniper.net Mon Aug 16 16:06:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEBC03A689E for ; Mon, 16 Aug 2010 16:06:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRfwPA2w9gyj for ; Mon, 16 Aug 2010 16:06:56 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id AE9BA3A67A2 for ; Mon, 16 Aug 2010 16:06:56 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTGnEsVnliw0fsJBAxBsWzwNz/r7JXd+N@postini.com; Mon, 16 Aug 2010 16:07:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Mon, 16 Aug 2010 16:06:59 -0700 From: Kent Watsen To: Juergen Schoenwaelder Date: Mon, 16 Aug 2010 16:06:57 -0700 Thread-Topic: [Netconf] how to handle XML parse errors Thread-Index: Acs9iH+wMKNTQxjgQmaqsIobrKTG4wADC7NA Message-ID: <84600D05C20FF943918238042D7670FD36D70882BD@EMBX01-HQ.jnpr.net> References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> In-Reply-To: <20100816211742.GA26012@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 23:06:57 -0000 Copy-n-pasting XML is a likely scenario - I do it all the time! And I many= times mess it up too :) I still think an rpc-error is more appropriate, = perhaps one of these? error-tag: missing-element error-type: protocol, application error-severity: error error-info: : name of the missing element Description: An expected element is missing. error-tag: bad-element error-type: protocol, application error-severity: error error-info: : name of the element w/ bad value Description: An element value is not correct; e.g., wrong type, out of range, pattern mismatch. error-tag: unknown-element error-type: protocol, application error-severity: error error-info: : name of the unexpected element Description: An unexpected element is present. Regarding the concern for users copy-n-pasting multiple pipelined requests,= I think there may be a statement about pipelining requests in general, tha= t they SHOULD NOT depend on each other and that they SHOULD be "safe" and "= idempotent" (as defined by the HTTP spec) Thanks, Kent From wjhns1@hardakers.net Tue Aug 17 07:14:42 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E090E3A687B for ; Tue, 17 Aug 2010 07:14:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-zbQ5gPH1gP for ; Tue, 17 Aug 2010 07:14:40 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A60653A697F for ; Tue, 17 Aug 2010 07:13:16 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id C97CB98087; Tue, 17 Aug 2010 07:13:51 -0700 (PDT) From: Wes Hardaker To: Kent Watsen Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> Date: Tue, 17 Aug 2010 07:13:51 -0700 In-Reply-To: <20100816211742.GA26012@elstar.local> (Juergen Schoenwaelder's message of "Mon, 16 Aug 2010 23:17:44 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:14:43 -0000 >>>>> On Mon, 16 Aug 2010 23:17:44 +0200, Juergen Schoenwaelder said: JS> PS: I did not list Wes' argument for pipelined sequences of JS> operations. If a client sends multiple operations and does not JS> care about error checking, the client gets what it asked for. JS> There are many reasons why operations can fail. There are "huge delayed networks" where round trips are too long to wait. See "Interplanetary Internet" for examples. Though there are real-world on-the-ground-now examples as well (usually in "disrupted environments" like wireless mesh networks). -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Tue Aug 17 07:18:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C68923A67DA for ; Tue, 17 Aug 2010 07:18:18 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6NdiLEHx1Ku for ; Tue, 17 Aug 2010 07:18:18 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D7F8A3A6861 for ; Tue, 17 Aug 2010 07:18:17 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 2312E98087; Tue, 17 Aug 2010 07:18:53 -0700 (PDT) From: Wes Hardaker To: Kent Watsen Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> Date: Tue, 17 Aug 2010 07:18:52 -0700 In-Reply-To: <20100816211742.GA26012@elstar.local> (Juergen Schoenwaelder's message of "Mon, 16 Aug 2010 23:17:44 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:18:18 -0000 >>>>> On Mon, 16 Aug 2010 23:17:44 +0200, Juergen Schoenwaelder said: JS> PS: I did not list Wes' argument for pipelined sequences of JS> operations. If a client sends multiple operations and does not JS> care about error checking, the client gets what it asked for. JS> There are many reasons why operations can fail. You know... I hear this argument all the time, and it's a good one. But you notice we also design all our protocols such that streamlining is allowed. If we want to discourage or say "don't do this" why wouldn't we put a magic cookie in each server's response message that the management station must copy into the next "request" message to prove they at least received the last response. That way they can't be "stupid" like you say above. I suspect you'd argue against this "user protection feature" saying "it doesn't allow for pipelining" :-) -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Tue Aug 17 07:30:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A7B3A68C6 for ; Tue, 17 Aug 2010 07:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.754 X-Spam-Level: X-Spam-Status: No, score=-101.754 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoxfACnkPlJQ for ; Tue, 17 Aug 2010 07:30:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 52B593A688F for ; Tue, 17 Aug 2010 07:30:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43CEAC0010; Tue, 17 Aug 2010 16:30:52 +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 udqTkYa25cZZ; Tue, 17 Aug 2010 16:30:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BDFD9C000F; Tue, 17 Aug 2010 16:30:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6D65D144A892; Tue, 17 Aug 2010 16:30:47 +0200 (CEST) Date: Tue, 17 Aug 2010 16:30:46 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100817143045.GA28554@elstar.local> Mail-Followup-To: Wes Hardaker , Kent Watsen , "netconf@ietf.org" References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2010 14:30:18 -0000 On Tue, Aug 17, 2010 at 04:18:52PM +0200, Wes Hardaker wrote: > >>>>> On Mon, 16 Aug 2010 23:17:44 +0200, Juergen Schoenwaelder said: > > JS> PS: I did not list Wes' argument for pipelined sequences of > JS> operations. If a client sends multiple operations and does not > JS> care about error checking, the client gets what it asked for. > JS> There are many reasons why operations can fail. > > You know... I hear this argument all the time, and it's a good one. > But you notice we also design all our protocols such that streamlining > is allowed. If we want to discourage or say "don't do this" why > wouldn't we put a magic cookie in each server's response message that > the management station must copy into the next "request" message to > prove they at least received the last response. That way they can't be > "stupid" like you say above. I suspect you'd argue against this "user > protection feature" saying "it doesn't allow for pipelining" :-) I wrote "the client gets what it asked for". If a client pipelines a sequence of protocol operations, it needs to be prepared to clean up any mess that might have been created due to a failure somewhere in the pipeline. I did not use words such as "stupid" or "don't do this". I also note that all existing specified NETCONF transports run over TCP. If your goal is to run NETCONF over DTNs where TCP is not an option, there probably needs some additional work to be done anyway. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Tue Aug 17 07:37:47 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 996543A697B for ; Tue, 17 Aug 2010 07:37:47 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGxmEpEkP-pe for ; Tue, 17 Aug 2010 07:37:46 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 1DFE03A688F for ; Tue, 17 Aug 2010 07:37:46 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 627D1980DD; Tue, 17 Aug 2010 07:38:21 -0700 (PDT) From: Wes Hardaker To: Kent Watsen Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> Date: Tue, 17 Aug 2010 07:38:21 -0700 In-Reply-To: <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> (Kent Watsen's message of "Mon, 16 Aug 2010 13:12:01 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 14:37:47 -0000 >>>>> On Mon, 16 Aug 2010 13:12:01 -0700, Kent Watsen said: KW> I'm wondering if this is an academic exercise or if there is an KW> actual problem being solved here. The issues are operational ("pipelining" as Juergen labeled it) and security related. The security related issue is just to protect the agent (where the important data is stored) from badly coded managers. The netconf agent should always be what we're trying to protect against damage, since that's where all the important config is. By mandating that agent's "continue processing whenever possible" seems to me like a bad decision that just leads to errors. SSH (and other protocols) don't provide proper message framing. So the RFC inserts a magic ]]>]]> bullet that can be used to detect the "start of the next message" so that if the current one can't be parsed you just skip to the next. That seems nice until you realize how many operators are going to write scripts out there for use with netconf. I'm *sure* there will be ones written that fail to account for tricky user-input. I'm sure of it because it's happened repeatedly for decades. I don't see the goal in making it easier for them while at the same time making coding the agent harder. If the manager sends a bad management request, why *should* the agent resources be used to try and figure out where in the parsing stream the problem might be. I do agree that having the agent return a "error message" before closing the stream sounds like an excellent idea. But I don't see the benefit in wasting the agent's resources trying to recover from a parser error. Let the management station figure it out. In the SSH case (and now TLS I believe), injection attacks become very very powerful for any management operation that doesn't very carefully check it's input. #!/bin/csh echo "please enter your desired Account Name:" set loginname=$< echo "please enter your Full Name:" set name=$< cat << EOF | netconf-client remotehost.example.com $loginname $name The above works great if the user is nice. I'd even bet that most people *would* check the $loginname field, since that's an obvious place where bad data would matter. But I'd bet that many operators will fail to check the $name field, because why would it matter? A name can contain just about anything. It works less great if the user types in a fullname of ]]>]]> ... newsecret ... Andy's right, it's still possible to "maybe" complete the XML anyway if that input isn't checked. But it takes a lot more work trying to "guess" what the end of the XML looks like when you can't see the stream itself to figure out how the management app is encoding the request over an encrypted stream. On the other-hand, the existence of the ']]>]]>' identifier mean the SSH and TLS streams make it very very easy to inject bad data into a message and immediately start into the next message controlled by the attacker. No guessing required. Closing the session will fix this. Closing the session will make pipelining actually safer to use as well. Win-win. -- Wes Hardaker Cobham Analytic Solutions From ietf@andybierman.com Tue Aug 17 08:20:18 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F6C3A68DE for ; Tue, 17 Aug 2010 08:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BItcHJo6sULP for ; Tue, 17 Aug 2010 08:20:17 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by core3.amsl.com (Postfix) with ESMTP id 22FCE3A6942 for ; Tue, 17 Aug 2010 08:20:16 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7HFKomw026329 for ; Tue, 17 Aug 2010 11:20:51 -0400 Authentication-Results: cm-omr4 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [184.192.101.91] ([184.192.101.91:43426] helo=[184.192.101.91]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 14/D0-10553-0D8AA6C4; Tue, 17 Aug 2010 11:20:50 -0400 To: "=?utf-8?B?V2VzIEhhcmRha2Vy?=" , "=?utf-8?B?S2VudCBXYXRzZW4=?=" Message-ID: <14.D0.10553.0D8AA6C4@cm-omr4> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 17 Aug 2010 08:21:05 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9_1282058465165" Cc: =?utf-8?B?bmV0Y29uZlxAaWV0Zi5vcmc=?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:20:18 -0000 ------=_Part_9_1282058465165 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksCgpJTU8sIHRoZSBsaWtlbGlob29kIG9mIGFuIGluamVjdGlvbiBhdHRhY2sgaXMgbW9yZSBs aWtlbHkgdGhhbiBhIGJ1Z2d5IG1hbmFnZXIsIGFuZCB0aGF0IGlzIG1vcmUgaW1wb3J0YW50LgoK VGhlIHNlcnZlciBtYXkgbm90IGV2ZXIga25vdyB3aGljaCBwYXJ0IG9mIHRoZSBtZXNzYWdlIGNh dXNlZCBhIHBhcnNlIGVycm9yLiAgSW4gdGhlIGxpYnhtbDIgY29kZSBJIHVzZSwgdGhlIEVPRiBl cnJvciB3aWxsIG9jY3VyIGxvb2tpbmcgZm9yIGEgbWlzc2luZyBlbmQgdGFnLiAgVGhlIHNlcnZl ciBjYW5ub3QgcmVwb3J0IHRoZSBleGFjdCBlcnJvci4KCkFuZHkKCi0tLS0tIFJlcGx5IG1lc3Nh Z2UgLS0tLS0KRnJvbTogIldlcyBIYXJkYWtlciIgPHdqaG5zMUBoYXJkYWtlcnMubmV0PgpEYXRl OiBUdWUsIEF1ZyAxNywgMjAxMCAwNzozOApTdWJqZWN0OiBbTmV0Y29uZl0gaG93IHRvIGhhbmRs ZSBYTUwgcGFyc2UgZXJyb3JzClRvOiAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0 PgpDYzogIldlcyBIYXJkYWtlciIgPHdqaG5zMUBoYXJkYWtlcnMubmV0PiwgIkFuZHkgQmllcm1h biIgPGlldGZAYW5keWJpZXJtYW4uY29tPiwgIm5ldGNvbmZcQGlldGYub3JnIiA8bmV0Y29uZkBp ZXRmLm9yZz4KCgo+Pj4+PiBPbiBNb24sIDE2IEF1ZyAyMDEwIDEzOjEyOjAxIC0wNzAwLCBLZW50 IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gc2FpZDoKCktXPiBJJ20gd29uZGVyaW5nIGlm IHRoaXMgaXMgYW4gYWNhZGVtaWMgZXhlcmNpc2Ugb3IgaWYgdGhlcmUgaXMgYW4KS1c+IGFjdHVh bCBwcm9ibGVtIGJlaW5nIHNvbHZlZCBoZXJlLgoKVGhlIGlzc3VlcyBhcmUgb3BlcmF0aW9uYWwg KCJwaXBlbGluaW5nIiBhcyBKdWVyZ2VuIGxhYmVsZWQgaXQpIGFuZApzZWN1cml0eSByZWxhdGVk LgoKVGhlIHNlY3VyaXR5IHJlbGF0ZWQgaXNzdWUgaXMganVzdCB0byBwcm90ZWN0IHRoZSBhZ2Vu dCAod2hlcmUgdGhlCmltcG9ydGFudCBkYXRhIGlzIHN0b3JlZCkgZnJvbSBiYWRseSBjb2RlZCBt YW5hZ2Vycy4KClRoZSBuZXRjb25mIGFnZW50IHNob3VsZCBhbHdheXMgYmUgd2hhdCB3ZSdyZSB0 cnlpbmcgdG8gcHJvdGVjdCBhZ2FpbnN0CmRhbWFnZSwgc2luY2UgdGhhdCdzIHdoZXJlIGFsbCB0 aGUgaW1wb3J0YW50IGNvbmZpZyBpcy4gIEJ5IG1hbmRhdGluZwp0aGF0IGFnZW50J3MgImNvbnRp bnVlIHByb2Nlc3Npbmcgd2hlbmV2ZXIgcG9zc2libGUiIHNlZW1zIHRvIG1lIGxpa2UgYQpiYWQg ZGVjaXNpb24gdGhhdCBqdXN0IGxlYWRzIHRvIGVycm9ycy4KClNTSCAoYW5kIG90aGVyIHByb3Rv Y29scykgZG9uJ3QgcHJvdmlkZSBwcm9wZXIgbWVzc2FnZSBmcmFtaW5nLiAgU28gdGhlClJGQyBp bnNlcnRzIGEgbWFnaWMgXV0+XV0+IGJ1bGxldCB0aGF0IGNhbiBiZSB1c2VkIHRvIGRldGVjdCB0 aGUgInN0YXJ0Cm9mIHRoZSBuZXh0IG1lc3NhZ2UiIHNvIHRoYXQgaWYgdGhlIGN1cnJlbnQgb25l IGNhbid0IGJlIHBhcnNlZCB5b3UganVzdApza2lwIHRvIHRoZSBuZXh0LiAgVGhhdCBzZWVtcyBu aWNlIHVudGlsIHlvdSByZWFsaXplIGhvdyBtYW55IG9wZXJhdG9ycwphcmUgZ29pbmcgdG8gd3Jp dGUgc2NyaXB0cyBvdXQgdGhlcmUgZm9yIHVzZSB3aXRoIG5ldGNvbmYuICBJJ20gKnN1cmUqCnRo ZXJlIHdpbGwgYmUgb25lcyB3cml0dGVuIHRoYXQgZmFpbCB0byBhY2NvdW50IGZvciB0cmlja3kg dXNlci1pbnB1dC4KSSdtIHN1cmUgb2YgaXQgYmVjYXVzZSBpdCdzIGhhcHBlbmVkIHJlcGVhdGVk bHkgZm9yIGRlY2FkZXMuCgpJIGRvbid0IHNlZSB0aGUgZ29hbCBpbiBtYWtpbmcgaXQgZWFzaWVy IGZvciB0aGVtIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUKbWFraW5nIGNvZGluZyB0aGUgYWdlbnQg aGFyZGVyLiAgSWYgdGhlIG1hbmFnZXIgc2VuZHMgYSBiYWQgbWFuYWdlbWVudApyZXF1ZXN0LCB3 aHkgKnNob3VsZCogdGhlIGFnZW50IHJlc291cmNlcyBiZSB1c2VkIHRvIHRyeSBhbmQgZmlndXJl IG91dAp3aGVyZSBpbiB0aGUgcGFyc2luZyBzdHJlYW0gdGhlIHByb2JsZW0gbWlnaHQgYmUuICBJ IGRvIGFncmVlIHRoYXQKaGF2aW5nIHRoZSBhZ2VudCByZXR1cm4gYSAiZXJyb3IgbWVzc2FnZSIg YmVmb3JlIGNsb3NpbmcgdGhlIHN0cmVhbQpzb3VuZHMgbGlrZSBhbiBleGNlbGxlbnQgaWRlYS4g IEJ1dCBJIGRvbid0IHNlZSB0aGUgYmVuZWZpdCBpbiB3YXN0aW5nCnRoZSBhZ2VudCdzIHJlc291 cmNlcyB0cnlpbmcgdG8gcmVjb3ZlciBmcm9tIGEgcGFyc2VyIGVycm9yLiAgTGV0IHRoZQptYW5h Z2VtZW50IHN0YXRpb24gZmlndXJlIGl0IG91dC4KCkluIHRoZSBTU0ggY2FzZSAoYW5kIG5vdyBU TFMgSSBiZWxpZXZlKSwgaW5qZWN0aW9uIGF0dGFja3MgYmVjb21lIHZlcnkKdmVyeSBwb3dlcmZ1 bCBmb3IgYW55IG1hbmFnZW1lbnQgb3BlcmF0aW9uIHRoYXQgZG9lc24ndCB2ZXJ5IGNhcmVmdWxs eQpjaGVjayBpdCdzIGlucHV0LgoKICAjIS9iaW4vY3NoCiAgZWNobyAicGxlYXNlIGVudGVyIHlv dXIgZGVzaXJlZCBBY2NvdW50IE5hbWU6IgogIHNldCBsb2dpbm5hbWU9JDwKCiAgZWNobyAicGxl YXNlIGVudGVyIHlvdXIgRnVsbCBOYW1lOiIKICBzZXQgbmFtZT0kPAoKICBjYXQgPDwgRU9GIHwg bmV0Y29uZi1jbGllbnQgcmVtb3RlaG9zdC5leGFtcGxlLmNvbQogIDxycGMgbWVzc2FnZS1pZD0i MTAxIiB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4KICAg IDxlZGl0LWNvbmZpZz4KICAgICAgPHRhcmdldD4gPHJ1bm5pbmcvPiA8L3RhcmdldD4KICAgICAg PGNvbmZpZz4KICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEu Mi9jb25maWciPgogICAgICAgICAgPHVzZXI+CiAgICAgICAgICAgIDxsb2dpbj4kbG9naW5uYW1l PC9sb2dpbj4KICAgICAgICAgICAgPGZ1bGxuYW1lPiRuYW1lPC9mdWxsbmFtZT4KICAgICAgICAg IDwvdXNlcj4KICAgICAgICA8L3RvcD4KICAgICAgPC9jb25maWc+CiAgICA8L2VkaXQtY29uZmln PgogIDwvcnBjPgoKVGhlIGFib3ZlIHdvcmtzIGdyZWF0IGlmIHRoZSB1c2VyIGlzIG5pY2UuICBJ J2QgZXZlbiBiZXQgdGhhdCBtb3N0CnBlb3BsZSAqd291bGQqIGNoZWNrIHRoZSAkbG9naW5uYW1l IGZpZWxkLCBzaW5jZSB0aGF0J3MgYW4gb2J2aW91cyBwbGFjZQp3aGVyZSBiYWQgZGF0YSB3b3Vs ZCBtYXR0ZXIuICBCdXQgSSdkIGJldCB0aGF0IG1hbnkgb3BlcmF0b3JzIHdpbGwgZmFpbAp0byBj aGVjayB0aGUgJG5hbWUgZmllbGQsIGJlY2F1c2Ugd2h5IHdvdWxkIGl0IG1hdHRlcj8gIEEgbmFt ZSBjYW4KY29udGFpbiBqdXN0IGFib3V0IGFueXRoaW5nLiAgSXQgd29ya3MgbGVzcyBncmVhdCBp ZiB0aGUgdXNlciB0eXBlcyBpbiBhCmZ1bGxuYW1lIG9mCgogIF1dPl1dPgogIDxycGMgLi4uPjxl ZGl0LWNvbmZpZz4uLi4KICA8Y2hhbmdlLXBhc3N3b3JkIGxvZ2luPSJyb290Ij5uZXdzZWNyZXQ8 L2NoYW5nZS1wYXNzd29yZD4KICAuLi4KCkFuZHkncyByaWdodCwgaXQncyBzdGlsbCBwb3NzaWJs ZSB0byAibWF5YmUiIGNvbXBsZXRlIHRoZSBYTUwgYW55d2F5IGlmCnRoYXQgaW5wdXQgaXNuJ3Qg Y2hlY2tlZC4gIEJ1dCBpdCB0YWtlcyBhIGxvdCBtb3JlIHdvcmsgdHJ5aW5nIHRvCiJndWVzcyIg d2hhdCB0aGUgZW5kIG9mIHRoZSBYTUwgbG9va3MgbGlrZSB3aGVuIHlvdSBjYW4ndCBzZWUgdGhl IHN0cmVhbQppdHNlbGYgdG8gZmlndXJlIG91dCBob3cgdGhlIG1hbmFnZW1lbnQgYXBwIGlzIGVu Y29kaW5nIHRoZSByZXF1ZXN0IG92ZXIKYW4gZW5jcnlwdGVkIHN0cmVhbS4gIE9uIHRoZSBvdGhl ci1oYW5kLCB0aGUgZXhpc3RlbmNlIG9mIHRoZSAnXV0+XV0+JwppZGVudGlmaWVyIG1lYW4gdGhl IFNTSCBhbmQgVExTIHN0cmVhbXMgbWFrZSBpdCB2ZXJ5IHZlcnkgZWFzeSB0byBpbmplY3QKYmFk IGRhdGEgaW50byBhIG1lc3NhZ2UgYW5kIGltbWVkaWF0ZWx5IHN0YXJ0IGludG8gdGhlIG5leHQg bWVzc2FnZQpjb250cm9sbGVkIGJ5IHRoZSBhdHRhY2tlci4gIE5vIGd1ZXNzaW5nIHJlcXVpcmVk LgoKQ2xvc2luZyB0aGUgc2Vzc2lvbiB3aWxsIGZpeCB0aGlzLgpDbG9zaW5nIHRoZSBzZXNzaW9u IHdpbGwgbWFrZSBwaXBlbGluaW5nIGFjdHVhbGx5IHNhZmVyIHRvIHVzZSBhcyB3ZWxsLgoKV2lu LXdpbi4KLS0gCldlcyBIYXJkYWtlcgpDb2JoYW0gQW5hbHl0aWMgU29sdXRpb25zCgo= ------=_Part_9_1282058465165 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGksPGJyPjxicj5JTU8sIHRoZSBsaWtlbGlob29kIG9mIGFuIGluamVjdGlvbiBhdHRhY2sgaXMg bW9yZSBsaWtlbHkgdGhhbiBhIGJ1Z2d5IG1hbmFnZXIsIGFuZCB0aGF0IGlzIG1vcmUgaW1wb3J0 YW50Ljxicj48YnI+VGhlIHNlcnZlciBtYXkgbm90IGV2ZXIga25vdyB3aGljaCBwYXJ0IG9mIHRo ZSBtZXNzYWdlIGNhdXNlZCBhIHBhcnNlIGVycm9yLiAmbmJzcDtJbiB0aGUgbGlieG1sMiBjb2Rl IEkgdXNlLCB0aGUgRU9GIGVycm9yIHdpbGwgb2NjdXIgbG9va2luZyBmb3IgYSBtaXNzaW5nIGVu ZCB0YWcuICZuYnNwO1RoZSBzZXJ2ZXIgY2Fubm90IHJlcG9ydCB0aGUgZXhhY3QgZXJyb3IuPGJy Pjxicj5BbmR5PGJyPjxicj4tLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tPGJyPkZyb206ICZxdW90 O1dlcyBIYXJkYWtlciZxdW90OyAmbHQ7d2pobnMxQGhhcmRha2Vycy5uZXQmZ3Q7PGJyPkRhdGU6 IFR1ZSwgQXVnIDE3LCAyMDEwIDA3OjM4PGJyPlN1YmplY3Q6IFtOZXRjb25mXSBob3cgdG8gaGFu ZGxlIFhNTCBwYXJzZSBlcnJvcnM8YnI+VG86ICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDtr d2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj5DYzogJnF1b3Q7V2VzIEhhcmRha2VyJnF1b3Q7ICZs dDt3amhuczFAaGFyZGFrZXJzLm5ldCZndDssICZxdW90O0FuZHkgQmllcm1hbiZxdW90OyAmbHQ7 aWV0ZkBhbmR5Ymllcm1hbi5jb20mZ3Q7LCAmcXVvdDtuZXRjb25mXEBpZXRmLm9yZyZxdW90OyAm bHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+PGJyPjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBP biBNb24sIDE2IEF1ZyAyMDEwIDEzOjEyOjAxIC0wNzAwLCBLZW50IFdhdHNlbiAmbHQ7a3dhdHNl bkBqdW5pcGVyLm5ldCZndDsgc2FpZDo8YnI+PGJyPktXJmd0OyBJJiMzOTttIHdvbmRlcmluZyBp ZiB0aGlzIGlzIGFuIGFjYWRlbWljIGV4ZXJjaXNlIG9yIGlmIHRoZXJlIGlzIGFuPGJyPktXJmd0 OyBhY3R1YWwgcHJvYmxlbSBiZWluZyBzb2x2ZWQgaGVyZS48YnI+PGJyPlRoZSBpc3N1ZXMgYXJl IG9wZXJhdGlvbmFsICgmcXVvdDtwaXBlbGluaW5nJnF1b3Q7IGFzIEp1ZXJnZW4gbGFiZWxlZCBp dCkgYW5kPGJyPnNlY3VyaXR5IHJlbGF0ZWQuPGJyPjxicj5UaGUgc2VjdXJpdHkgcmVsYXRlZCBp c3N1ZSBpcyBqdXN0IHRvIHByb3RlY3QgdGhlIGFnZW50ICh3aGVyZSB0aGU8YnI+aW1wb3J0YW50 IGRhdGEgaXMgc3RvcmVkKSBmcm9tIGJhZGx5IGNvZGVkIG1hbmFnZXJzLjxicj48YnI+VGhlIG5l dGNvbmYgYWdlbnQgc2hvdWxkIGFsd2F5cyBiZSB3aGF0IHdlJiMzOTtyZSB0cnlpbmcgdG8gcHJv dGVjdCBhZ2FpbnN0PGJyPmRhbWFnZSwgc2luY2UgdGhhdCYjMzk7cyB3aGVyZSBhbGwgdGhlIGlt cG9ydGFudCBjb25maWcgaXMuICZuYnNwO0J5IG1hbmRhdGluZzxicj50aGF0IGFnZW50JiMzOTtz ICZxdW90O2NvbnRpbnVlIHByb2Nlc3Npbmcgd2hlbmV2ZXIgcG9zc2libGUmcXVvdDsgc2VlbXMg dG8gbWUgbGlrZSBhPGJyPmJhZCBkZWNpc2lvbiB0aGF0IGp1c3QgbGVhZHMgdG8gZXJyb3JzLjxi cj48YnI+U1NIIChhbmQgb3RoZXIgcHJvdG9jb2xzKSBkb24mIzM5O3QgcHJvdmlkZSBwcm9wZXIg bWVzc2FnZSBmcmFtaW5nLiAmbmJzcDtTbyB0aGU8YnI+UkZDIGluc2VydHMgYSBtYWdpYyBdXSZn dDtdXSZndDsgYnVsbGV0IHRoYXQgY2FuIGJlIHVzZWQgdG8gZGV0ZWN0IHRoZSAmcXVvdDtzdGFy dDxicj5vZiB0aGUgbmV4dCBtZXNzYWdlJnF1b3Q7IHNvIHRoYXQgaWYgdGhlIGN1cnJlbnQgb25l IGNhbiYjMzk7dCBiZSBwYXJzZWQgeW91IGp1c3Q8YnI+c2tpcCB0byB0aGUgbmV4dC4gJm5ic3A7 VGhhdCBzZWVtcyBuaWNlIHVudGlsIHlvdSByZWFsaXplIGhvdyBtYW55IG9wZXJhdG9yczxicj5h cmUgZ29pbmcgdG8gd3JpdGUgc2NyaXB0cyBvdXQgdGhlcmUgZm9yIHVzZSB3aXRoIG5ldGNvbmYu ICZuYnNwO0kmIzM5O20gKnN1cmUqPGJyPnRoZXJlIHdpbGwgYmUgb25lcyB3cml0dGVuIHRoYXQg ZmFpbCB0byBhY2NvdW50IGZvciB0cmlja3kgdXNlci1pbnB1dC48YnI+SSYjMzk7bSBzdXJlIG9m IGl0IGJlY2F1c2UgaXQmIzM5O3MgaGFwcGVuZWQgcmVwZWF0ZWRseSBmb3IgZGVjYWRlcy48YnI+ PGJyPkkgZG9uJiMzOTt0IHNlZSB0aGUgZ29hbCBpbiBtYWtpbmcgaXQgZWFzaWVyIGZvciB0aGVt IHdoaWxlIGF0IHRoZSBzYW1lIHRpbWU8YnI+bWFraW5nIGNvZGluZyB0aGUgYWdlbnQgaGFyZGVy LiAmbmJzcDtJZiB0aGUgbWFuYWdlciBzZW5kcyBhIGJhZCBtYW5hZ2VtZW50PGJyPnJlcXVlc3Qs IHdoeSAqc2hvdWxkKiB0aGUgYWdlbnQgcmVzb3VyY2VzIGJlIHVzZWQgdG8gdHJ5IGFuZCBmaWd1 cmUgb3V0PGJyPndoZXJlIGluIHRoZSBwYXJzaW5nIHN0cmVhbSB0aGUgcHJvYmxlbSBtaWdodCBi ZS4gJm5ic3A7SSBkbyBhZ3JlZSB0aGF0PGJyPmhhdmluZyB0aGUgYWdlbnQgcmV0dXJuIGEgJnF1 b3Q7ZXJyb3IgbWVzc2FnZSZxdW90OyBiZWZvcmUgY2xvc2luZyB0aGUgc3RyZWFtPGJyPnNvdW5k cyBsaWtlIGFuIGV4Y2VsbGVudCBpZGVhLiAmbmJzcDtCdXQgSSBkb24mIzM5O3Qgc2VlIHRoZSBi ZW5lZml0IGluIHdhc3Rpbmc8YnI+dGhlIGFnZW50JiMzOTtzIHJlc291cmNlcyB0cnlpbmcgdG8g cmVjb3ZlciBmcm9tIGEgcGFyc2VyIGVycm9yLiAmbmJzcDtMZXQgdGhlPGJyPm1hbmFnZW1lbnQg c3RhdGlvbiBmaWd1cmUgaXQgb3V0Ljxicj48YnI+SW4gdGhlIFNTSCBjYXNlIChhbmQgbm93IFRM UyBJIGJlbGlldmUpLCBpbmplY3Rpb24gYXR0YWNrcyBiZWNvbWUgdmVyeTxicj52ZXJ5IHBvd2Vy ZnVsIGZvciBhbnkgbWFuYWdlbWVudCBvcGVyYXRpb24gdGhhdCBkb2VzbiYjMzk7dCB2ZXJ5IGNh cmVmdWxseTxicj5jaGVjayBpdCYjMzk7cyBpbnB1dC48YnI+PGJyPiAmbmJzcDsjIS9iaW4vY3No PGJyPiAmbmJzcDtlY2hvICZxdW90O3BsZWFzZSBlbnRlciB5b3VyIGRlc2lyZWQgQWNjb3VudCBO YW1lOiZxdW90Ozxicj4gJm5ic3A7c2V0IGxvZ2lubmFtZT0kJmx0Ozxicj48YnI+ICZuYnNwO2Vj aG8gJnF1b3Q7cGxlYXNlIGVudGVyIHlvdXIgRnVsbCBOYW1lOiZxdW90Ozxicj4gJm5ic3A7c2V0 IG5hbWU9JCZsdDs8YnI+PGJyPiAmbmJzcDtjYXQgJmx0OyZsdDsgRU9GIHwgbmV0Y29uZi1jbGll bnQgcmVtb3RlaG9zdC5leGFtcGxlLmNvbTxicj4gJm5ic3A7Jmx0O3JwYyBtZXNzYWdlLWlkPSZx dW90OzEwMSZxdW90OyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAmcXVvdDsmZ3Q7PGJyPiAmbmJzcDsgJm5ic3A7Jmx0O2VkaXQtY29uZmlnJmd0Ozxi cj4gJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7dGFyZ2V0Jmd0OyAmbHQ7cnVubmluZy8mZ3Q7ICZs dDsvdGFyZ2V0Jmd0Ozxicj4gJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7Y29uZmlnJmd0Ozxicj4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3RvcCB4bWxucz0mcXVvdDs8YSBocmVmPSJo dHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWciPmh0dHA6Ly9leGFtcGxlLmNvbS9z Y2hlbWEvMS4yL2NvbmZpZzwvYT4mcXVvdDsmZ3Q7PGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmx0O3VzZXImZ3Q7PGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDtsb2dpbiZndDskbG9naW5uYW1lJmx0Oy9sb2dpbiZndDs8YnI+ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2Z1bGxuYW1lJmd0OyRu YW1lJmx0Oy9mdWxsbmFtZSZndDs8YnI+ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbHQ7L3VzZXImZ3Q7PGJyPiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L3RvcCZn dDs8YnI+ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9jb25maWcmZ3Q7PGJyPiAmbmJzcDsgJm5i c3A7Jmx0Oy9lZGl0LWNvbmZpZyZndDs8YnI+ICZuYnNwOyZsdDsvcnBjJmd0Ozxicj48YnI+VGhl IGFib3ZlIHdvcmtzIGdyZWF0IGlmIHRoZSB1c2VyIGlzIG5pY2UuICZuYnNwO0kmIzM5O2QgZXZl biBiZXQgdGhhdCBtb3N0PGJyPnBlb3BsZSAqd291bGQqIGNoZWNrIHRoZSAkbG9naW5uYW1lIGZp ZWxkLCBzaW5jZSB0aGF0JiMzOTtzIGFuIG9idmlvdXMgcGxhY2U8YnI+d2hlcmUgYmFkIGRhdGEg d291bGQgbWF0dGVyLiAmbmJzcDtCdXQgSSYjMzk7ZCBiZXQgdGhhdCBtYW55IG9wZXJhdG9ycyB3 aWxsIGZhaWw8YnI+dG8gY2hlY2sgdGhlICRuYW1lIGZpZWxkLCBiZWNhdXNlIHdoeSB3b3VsZCBp dCBtYXR0ZXI/ICZuYnNwO0EgbmFtZSBjYW48YnI+Y29udGFpbiBqdXN0IGFib3V0IGFueXRoaW5n LiAmbmJzcDtJdCB3b3JrcyBsZXNzIGdyZWF0IGlmIHRoZSB1c2VyIHR5cGVzIGluIGE8YnI+ZnVs bG5hbWUgb2Y8YnI+PGJyPiAmbmJzcDtdXSZndDtdXSZndDs8YnI+ICZuYnNwOyZsdDtycGMgLi4u Jmd0OyZsdDtlZGl0LWNvbmZpZyZndDsuLi48YnI+ICZuYnNwOyZsdDtjaGFuZ2UtcGFzc3dvcmQg bG9naW49JnF1b3Q7cm9vdCZxdW90OyZndDtuZXdzZWNyZXQmbHQ7L2NoYW5nZS1wYXNzd29yZCZn dDs8YnI+ICZuYnNwOy4uLjxicj48YnI+QW5keSYjMzk7cyByaWdodCwgaXQmIzM5O3Mgc3RpbGwg cG9zc2libGUgdG8gJnF1b3Q7bWF5YmUmcXVvdDsgY29tcGxldGUgdGhlIFhNTCBhbnl3YXkgaWY8 YnI+dGhhdCBpbnB1dCBpc24mIzM5O3QgY2hlY2tlZC4gJm5ic3A7QnV0IGl0IHRha2VzIGEgbG90 IG1vcmUgd29yayB0cnlpbmcgdG88YnI+JnF1b3Q7Z3Vlc3MmcXVvdDsgd2hhdCB0aGUgZW5kIG9m IHRoZSBYTUwgbG9va3MgbGlrZSB3aGVuIHlvdSBjYW4mIzM5O3Qgc2VlIHRoZSBzdHJlYW08YnI+ aXRzZWxmIHRvIGZpZ3VyZSBvdXQgaG93IHRoZSBtYW5hZ2VtZW50IGFwcCBpcyBlbmNvZGluZyB0 aGUgcmVxdWVzdCBvdmVyPGJyPmFuIGVuY3J5cHRlZCBzdHJlYW0uICZuYnNwO09uIHRoZSBvdGhl ci1oYW5kLCB0aGUgZXhpc3RlbmNlIG9mIHRoZSAmIzM5O11dJmd0O11dJmd0OyYjMzk7PGJyPmlk ZW50aWZpZXIgbWVhbiB0aGUgU1NIIGFuZCBUTFMgc3RyZWFtcyBtYWtlIGl0IHZlcnkgdmVyeSBl YXN5IHRvIGluamVjdDxicj5iYWQgZGF0YSBpbnRvIGEgbWVzc2FnZSBhbmQgaW1tZWRpYXRlbHkg c3RhcnQgaW50byB0aGUgbmV4dCBtZXNzYWdlPGJyPmNvbnRyb2xsZWQgYnkgdGhlIGF0dGFja2Vy LiAmbmJzcDtObyBndWVzc2luZyByZXF1aXJlZC48YnI+PGJyPkNsb3NpbmcgdGhlIHNlc3Npb24g d2lsbCBmaXggdGhpcy48YnI+Q2xvc2luZyB0aGUgc2Vzc2lvbiB3aWxsIG1ha2UgcGlwZWxpbmlu ZyBhY3R1YWxseSBzYWZlciB0byB1c2UgYXMgd2VsbC48YnI+PGJyPldpbi13aW4uPGJyPi0tIDxi cj5XZXMgSGFyZGFrZXI8YnI+Q29iaGFtIEFuYWx5dGljIFNvbHV0aW9uczxicj48YnI+PGJyPjxi cj4= ------=_Part_9_1282058465165-- From lhotka@cesnet.cz Tue Aug 17 08:40:43 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEC073A69F2 for ; Tue, 17 Aug 2010 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.383 X-Spam-Level: X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaGjoYXzUGBy for ; Tue, 17 Aug 2010 08:40:43 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id D5D6B3A6862 for ; Tue, 17 Aug 2010 08:40:42 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 73F703E05EB; Tue, 17 Aug 2010 17:41:00 +0200 (CEST) From: Ladislav Lhotka To: Wes Hardaker , Kent Watsen In-Reply-To: References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Tue, 17 Aug 2010 17:41:13 +0200 Message-ID: <8762z9z1pi.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 15:40:43 -0000 On Tue, 17 Aug 2010 07:38:21 -0700, Wes Hardaker wrote: > #!/bin/csh > echo "please enter your desired Account Name:" > set loginname=$< > > echo "please enter your Full Name:" > set name=$< > > cat << EOF | netconf-client remotehost.example.com > > > > > > > $loginname > $name > > > > > > > The above works great if the user is nice. I'd even bet that most > people *would* check the $loginname field, since that's an obvious place > where bad data would matter. But I'd bet that many operators will fail > to check the $name field, because why would it matter? A name can > contain just about anything. It works less great if the user types in a > fullname of > > ]]>]]> > ... > newsecret > ... > Even if the session is terminated on non-well-formed input, it's only little extra work for the bad guy to make it well-formed: Black Hat...]]>]]> ... newsecret So terminating the session doesn't really close this security hole. Lada -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Tue Aug 17 13:11:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4981D3A6946 for ; Tue, 17 Aug 2010 13:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B39m+a8BKRIs for ; Tue, 17 Aug 2010 13:11:34 -0700 (PDT) Received: from omr1.networksolutionsemail.com (omr1.networksolutionsemail.com [205.178.146.51]) by core3.amsl.com (Postfix) with ESMTP id B7B703A6875 for ; Tue, 17 Aug 2010 13:11:33 -0700 (PDT) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7HKC6k0007384 for ; Tue, 17 Aug 2010 16:12:08 -0400 Authentication-Results: cm-omr4 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [184.192.101.91] ([184.192.101.91:36749] helo=[184.192.101.91]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E8/D1-10553-41DEA6C4; Tue, 17 Aug 2010 16:12:06 -0400 To: "=?utf-8?B?TGFkaXNsYXYgTGhvdGth?=" , "=?utf-8?B?V2VzIEhhcmRha2Vy?=" , "=?utf-8?B?S2VudCBXYXRzZW4=?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 17 Aug 2010 13:12:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10_1282075939570" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:11:37 -0000 ------=_Part_10_1282075939570 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SWYgdGhlIGhhY2tlciBjYW4gc2VlIHRoZSBYTUwgdGhlbiBjbG9zaW5nIG9mZiB0aGUgZW5kIHRh Z3MgY29ycmVjdGx5IHdpbGwgYmUgdHJpdmlhbC4gIElmIG5vdCwgYmVjYXVzZSB0aGUgY2hhbm5l bCBpcyBlbmNyeXB0ZWQsIHRoZW4gaXQgd2lsbCBub3QgYmUgc28gZWFzeS4KCkFuZHkKCi0tLS0t IFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIkxhZGlzbGF2IExob3RrYSIgPGxob3RrYUBjZXNu ZXQuY3o+CkRhdGU6IFR1ZSwgQXVnIDE3LCAyMDEwIDA4OjQxClN1YmplY3Q6IFtOZXRjb25mXSBo b3cgdG8gaGFuZGxlIFhNTCBwYXJzZSBlcnJvcnMKVG86ICJXZXMgSGFyZGFrZXIiIDx3amhuczFA aGFyZGFrZXJzLm5ldD4sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+CkNjOiAi bmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+CgoKT24gVHVlLCAxNyBBdWcgMjAx MCAwNzozODoyMSAtMDcwMCwgV2VzIEhhcmRha2VyIDx3amhuczFAaGFyZGFrZXJzLm5ldD4gd3Jv dGU6Cj4gICAjIS9iaW4vY3NoCj4gICBlY2hvICJwbGVhc2UgZW50ZXIgeW91ciBkZXNpcmVkIEFj Y291bnQgTmFtZToiCj4gICBzZXQgbG9naW5uYW1lPSQ8Cj4gCj4gICBlY2hvICJwbGVhc2UgZW50 ZXIgeW91ciBGdWxsIE5hbWU6Igo+ICAgc2V0IG5hbWU9JDwKPiAKPiAgIGNhdCA8PCBFT0YgfCBu ZXRjb25mLWNsaWVudCByZW1vdGVob3N0LmV4YW1wbGUuY29tCj4gICA8cnBjIG1lc3NhZ2UtaWQ9 IjEwMSIgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+Cj4g ICAgIDxlZGl0LWNvbmZpZz4KPiAgICAgICA8dGFyZ2V0PiA8cnVubmluZy8+IDwvdGFyZ2V0Pgo+ ICAgICAgIDxjb25maWc+Cj4gICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20v c2NoZW1hLzEuMi9jb25maWciPgo+ICAgICAgICAgICA8dXNlcj4KPiAgICAgICAgICAgICA8bG9n aW4+JGxvZ2lubmFtZTwvbG9naW4+Cj4gICAgICAgICAgICAgPGZ1bGxuYW1lPiRuYW1lPC9mdWxs bmFtZT4KPiAgICAgICAgICAgPC91c2VyPgo+ICAgICAgICAgPC90b3A+Cj4gICAgICAgPC9jb25m aWc+Cj4gICAgIDwvZWRpdC1jb25maWc+Cj4gICA8L3JwYz4KPiAKPiBUaGUgYWJvdmUgd29ya3Mg Z3JlYXQgaWYgdGhlIHVzZXIgaXMgbmljZS4gIEknZCBldmVuIGJldCB0aGF0IG1vc3QKPiBwZW9w bGUgKndvdWxkKiBjaGVjayB0aGUgJGxvZ2lubmFtZSBmaWVsZCwgc2luY2UgdGhhdCdzIGFuIG9i dmlvdXMgcGxhY2UKPiB3aGVyZSBiYWQgZGF0YSB3b3VsZCBtYXR0ZXIuICBCdXQgSSdkIGJldCB0 aGF0IG1hbnkgb3BlcmF0b3JzIHdpbGwgZmFpbAo+IHRvIGNoZWNrIHRoZSAkbmFtZSBmaWVsZCwg YmVjYXVzZSB3aHkgd291bGQgaXQgbWF0dGVyPyAgQSBuYW1lIGNhbgo+IGNvbnRhaW4ganVzdCBh Ym91dCBhbnl0aGluZy4gIEl0IHdvcmtzIGxlc3MgZ3JlYXQgaWYgdGhlIHVzZXIgdHlwZXMgaW4g YQo+IGZ1bGxuYW1lIG9mCj4gCj4gICBdXT5dXT4KPiAgIDxycGMgLi4uPjxlZGl0LWNvbmZpZz4u Li4KPiAgIDxjaGFuZ2UtcGFzc3dvcmQgbG9naW49InJvb3QiPm5ld3NlY3JldDwvY2hhbmdlLXBh c3N3b3JkPgo+ICAgLi4uCj4gCgpFdmVuIGlmIHRoZSBzZXNzaW9uIGlzIHRlcm1pbmF0ZWQgb24g bm9uLXdlbGwtZm9ybWVkIGlucHV0LCBpdCdzIG9ubHkKbGl0dGxlIGV4dHJhIHdvcmsgZm9yIHRo ZSBiYWQgZ3V5IHRvIG1ha2UgaXQgd2VsbC1mb3JtZWQ6CgogIEJsYWNrIEhhdDwvZnVsbG5hbWU+ Li4uPC9ycGM+XV0+XV0+CiAgPHJwYyAuLi4+PGVkaXQtY29uZmlnPi4uLgogIDxjaGFuZ2UtcGFz c3dvcmQgbG9naW49InJvb3QiPm5ld3NlY3JldDwvY2hhbmdlLXBhc3N3b3JkPgoKU28gdGVybWlu YXRpbmcgdGhlIHNlc3Npb24gZG9lc24ndCByZWFsbHkgY2xvc2UgdGhpcyBzZWN1cml0eSBob2xl LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBD Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5ldGNvbmYg bWFpbGluZyBsaXN0Ck5ldGNvbmZAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRjb25mCgo= ------=_Part_10_1282075939570 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SWYgdGhlIGhhY2tlciBjYW4gc2VlIHRoZSBYTUwgdGhlbiBjbG9zaW5nIG9mZiB0aGUgZW5kIHRh Z3MgY29ycmVjdGx5IHdpbGwgYmUgdHJpdmlhbC4gJm5ic3A7SWYgbm90LCBiZWNhdXNlIHRoZSBj aGFubmVsIGlzIGVuY3J5cHRlZCwgdGhlbiBpdCB3aWxsIG5vdCBiZSBzbyBlYXN5Ljxicj48YnI+ QW5keTxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtMYWRp c2xhdiBMaG90a2EmcXVvdDsgJmx0O2xob3RrYUBjZXNuZXQuY3omZ3Q7PGJyPkRhdGU6IFR1ZSwg QXVnIDE3LCAyMDEwIDA4OjQxPGJyPlN1YmplY3Q6IFtOZXRjb25mXSBob3cgdG8gaGFuZGxlIFhN TCBwYXJzZSBlcnJvcnM8YnI+VG86ICZxdW90O1dlcyBIYXJkYWtlciZxdW90OyAmbHQ7d2pobnMx QGhhcmRha2Vycy5uZXQmZ3Q7LCAmcXVvdDtLZW50IFdhdHNlbiZxdW90OyAmbHQ7a3dhdHNlbkBq dW5pcGVyLm5ldCZndDs8YnI+Q2M6ICZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25l dGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+T24gVHVlLCAxNyBBdWcgMjAxMCAwNzozODoy MSAtMDcwMCwgV2VzIEhhcmRha2VyICZsdDt3amhuczFAaGFyZGFrZXJzLm5ldCZndDsgd3JvdGU6 PGJyPiZndDsgJm5ic3A7ICMhL2Jpbi9jc2g8YnI+Jmd0OyAmbmJzcDsgZWNobyAmcXVvdDtwbGVh c2UgZW50ZXIgeW91ciBkZXNpcmVkIEFjY291bnQgTmFtZTomcXVvdDs8YnI+Jmd0OyAmbmJzcDsg c2V0IGxvZ2lubmFtZT0kJmx0Ozxicj4mZ3Q7IDxicj4mZ3Q7ICZuYnNwOyBlY2hvICZxdW90O3Bs ZWFzZSBlbnRlciB5b3VyIEZ1bGwgTmFtZTomcXVvdDs8YnI+Jmd0OyAmbmJzcDsgc2V0IG5hbWU9 JCZsdDs8YnI+Jmd0OyA8YnI+Jmd0OyAmbmJzcDsgY2F0ICZsdDsmbHQ7IEVPRiB8IG5ldGNvbmYt Y2xpZW50IHJlbW90ZWhvc3QuZXhhbXBsZS5jb208YnI+Jmd0OyAmbmJzcDsgJmx0O3JwYyBtZXNz YWdlLWlkPSZxdW90OzEwMSZxdW90OyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZWRp dC1jb25maWcmZ3Q7PGJyPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O3RhcmdldCZndDsg Jmx0O3J1bm5pbmcvJmd0OyAmbHQ7L3RhcmdldCZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7Y29uZmlnJmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7dG9wIHhtbG5zPSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4y L2NvbmZpZyI+aHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnPC9hPiZxdW90OyZn dDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDt1c2VyJmd0 Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDts b2dpbiZndDskbG9naW5uYW1lJmx0Oy9sb2dpbiZndDs8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZnVsbG5hbWUmZ3Q7JG5hbWUmbHQ7L2Z1bGxu YW1lJmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy91 c2VyJmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L3RvcCZndDs8 YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7L2NvbmZpZyZndDs8YnI+Jmd0OyAmbmJz cDsgJm5ic3A7ICZsdDsvZWRpdC1jb25maWcmZ3Q7PGJyPiZndDsgJm5ic3A7ICZsdDsvcnBjJmd0 Ozxicj4mZ3Q7IDxicj4mZ3Q7IFRoZSBhYm92ZSB3b3JrcyBncmVhdCBpZiB0aGUgdXNlciBpcyBu aWNlLiAmbmJzcDtJJiMzOTtkIGV2ZW4gYmV0IHRoYXQgbW9zdDxicj4mZ3Q7IHBlb3BsZSAqd291 bGQqIGNoZWNrIHRoZSAkbG9naW5uYW1lIGZpZWxkLCBzaW5jZSB0aGF0JiMzOTtzIGFuIG9idmlv dXMgcGxhY2U8YnI+Jmd0OyB3aGVyZSBiYWQgZGF0YSB3b3VsZCBtYXR0ZXIuICZuYnNwO0J1dCBJ JiMzOTtkIGJldCB0aGF0IG1hbnkgb3BlcmF0b3JzIHdpbGwgZmFpbDxicj4mZ3Q7IHRvIGNoZWNr IHRoZSAkbmFtZSBmaWVsZCwgYmVjYXVzZSB3aHkgd291bGQgaXQgbWF0dGVyPyAmbmJzcDtBIG5h bWUgY2FuPGJyPiZndDsgY29udGFpbiBqdXN0IGFib3V0IGFueXRoaW5nLiAmbmJzcDtJdCB3b3Jr cyBsZXNzIGdyZWF0IGlmIHRoZSB1c2VyIHR5cGVzIGluIGE8YnI+Jmd0OyBmdWxsbmFtZSBvZjxi cj4mZ3Q7IDxicj4mZ3Q7ICZuYnNwOyBdXSZndDtdXSZndDs8YnI+Jmd0OyAmbmJzcDsgJmx0O3Jw YyAuLi4mZ3Q7Jmx0O2VkaXQtY29uZmlnJmd0Oy4uLjxicj4mZ3Q7ICZuYnNwOyAmbHQ7Y2hhbmdl LXBhc3N3b3JkIGxvZ2luPSZxdW90O3Jvb3QmcXVvdDsmZ3Q7bmV3c2VjcmV0Jmx0Oy9jaGFuZ2Ut cGFzc3dvcmQmZ3Q7PGJyPiZndDsgJm5ic3A7IC4uLjxicj4mZ3Q7IDxicj48YnI+RXZlbiBpZiB0 aGUgc2Vzc2lvbiBpcyB0ZXJtaW5hdGVkIG9uIG5vbi13ZWxsLWZvcm1lZCBpbnB1dCwgaXQmIzM5 O3Mgb25seTxicj5saXR0bGUgZXh0cmEgd29yayBmb3IgdGhlIGJhZCBndXkgdG8gbWFrZSBpdCB3 ZWxsLWZvcm1lZDo8YnI+PGJyPiAmbmJzcDtCbGFjayBIYXQmbHQ7L2Z1bGxuYW1lJmd0Oy4uLiZs dDsvcnBjJmd0O11dJmd0O11dJmd0Ozxicj4gJm5ic3A7Jmx0O3JwYyAuLi4mZ3Q7Jmx0O2VkaXQt Y29uZmlnJmd0Oy4uLjxicj4gJm5ic3A7Jmx0O2NoYW5nZS1wYXNzd29yZCBsb2dpbj0mcXVvdDty b290JnF1b3Q7Jmd0O25ld3NlY3JldCZsdDsvY2hhbmdlLXBhc3N3b3JkJmd0Ozxicj48YnI+U28g dGVybWluYXRpbmcgdGhlIHNlc3Npb24gZG9lc24mIzM5O3QgcmVhbGx5IGNsb3NlIHRoaXMgc2Vj dXJpdHkgaG9sZS48YnI+PGJyPkxhZGE8YnI+PGJyPi0tIDxicj5MYWRpc2xhdiBMaG90a2EsIENF U05FVDxicj5QR1AgS2V5IElEOiBFNzRFOEMwQzxicj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj5OZXRjb25mIG1haWxpbmcgbGlzdDxicj5OZXRjb25m QGlldGYub3JnPGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25m PC9hPjxicj48YnI+PGJyPjxicj4= ------=_Part_10_1282075939570-- From randy_presuhn@mindspring.com Tue Aug 17 13:17:55 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77FEA3A69E8 for ; Tue, 17 Aug 2010 13:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KQ3EFCmBX41 for ; Tue, 17 Aug 2010 13:17:54 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 8F8F13A6946 for ; Tue, 17 Aug 2010 13:17:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=iulmTKF93CPA1T6NSr9506tUudKo8KpATrsZW4XL3a/uJ0UEkUHamSrE/D504BeL; 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.41.48.100] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlSc9-00068B-Kf for netconf@ietf.org; Tue, 17 Aug 2010 16:18:29 -0400 Message-ID: <00bc01cb3e49$5d0da0a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Tue, 17 Aug 2010 13:18:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fea39a029ac8faefa0cda5dfaa0c18920d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.48.100 Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:17:55 -0000 Hi - > From: "Andy Bierman" > To: "Ladislav Lhotka" ; "Wes Hardaker" ; "Kent Watsen" > Cc: > Sent: Tuesday, August 17, 2010 1:12 PM > Subject: Re: [Netconf] how to handle XML parse errors > > If the hacker can see the XML then closing off the end tags correctly > will be trivial. If not, because the channel is encrypted, then it > will not be so easy. No. The attack does not depend on being able to intercept or modify the data stream. The detailed example showed how the failure to exhaustively inspect USER INPUT makes the attack posisble. Randy From j.schoenwaelder@jacobs-university.de Tue Aug 17 13:43:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A6F3A6A07 for ; Tue, 17 Aug 2010 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.763 X-Spam-Level: X-Spam-Status: No, score=-101.763 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLy+vt5wduau for ; Tue, 17 Aug 2010 13:43:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 727EC3A6A02 for ; Tue, 17 Aug 2010 13:43:08 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D4CDC000D; Tue, 17 Aug 2010 22:43:43 +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 CT7FpXXgpv9b; Tue, 17 Aug 2010 22:43:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D68BC0002; Tue, 17 Aug 2010 22:43:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 32BD6144B3C6; Tue, 17 Aug 2010 22:43:37 +0200 (CEST) Date: Tue, 17 Aug 2010 22:43:37 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100817204337.GA29387@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Wes Hardaker , Kent Watsen , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2010 20:43:09 -0000 On Tue, Aug 17, 2010 at 10:12:19PM +0200, Andy Bierman wrote: > If the hacker can see the XML then closing off the end tags > correctly will be trivial. If not, because the channel is > encrypted, then it will not be so easy. Assuming that the data model is not a hidden secret (and NETCONF itself surely isn't), it boils down to guessing the correct namespace prefixes, no? Even brute force testing might be doable since most people choose short prefixes. So yes, closing the session raises the bar a bit but not for someone seriously interested. /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@cesnet.cz Tue Aug 17 13:57:43 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB6A3A6A02 for ; Tue, 17 Aug 2010 13:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ8RwZwSxgSH for ; Tue, 17 Aug 2010 13:57:42 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id 6D1A93A680B for ; Tue, 17 Aug 2010 13:57:42 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id C3B4D3E05EB; Tue, 17 Aug 2010 22:57:59 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Wes Hardaker , Kent Watsen In-Reply-To: References: User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Tue, 17 Aug 2010 22:58:14 +0200 Message-ID: <87hbitq7mh.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:57:43 -0000 On Tue, 17 Aug 2010 13:12:19 -0700, Andy Bierman wrote: > If the hacker can see the XML then closing off the end tags correctly > will be trivial. If not, because the channel is encrypted, then it > will not be so easy. No, it is sufficient to figure out where the user input belongs. Knowing the data model, it is not very hard to guess that it is the element, given that the script asks for "Full Name". Such simple scripts are only good for a trusted environment, otherwise a schema-based validation on the client side is a must. Fortunately, it's quite easy to do even in a shell script. That said, I think that terminating the session upon receiving a non-well-formed PDU is probably a good thing even though the security argument is not very strong. For instance, what else could the server do if the sequence "]]>]]>" appeared inside a valid document, i.e. in an attribute value, PI or comment? Lada > > Andy > > ----- Reply message ----- > From: "Ladislav Lhotka" > Date: Tue, Aug 17, 2010 08:41 > Subject: [Netconf] how to handle XML parse errors > To: "Wes Hardaker" , "Kent Watsen" > Cc: "netconf@ietf.org" > > > On Tue, 17 Aug 2010 07:38:21 -0700, Wes Hardaker wrote: > > #!/bin/csh > > echo "please enter your desired Account Name:" > > set loginname=$< > > > > echo "please enter your Full Name:" > > set name=$< > > > > cat << EOF | netconf-client remotehost.example.com > > > > > > > > > > > > > > $loginname > > $name > > > > > > > > > > > > > > The above works great if the user is nice. I'd even bet that most > > people *would* check the $loginname field, since that's an obvious place > > where bad data would matter. But I'd bet that many operators will fail > > to check the $name field, because why would it matter? A name can > > contain just about anything. It works less great if the user types in a > > fullname of > > > > ]]>]]> > > ... > > newsecret > > ... > > > > Even if the session is terminated on non-well-formed input, it's only > little extra work for the bad guy to make it well-formed: > > Black Hat...]]>]]> > ... > newsecret > > So terminating the session doesn't really close this security hole. > > Lada > > -- > Ladislav Lhotka, CESNET > PGP Key ID: E74E8C0C > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > Non-text part: text/html -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From ietf@andybierman.com Tue Aug 17 14:01:23 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D1553A6A35 for ; Tue, 17 Aug 2010 14:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTcTW0mET73X for ; Tue, 17 Aug 2010 14:01:21 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by core3.amsl.com (Postfix) with ESMTP id 7E4F43A6A18 for ; Tue, 17 Aug 2010 14:01:20 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7HL1teP010459 for ; Tue, 17 Aug 2010 17:01:55 -0400 Authentication-Results: cm-omr6 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [184.192.101.91] ([184.192.101.91:33700] helo=[184.192.101.91]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id A8/4A-16497-1C8FA6C4; Tue, 17 Aug 2010 17:01:55 -0400 To: "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Tue, 17 Aug 2010 14:02:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_11_1282078928935" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 21:01:23 -0000 ------=_Part_11_1282078928935 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U28gd2h5IGRvIHdlIGV2ZW4gY2FyZT8KSWYgdGhlIHByb2dyYW1tZXIgaXMgc28gYmFkIHRoYXQg WE1MIGlzIGFjY2VwdGVkIHdpdGhvdXQgZXZlbiBjaGFuZ2luZyBhbmdsZSBicmFja2V0cyB0byBj aGFyYWN0ZXIgZW50aXRpZXMsIHRoZW4geW91IGdldCB3aGF0IHlvdSBkZXNlcnZlLiAgRHJvcHBp bmcgdGhlIHNlc3Npb24gbWFrZXMgaXQgaGFyZGVyIHRvIGtlZXAgdHJ5aW5nIHRoZSBhdHRhY2su ClRoZSBhZG1pbiBtaWdodCBub3RpY2UgYWxsIHRoZSBzZXNzaW9uIG5vdGlmaWNhdGlvbnMgKGlm IGFueSkuCgpBbmR5CgoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiSnVlcmdlbiBT Y2hvZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPgpEYXRl OiBUdWUsIEF1ZyAxNywgMjAxMCAxMzo0MwpTdWJqZWN0OiBbTmV0Y29uZl0gaG93IHRvIGhhbmRs ZSBYTUwgcGFyc2UgZXJyb3JzClRvOiAiQW5keSBCaWVybWFuIiA8aWV0ZkBhbmR5Ymllcm1hbi5j b20+CkNjOiAiTGFkaXNsYXYgTGhvdGthIiA8bGhvdGthQGNlc25ldC5jej4sICJXZXMgSGFyZGFr ZXIiIDx3amhuczFAaGFyZGFrZXJzLm5ldD4sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBl ci5uZXQ+LCAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+CgoKT24gVHVlLCBB dWcgMTcsIDIwMTAgYXQgMTA6MTI6MTlQTSArMDIwMCwgQW5keSBCaWVybWFuIHdyb3RlOgoKPiBJ ZiB0aGUgaGFja2VyIGNhbiBzZWUgdGhlIFhNTCB0aGVuIGNsb3Npbmcgb2ZmIHRoZSBlbmQgdGFn cwo+IGNvcnJlY3RseSB3aWxsIGJlIHRyaXZpYWwuICBJZiBub3QsIGJlY2F1c2UgdGhlIGNoYW5u ZWwgaXMKPiBlbmNyeXB0ZWQsIHRoZW4gaXQgd2lsbCBub3QgYmUgc28gZWFzeS4KCkFzc3VtaW5n IHRoYXQgdGhlIGRhdGEgbW9kZWwgaXMgbm90IGEgaGlkZGVuIHNlY3JldCAoYW5kIE5FVENPTkYK aXRzZWxmIHN1cmVseSBpc24ndCksIGl0IGJvaWxzIGRvd24gdG8gZ3Vlc3NpbmcgdGhlIGNvcnJl Y3QgbmFtZXNwYWNlCnByZWZpeGVzLCBubz8gRXZlbiBicnV0ZSBmb3JjZSB0ZXN0aW5nIG1pZ2h0 IGJlIGRvYWJsZSBzaW5jZSBtb3N0CnBlb3BsZSBjaG9vc2Ugc2hvcnQgcHJlZml4ZXMuIFNvIHll cywgY2xvc2luZyB0aGUgc2Vzc2lvbiByYWlzZXMgdGhlCmJhciBhIGJpdCBidXQgbm90IGZvciBz b21lb25lIHNlcmlvdXNseSBpbnRlcmVzdGVkLgoKL2pzCgotLSAKSnVlcmdlbiBTY2hvZW53YWVs ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgKUGhvbmU6ICs0OSA0 MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxLCAyODc1OSBCcmVtZW4sIEdlcm1hbnkK RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+Cgo= ------=_Part_11_1282078928935 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline U28gd2h5IGRvIHdlIGV2ZW4gY2FyZT88YnI+SWYgdGhlIHByb2dyYW1tZXIgaXMgc28gYmFkIHRo YXQgWE1MIGlzIGFjY2VwdGVkIHdpdGhvdXQgZXZlbiBjaGFuZ2luZyBhbmdsZSBicmFja2V0cyB0 byBjaGFyYWN0ZXIgZW50aXRpZXMsIHRoZW4geW91IGdldCB3aGF0IHlvdSBkZXNlcnZlLiAmbmJz cDtEcm9wcGluZyB0aGUgc2Vzc2lvbiBtYWtlcyBpdCBoYXJkZXIgdG8ga2VlcCB0cnlpbmcgdGhl IGF0dGFjay48YnI+VGhlIGFkbWluIG1pZ2h0IG5vdGljZSBhbGwgdGhlIHNlc3Npb24gbm90aWZp Y2F0aW9ucyAoaWYgYW55KS48YnI+PGJyPkFuZHk8YnI+PGJyPjxicj4tLS0tLSBSZXBseSBtZXNz YWdlIC0tLS0tPGJyPkZyb206ICZxdW90O0p1ZXJnZW4gU2Nob2Vud2FlbGRlciZxdW90OyAmbHQ7 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0Ozxicj5EYXRlOiBUdWUsIEF1 ZyAxNywgMjAxMCAxMzo0Mzxicj5TdWJqZWN0OiBbTmV0Y29uZl0gaG93IHRvIGhhbmRsZSBYTUwg cGFyc2UgZXJyb3JzPGJyPlRvOiAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsgJmx0O2lldGZAYW5k eWJpZXJtYW4uY29tJmd0Ozxicj5DYzogJnF1b3Q7TGFkaXNsYXYgTGhvdGthJnF1b3Q7ICZsdDts aG90a2FAY2VzbmV0LmN6Jmd0OywgJnF1b3Q7V2VzIEhhcmRha2VyJnF1b3Q7ICZsdDt3amhuczFA aGFyZGFrZXJzLm5ldCZndDssICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDtrd2F0c2VuQGp1 bmlwZXIubmV0Jmd0OywgJnF1b3Q7bmV0Y29uZkBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0Y29uZkBp ZXRmLm9yZyZndDs8YnI+PGJyPjxicj5PbiBUdWUsIEF1ZyAxNywgMjAxMCBhdCAxMDoxMjoxOVBN ICswMjAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPjxicj4mZ3Q7IElmIHRoZSBoYWNrZXIgY2Fu IHNlZSB0aGUgWE1MIHRoZW4gY2xvc2luZyBvZmYgdGhlIGVuZCB0YWdzPGJyPiZndDsgY29ycmVj dGx5IHdpbGwgYmUgdHJpdmlhbC4gJm5ic3A7SWYgbm90LCBiZWNhdXNlIHRoZSBjaGFubmVsIGlz PGJyPiZndDsgZW5jcnlwdGVkLCB0aGVuIGl0IHdpbGwgbm90IGJlIHNvIGVhc3kuPGJyPjxicj5B c3N1bWluZyB0aGF0IHRoZSBkYXRhIG1vZGVsIGlzIG5vdCBhIGhpZGRlbiBzZWNyZXQgKGFuZCBO RVRDT05GPGJyPml0c2VsZiBzdXJlbHkgaXNuJiMzOTt0KSwgaXQgYm9pbHMgZG93biB0byBndWVz c2luZyB0aGUgY29ycmVjdCBuYW1lc3BhY2U8YnI+cHJlZml4ZXMsIG5vPyBFdmVuIGJydXRlIGZv cmNlIHRlc3RpbmcgbWlnaHQgYmUgZG9hYmxlIHNpbmNlIG1vc3Q8YnI+cGVvcGxlIGNob29zZSBz aG9ydCBwcmVmaXhlcy4gU28geWVzLCBjbG9zaW5nIHRoZSBzZXNzaW9uIHJhaXNlcyB0aGU8YnI+ YmFyIGEgYml0IGJ1dCBub3QgZm9yIHNvbWVvbmUgc2VyaW91c2x5IGludGVyZXN0ZWQuPGJyPjxi cj4vanM8YnI+PGJyPi0tIDxicj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8YnI+UGhv bmU6ICs0OSA0MjEgMjAwIDM1ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBS aW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueTxicj5GYXg6ICZuYnNwOyArNDkgNDIxIDIwMCAz MTAzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5q YWNvYnMtdW5pdmVyc2l0eS5kZS8iPmh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9h PiZndDs8YnI+PGJyPjxicj48YnI+ ------=_Part_11_1282078928935-- From j.schoenwaelder@jacobs-university.de Tue Aug 17 14:25:51 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE2D3A68DC for ; Tue, 17 Aug 2010 14:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.771 X-Spam-Level: X-Spam-Status: No, score=-101.771 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2nthsd8JTsb for ; Tue, 17 Aug 2010 14:25:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6FB663A6853 for ; Tue, 17 Aug 2010 14:25:50 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9DFC8C0006; Tue, 17 Aug 2010 23:26:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qc2D3Ae+P2HQ; Tue, 17 Aug 2010 23:26:24 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1996FC0002; Tue, 17 Aug 2010 23:26:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4751E144B5BA; Tue, 17 Aug 2010 23:26:20 +0200 (CEST) Date: Tue, 17 Aug 2010 23:26:20 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100817212620.GA29487@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Wes Hardaker , Kent Watsen , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 17 Aug 2010 21:25:51 -0000 On Tue, Aug 17, 2010 at 11:02:08PM +0200, Andy Bierman wrote: > So why do we even care? Closing the session is a drastic measure but given the shortcomings of the framing we have invented, this might be the most robust solution overall, although likely a bit annoying on the cut'n'paste interface. /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@cesnet.cz Tue Aug 17 21:56:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FC13A6839 for ; Tue, 17 Aug 2010 21:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4d77t+gtY+ky for ; Tue, 17 Aug 2010 21:56:02 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id E35543A682A for ; Tue, 17 Aug 2010 21:56:01 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 678DC3E05ED; Wed, 18 Aug 2010 06:56:20 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , Andy Bierman In-Reply-To: <20100817212620.GA29487@elstar.local> References: <20100817212620.GA29487@elstar.local> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Wed, 18 Aug 2010 06:56:35 +0200 Message-ID: <871v9w1pto.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 04:56:03 -0000 On Tue, 17 Aug 2010 23:26:20 +0200, Juergen Schoenwaelder wrote: > On Tue, Aug 17, 2010 at 11:02:08PM +0200, Andy Bierman wrote: > > > So why do we even care? > > Closing the session is a drastic measure but given the shortcomings of > the framing we have invented, this might be the most robust solution > overall, although likely a bit annoying on the cut'n'paste interface. I agree. Perhaps the server could just send an error message ("malformed input") before closing the session. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mehmet.ersue@nsn.com Wed Aug 18 05:07:30 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A171F3A6870; Wed, 18 Aug 2010 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0FyeQIg566Q; Wed, 18 Aug 2010 05:07:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id ED7B63A68CF; Wed, 18 Aug 2010 05:07:28 -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 o7IC7pXF011337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Aug 2010 14:07:52 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7IC7ndF028252; Wed, 18 Aug 2010 14:07:50 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 14:07:49 +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, 18 Aug 2010 14:07:45 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64D63CDD@DEMUEXC006.nsn-intra.net> In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Network-wide Configuration - TM Forum View thread-index: Acs5PW1cqsiUctr7QHSkDxLM5YesGAAbqK5wABozHqAAACks8AAAovpQAAEs46AAAD2ZkAAAG+sAAAA+g2AAADkW4AAA0omAAAC564ABKXrDkA== References: <80A0822C5E9A4440A5117C2F4CD36A64D17E7D@DEMUEXC006.nsn-intra.net> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Andy Bierman" , "Phil Shafer" , "ext Martin Bjorklund" , "ext Bert (IETF) Wijnen" , , "Linowski, Bernd (EXT-Other - DE)" , "Kessens, David (NSN - US/Mountain View)" , "Juergen Schoenwaelder" , "ext Ladislav Lhotka" , "ext Davis, Nigel" X-OriginalArrivalTime: 18 Aug 2010 12:07:49.0518 (UTC) FILETIME=[FA1662E0:01CB3ECD] X-Mailman-Approved-At: Wed, 18 Aug 2010 05:12:13 -0700 Cc: netconf@ietf.org, NETMOD Working Group Subject: Re: [Netconf] Network-wide Configuration - TM Forum View X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 12:07:30 -0000 Hi All, there was no consensus on doodle for a conf time.=20 Some keyplayer cannot on the time where the majority=20 can. Pls fill out the new doodle: http://www.doodle.com/piexidce9kctgctz=20 This time the majority will win ;-) To make it more supportive for consensus I excluded=20 some obvious time slots (e.g. IESG chat). Nigel will take care on conf bridge and webex a few days before the meeting. PS: I am in vacation betw. 8/23-9/6. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Ersue, Mehmet (NSN - DE/Munich) > Sent: Thursday, August 12, 2010 8:19 PM > To: ext Andy Bierman; Phil Shafer; ext Martin Bjorklund; ext Bert > (IETF) Wijnen; dromasca@avaya.com; Linowski, Bernd (EXT-Other - DE); > Kessens, David (NSN - US/Mountain View); Juergen Schoenwaelder; ext > Ladislav Lhotka; ext Davis, Nigel > Cc: netconf@ietf.org; NETMOD Working Group > Subject: [Netconf] Network-wide Configuration - TM Forum View >=20 > Hi All, >=20 > as discussed in the Network-wide configuration BarBof > in Maastricht Nigel Davis from TM Forum volunteered to > give us an overview on the TMF network model, NE-Mediation- > EMS as well as the modeling and tooling framework at TMF. >=20 > Following is a draft agenda: >=20 > - Level set on purpose of meeting with respect to the bar BoF > discussion > - Briefly discuss NE-Mediation-EMS approach to dealing with > normalisation > - Examine the TMF network model and documentation structure/locations > - Discuss next step, possible liaison and ongoing work approach >=20 > Please let Nigel know if you would like to have additional > agenda points. >=20 > The proposed date for a conf call (1.5 hours) is next > Thursday (8/19) or Friday (8/20). Please check the doodle > below and enter your preferred time. >=20 > http://www.doodle.com/4gq3niupbev3vg6m >=20 > PS: We hope 8/19 or 8/20 does work for a conf call. > If not we can arrange another date. >=20 > Cheers, > Mehmet >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From wjhns1@hardakers.net Wed Aug 18 08:01:54 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5523A6987 for ; Wed, 18 Aug 2010 08:01:54 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dln6w7shPBmE for ; Wed, 18 Aug 2010 08:01:53 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id AF0E53A68A7 for ; Wed, 18 Aug 2010 08:01:53 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 9E79B9805C; Wed, 18 Aug 2010 08:02:28 -0700 (PDT) From: Wes Hardaker To: Wes Hardaker Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> <20100817143045.GA28554@elstar.local> Date: Wed, 18 Aug 2010 08:02:28 -0700 In-Reply-To: <20100817143045.GA28554@elstar.local> (Juergen Schoenwaelder's message of "Tue, 17 Aug 2010 16:30:46 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:01:54 -0000 >>>>> On Tue, 17 Aug 2010 16:30:46 +0200, Juergen Schoenwaelder said: JS> I wrote "the client gets what it asked for". Fair enough... JS> I also note that all existing specified NETCONF transports run over JS> TCP. If your goal is to run NETCONF over DTNs where TCP is not an JS> option, there probably needs some additional work to be done anyway. I generally don't like writing application protocols that "assume TCP is in use". It locks us into "managing only certain types of networks", which I think is a huge mistake. [I do agree, though, that other work is likely needed too] -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Aug 18 08:03:15 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B36293A68A7 for ; Wed, 18 Aug 2010 08:03:15 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6JwxVzvy4zv for ; Wed, 18 Aug 2010 08:03:15 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id BFEA63A6840 for ; Wed, 18 Aug 2010 08:03:14 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BB5B298066; Wed, 18 Aug 2010 08:03:49 -0700 (PDT) From: Wes Hardaker To: Ladislav Lhotka Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <8762z9z1pi.fsf@cesnet.cz> Date: Wed, 18 Aug 2010 08:03:49 -0700 In-Reply-To: <8762z9z1pi.fsf@cesnet.cz> (Ladislav Lhotka's message of "Tue, 17 Aug 2010 17:41:13 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:03:15 -0000 >>>>> On Tue, 17 Aug 2010 17:41:13 +0200, Ladislav Lhotka said: LL> Black Hat...]]>]]> ... LL> So terminating the session doesn't really close this security hole. No, but it makes it at least require either sniffing an encrypted connection or having access to exactly what the management station is sending. With just a ]]>]]> terminator I can do it blind to any code that fails to validate every field. There's a huge difference there. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Wed Aug 18 08:04:20 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E2A3A6840 for ; Wed, 18 Aug 2010 08:04:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVEPmFbRTRrU for ; Wed, 18 Aug 2010 08:04:19 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id D21543A659B for ; Wed, 18 Aug 2010 08:04:18 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id B6EF39806C; Wed, 18 Aug 2010 08:04:53 -0700 (PDT) From: Wes Hardaker To: "Andy Bierman" Organization: Sparta References: <14.D0.10553.0D8AA6C4@cm-omr4> Date: Wed, 18 Aug 2010 08:04:53 -0700 In-Reply-To: <14.D0.10553.0D8AA6C4@cm-omr4> (Andy Bierman's message of "Tue, 17 Aug 2010 08:21:05 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:04:20 -0000 >>>>> On Tue, 17 Aug 2010 08:21:05 -0700, "Andy Bierman" said: AB> The server may not ever know which part of the message caused a AB> parse error. In the libxml2 code I use, the EOF error will occur AB> looking for a missing end tag. The server cannot report the exact AB> error. I didn't mean that we should report an exact error; sorry if I misled you. I was actually thinking a generic "parseError" type error (with more detail *if* possible). -- Wes Hardaker Cobham Analytic Solutions From phil@juniper.net Wed Aug 18 08:14:45 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BCC3A6991 for ; Wed, 18 Aug 2010 08:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.266 X-Spam-Level: X-Spam-Status: No, score=-7.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2UNcbeZslJl for ; Wed, 18 Aug 2010 08:14:28 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with ESMTP id A80013A6848 for ; Wed, 18 Aug 2010 08:14:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKTGv47pMWf4w1R//DyKZ5KYX9MQYllL9r@postini.com; Wed, 18 Aug 2010 08:15:03 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.2.254.0; Wed, 18 Aug 2010 08:12:37 -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 o7IFCaU79245; Wed, 18 Aug 2010 08:12:36 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7IEribS060278; Wed, 18 Aug 2010 14:53:45 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008181453.o7IEribS060278@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20100817212620.GA29487@elstar.local> Date: Wed, 18 Aug 2010 10:53:44 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 15:14:45 -0000 Juergen Schoenwaelder writes: >Closing the session is a drastic measure but given the shortcomings of >the framing we have invented, this might be the most robust solution >overall, although likely a bit annoying on the cut'n'paste interface. Any chance we can address the framing issue? It would be nice to have something real, workable, and robust here. Thanks, Phil From j.schoenwaelder@jacobs-university.de Wed Aug 18 08:38:10 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD3D03A69A3 for ; Wed, 18 Aug 2010 08:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.779 X-Spam-Level: X-Spam-Status: No, score=-101.779 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEbN1YN7G0eS for ; Wed, 18 Aug 2010 08:37:59 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 311BA3A697A for ; Wed, 18 Aug 2010 08:37:43 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0ABEBC000D; Wed, 18 Aug 2010 17:37:40 +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 9c+9qP1oFTXI; Wed, 18 Aug 2010 17:37:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 97AF3C0002; Wed, 18 Aug 2010 17:37:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1801E144DEBC; Wed, 18 Aug 2010 17:37:24 +0200 (CEST) Date: Wed, 18 Aug 2010 17:37:23 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100818153723.GA1054@elstar.local> Mail-Followup-To: Wes Hardaker , "netconf@ietf.org" References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <20100816211742.GA26012@elstar.local> <20100817143045.GA28554@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 18 Aug 2010 15:38:10 -0000 X-List-Received-Date: Wed, 18 Aug 2010 15:38:10 -0000 On Wed, Aug 18, 2010 at 05:02:28PM +0200, Wes Hardaker wrote: > I generally don't like writing application protocols that "assume TCP is > in use". It locks us into "managing only certain types of networks", > which I think is a huge mistake. Just to clarify this: NETCONF does not require TCP - it just happens that all existing transports use TCP. The precise requirements are detailed in section 2 of RFC 4741, here is just a short quote: NETCONF is connection-oriented, requiring a persistent connection between peers. This connection must provide reliable, sequenced data delivery. /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@cesnet.cz Wed Aug 18 09:29:26 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F1B23A69A2 for ; Wed, 18 Aug 2010 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygcjqE3++L10 for ; Wed, 18 Aug 2010 09:29:25 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id D77213A69A6 for ; Wed, 18 Aug 2010 09:29:24 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 05AA33E05ED; Wed, 18 Aug 2010 18:29:41 +0200 (CEST) From: Ladislav Lhotka To: Wes Hardaker In-Reply-To: References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <8762z9z1pi.fsf@cesnet.cz> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Wed, 18 Aug 2010 18:29:56 +0200 Message-ID: <878w43994r.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:29:26 -0000 On Wed, 18 Aug 2010 08:03:49 -0700, Wes Hardaker wrote: > >>>>> On Tue, 17 Aug 2010 17:41:13 +0200, Ladislav Lhotka said: > > LL> Black Hat...]]>]]> > ... > LL> So terminating the session doesn't really close this security hole. > > No, but it makes it at least require either sniffing an encrypted > connection or having access to exactly what the management station is > sending. With just a ]]>]]> terminator I can do it blind to any code The management station must be sending what's written in the data model, so the attacker will just need to consult a nicely documented YANG module and guess a suitable target XML element for his input. It's a piece of cake. > that fails to validate every field. There's a huge difference there. While we both agree that the server should close the session upon receiving a malformed message, it must not be advertized as a remedy against code injection. Failing to validate every field will remain a huge security hole. Lada > -- > Wes Hardaker > Cobham Analytic Solutions -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From kwatsen@juniper.net Wed Aug 18 09:56:31 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8453A67FD for ; Wed, 18 Aug 2010 09:56:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijjvTbr45jO4 for ; Wed, 18 Aug 2010 09:56:31 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 009943A65A6 for ; Wed, 18 Aug 2010 09:56:30 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTGwQ36GvJaZAYr41ZGFwT/Ey97jq/N/V@postini.com; Wed, 18 Aug 2010 09:57:06 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; Wed, 18 Aug 2010 09:54:25 -0700 From: Kent Watsen To: Phil Shafer , Juergen Schoenwaelder Date: Wed, 18 Aug 2010 09:54:22 -0700 Thread-Topic: [Netconf] how to handle XML parse errors Thread-Index: Acs+6DRy+5GddzCxR2KO1fgRif2XMgACpRqQ Message-ID: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> References: <20100817212620.GA29487@elstar.local> <201008181453.o7IEribS060278@idle.juniper.net> In-Reply-To: <201008181453.o7IEribS060278@idle.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 16:56:32 -0000 Phil Shafer writes: > Any chance we can address the framing issue? It would be nice to > have something real, workable, and robust here. Isn't framing fundamentally supported by matching XML tags? ]]>]]> is only= there to support recovery, it's not intended to support framing - right? = =20 4742 says the ]]>]]> is to only to allow "resynchronization of the NETCONF = exchange in the event of an XML syntax or parsing error." My reading of th= at is that the parsing error has to happen first, then the agent resynchron= izes on the next ]]>]]>. While the parsing error may be caused due to an u= nexpected ]]>]]>, that seems like a very special case. =20 Given this shift in emphasis, I'm comfortable in closing the session if and= only if the parsing error is due to an unexpected ]]>]]>. This text should go into 4742bis, not 4741bis Thanks, Kent From ietf@andybierman.com Wed Aug 18 10:10:16 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7686D3A6A04 for ; Wed, 18 Aug 2010 10:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4p7+cGdR5Zz for ; Wed, 18 Aug 2010 10:10:01 -0700 (PDT) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by core3.amsl.com (Postfix) with ESMTP id 976E83A6782 for ; Wed, 18 Aug 2010 10:10:00 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7IHAZB2018566 for ; Wed, 18 Aug 2010 13:10:35 -0400 Authentication-Results: cm-omr1 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.112.111.30] ([108.112.111.30:41666] helo=[108.112.111.30]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D4/21-29811-9041C6C4; Wed, 18 Aug 2010 13:10:35 -0400 To: "=?utf-8?B?S2VudCBXYXRzZW4=?=" , "=?utf-8?B?UGhpbCBTaGFmZXI=?=" , "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 18 Aug 2010 10:10:48 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_12_1282151448683" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:10:16 -0000 ------=_Part_12_1282151448683 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBpcyBkZWVwIGludG8gaW1wbGVtZW50YXRpb24gZGV0YWlscy4gIEluIHRoZSB5dW1hIGNv ZGUsIHRoZSBwcm9jZXNzIGxpc3RlbmluZyBmb3IgaW5wdXQgdXNlcyB0aGUgZW9tIG1hcmtlciB0 byBkZWNpZGUgd2hhdCB0byBnaXZlIHRvIHhtbFRleHRSZWFkZXIuICBEbyBub3QgYXNzdW1lIHRo ZSBzc2ggY29kZSB1bmRlcnN0YW5kcyBYTUwuCgpBRkFJSywgdGhlcmUgaXMgbm8gd2F5IHRvIHB1 dCBjaGFycyBpbiB0aGUgWE1MIHN0cmVhbSBmb3IgZnJhbWluZywgc28gdGhlcmUgaXMgbm8gcG9p bnQgaW4gY2hhbmdpbmcgNDc0Mi4KCkFuZHkKCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZy b206ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+CkRhdGU6IFdlZCwgQXVnIDE4 LCAyMDEwIDA5OjU0ClN1YmplY3Q6IFtOZXRjb25mXSBob3cgdG8gaGFuZGxlIFhNTCBwYXJzZSBl cnJvcnMKVG86ICJQaGlsIFNoYWZlciIgPHBoaWxAanVuaXBlci5uZXQ+LCAiSnVlcmdlbiBTY2hv ZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPgpDYzogIm5l dGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPgoKCgpQaGlsIFNoYWZlciB3cml0ZXM6 Cj4gQW55IGNoYW5jZSB3ZSBjYW4gYWRkcmVzcyB0aGUgZnJhbWluZyBpc3N1ZT8gIEl0IHdvdWxk IGJlIG5pY2UgdG8KPiBoYXZlIHNvbWV0aGluZyByZWFsLCB3b3JrYWJsZSwgYW5kIHJvYnVzdCBo ZXJlLgoKCklzbid0IGZyYW1pbmcgZnVuZGFtZW50YWxseSBzdXBwb3J0ZWQgYnkgbWF0Y2hpbmcg WE1MIHRhZ3M/ICBdXT5dXT4gaXMgb25seSB0aGVyZSB0byBzdXBwb3J0IHJlY292ZXJ5LCBpdCdz IG5vdCBpbnRlbmRlZCB0byBzdXBwb3J0IGZyYW1pbmcgLSByaWdodD8gICAKCjQ3NDIgc2F5cyB0 aGUgXV0+XV0+IGlzIHRvIG9ubHkgdG8gYWxsb3cgInJlc3luY2hyb25pemF0aW9uIG9mIHRoZSBO RVRDT05GIGV4Y2hhbmdlIGluIHRoZSBldmVudCBvZiBhbiBYTUwgc3ludGF4IG9yIHBhcnNpbmcg ZXJyb3IuIiAgTXkgcmVhZGluZyBvZiB0aGF0IGlzIHRoYXQgdGhlIHBhcnNpbmcgZXJyb3IgaGFz IHRvIGhhcHBlbiBmaXJzdCwgdGhlbiB0aGUgYWdlbnQgcmVzeW5jaHJvbml6ZXMgb24gdGhlIG5l eHQgXV0+XV0+LiAgV2hpbGUgdGhlIHBhcnNpbmcgZXJyb3IgbWF5IGJlIGNhdXNlZCBkdWUgdG8g YW4gdW5leHBlY3RlZCBdXT5dXT4sIHRoYXQgc2VlbXMgbGlrZSBhIHZlcnkgc3BlY2lhbCBjYXNl LiAgCgpHaXZlbiB0aGlzIHNoaWZ0IGluIGVtcGhhc2lzLCBJJ20gY29tZm9ydGFibGUgaW4gY2xv c2luZyB0aGUgc2Vzc2lvbiBpZiBhbmQgb25seSBpZiB0aGUgcGFyc2luZyBlcnJvciBpcyBkdWUg dG8gYW4gdW5leHBlY3RlZCBdXT5dXT4uCgpUaGlzIHRleHQgc2hvdWxkIGdvIGludG8gNDc0MmJp cywgbm90IDQ3NDFiaXMKClRoYW5rcywKS2VudAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9y ZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCg== ------=_Part_12_1282151448683 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline VGhpcyBpcyBkZWVwIGludG8gaW1wbGVtZW50YXRpb24gZGV0YWlscy4gJm5ic3A7SW4gdGhlIHl1 bWEgY29kZSwgdGhlIHByb2Nlc3MgbGlzdGVuaW5nIGZvciBpbnB1dCB1c2VzIHRoZSBlb20gbWFy a2VyIHRvIGRlY2lkZSB3aGF0IHRvIGdpdmUgdG8geG1sVGV4dFJlYWRlci4gJm5ic3A7RG8gbm90 IGFzc3VtZSB0aGUgc3NoIGNvZGUgdW5kZXJzdGFuZHMgWE1MLjxicj48YnI+QUZBSUssIHRoZXJl IGlzIG5vIHdheSB0byBwdXQgY2hhcnMgaW4gdGhlIFhNTCBzdHJlYW0gZm9yIGZyYW1pbmcsIHNv IHRoZXJlIGlzIG5vIHBvaW50IGluIGNoYW5naW5nIDQ3NDIuPGJyPjxicj5BbmR5PGJyPjxicj48 YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtLZW50IFdhdHNlbiZx dW90OyAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZndDs8YnI+RGF0ZTogV2VkLCBBdWcgMTgsIDIw MTAgMDk6NTQ8YnI+U3ViamVjdDogW05ldGNvbmZdIGhvdyB0byBoYW5kbGUgWE1MIHBhcnNlIGVy cm9yczxicj5UbzogJnF1b3Q7UGhpbCBTaGFmZXImcXVvdDsgJmx0O3BoaWxAanVuaXBlci5uZXQm Z3Q7LCAmcXVvdDtKdWVyZ2VuIFNjaG9lbndhZWxkZXImcXVvdDsgJmx0O2ouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+Q2M6ICZxdW90O25ldGNvbmZAaWV0Zi5vcmcm cXVvdDsgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+PGJyPlBoaWwgU2hhZmVy IHdyaXRlczo8YnI+Jmd0OyBBbnkgY2hhbmNlIHdlIGNhbiBhZGRyZXNzIHRoZSBmcmFtaW5nIGlz c3VlPyAmbmJzcDtJdCB3b3VsZCBiZSBuaWNlIHRvPGJyPiZndDsgaGF2ZSBzb21ldGhpbmcgcmVh bCwgd29ya2FibGUsIGFuZCByb2J1c3QgaGVyZS48YnI+PGJyPjxicj5Jc24mIzM5O3QgZnJhbWlu ZyBmdW5kYW1lbnRhbGx5IHN1cHBvcnRlZCBieSBtYXRjaGluZyBYTUwgdGFncz8gJm5ic3A7XV0m Z3Q7XV0mZ3Q7IGlzIG9ubHkgdGhlcmUgdG8gc3VwcG9ydCByZWNvdmVyeSwgaXQmIzM5O3Mgbm90 IGludGVuZGVkIHRvIHN1cHBvcnQgZnJhbWluZyAtIHJpZ2h0PyAmbmJzcDsgPGJyPjxicj40NzQy IHNheXMgdGhlIF1dJmd0O11dJmd0OyBpcyB0byBvbmx5IHRvIGFsbG93ICZxdW90O3Jlc3luY2hy b25pemF0aW9uIG9mIHRoZSBORVRDT05GIGV4Y2hhbmdlIGluIHRoZSBldmVudCBvZiBhbiBYTUwg c3ludGF4IG9yIHBhcnNpbmcgZXJyb3IuJnF1b3Q7ICZuYnNwO015IHJlYWRpbmcgb2YgdGhhdCBp cyB0aGF0IHRoZSBwYXJzaW5nIGVycm9yIGhhcyB0byBoYXBwZW4gZmlyc3QsIHRoZW4gdGhlIGFn ZW50IHJlc3luY2hyb25pemVzIG9uIHRoZSBuZXh0IF1dJmd0O11dJmd0Oy4gJm5ic3A7V2hpbGUg dGhlIHBhcnNpbmcgZXJyb3IgbWF5IGJlIGNhdXNlZCBkdWUgdG8gYW4gdW5leHBlY3RlZCBdXSZn dDtdXSZndDssIHRoYXQgc2VlbXMgbGlrZSBhIHZlcnkgc3BlY2lhbCBjYXNlLiAmbmJzcDs8YnI+ PGJyPkdpdmVuIHRoaXMgc2hpZnQgaW4gZW1waGFzaXMsIEkmIzM5O20gY29tZm9ydGFibGUgaW4g Y2xvc2luZyB0aGUgc2Vzc2lvbiBpZiBhbmQgb25seSBpZiB0aGUgcGFyc2luZyBlcnJvciBpcyBk dWUgdG8gYW4gdW5leHBlY3RlZCBdXSZndDtdXSZndDsuPGJyPjxicj5UaGlzIHRleHQgc2hvdWxk IGdvIGludG8gNDc0MmJpcywgbm90IDQ3NDFiaXM8YnI+PGJyPlRoYW5rcyw8YnI+S2VudDxicj48 YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+TmV0 Y29uZiBtYWlsaW5nIGxpc3Q8YnI+TmV0Y29uZkBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_12_1282151448683-- From phil@juniper.net Wed Aug 18 10:23:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4689B3A67FE for ; Wed, 18 Aug 2010 10:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ7-r15OOwx6 for ; Wed, 18 Aug 2010 10:23:52 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 545F53A67FD for ; Wed, 18 Aug 2010 10:22:48 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTGwXCyBj2iMDjcKU9L76sGIi6K6c0H3h@postini.com; Wed, 18 Aug 2010 10:23:25 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.2.254.0; Wed, 18 Aug 2010 10:19:52 -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 o7IHJpU33216; Wed, 18 Aug 2010 10:19:51 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7IH10MG061508; Wed, 18 Aug 2010 17:01:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008181701.o7IH10MG061508@idle.juniper.net> To: Kent Watsen In-Reply-To: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> Date: Wed, 18 Aug 2010 13:01:00 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:23:53 -0000 Kent Watsen writes: >Isn't framing fundamentally supported by matching XML tags? ]]>]]> is only > there to support recovery, it's not intended to support framing - right? Matching tags means garbage-in-garbage-out. Without a real framing protocol you are trusting the content to tell you when the content ends. And one can't look for blindly for the string "", since this could reasonably appear inside the message. No one is excited about the idea, but having real content framing would be goodness. >Given this shift in emphasis, I'm comfortable in closing the session if and= > only if the parsing error is due to an unexpected ]]>]]>. FWIW, here's the original text from the junoscript draft (in 2002): http://tools.ietf.org/id/draft-shafer-js-xml-api-00.txt 2.5 Framing Protocol Errors When errors are detected in the framing protocol, the JUNOScript server closes the connection. Although this behavior may seem severe, the server cannot trust that it will not discard something important during error recovery that may cause the script to fail its intended purpose. Errors in RPC content are acceptable and are reported as errors, but failures of the framing protocol are fatal. This scenario is a result of having both framing and content in XML. A distinct framing protocol would not have this problem. The choice was between a non-XML framing protocol and having the entire session form a component XML document. Given our expectation of JUNOScript as a component of UNIX pipelines in shell scripts, we chose the latter. Thanks, Phil From phil@juniper.net Wed Aug 18 10:34:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F173A686C for ; Wed, 18 Aug 2010 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.623 X-Spam-Level: X-Spam-Status: No, score=-6.623 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX1kmczAdzWZ for ; Wed, 18 Aug 2010 10:33:36 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by core3.amsl.com (Postfix) with ESMTP id 18B3D3A6957 for ; Wed, 18 Aug 2010 10:31:24 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTGwY99zC7Swj32q+ZzVFBVOicz+rugeH@postini.com; Wed, 18 Aug 2010 10:32: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.2.254.0; Wed, 18 Aug 2010 10:30:38 -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 o7IHUbU37855; Wed, 18 Aug 2010 10:30:37 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7IHBkQW061643; Wed, 18 Aug 2010 17:11:46 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008181711.o7IHBkQW061643@idle.juniper.net> To: =?utf-8?B?QW5keSBCaWVybWFu?= In-Reply-To: Date: Wed, 18 Aug 2010 13:11:46 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 17:34:55 -0000 "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >AFAIK, there is no way to put chars in the XML stream for framing, so there is >no point in changing 4742. The transport encoding can insert whatever is needed. For example, I could define a framing protocol that inserts "#Frame-length" messages into the text, and "#End-of-frame" at the end of a message. There would be no confusion about when a message ends and no overlap between content and framing. #Frame-length: 1024 ... 1024 bytes of content #Frame-length: 1024 ... 1024 bytes of content #Frame-length: 56 ... 56 bytes of content #End-of-frame The "write" code is simple: fprintf(fp, "#Frame-length: %u\n%s", strlen(msg), msg); and the reading code is similarly simple. End-of-frame detection is simple and robust. If I want to manually construct data, I can calculate the length and add the it statically to the top of my file, and if I want to cut-n-parse, I can make a perl function to do this framing for me. Yeah, I know; none of this is news and I've begged for this before, but somehow I just couldn't stop myself. Thanks, Phil From ietf@andybierman.com Wed Aug 18 11:10:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F50B3A69F2 for ; Wed, 18 Aug 2010 11:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb5qojuyS-Ej for ; Wed, 18 Aug 2010 11:10:51 -0700 (PDT) Received: from omr17.networksolutionsemail.com (omr17.networksolutionsemail.com [205.178.146.67]) by core3.amsl.com (Postfix) with ESMTP id 6E5FD3A6A20 for ; Wed, 18 Aug 2010 11:10:45 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr17.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7IIBKtl025255 for ; Wed, 18 Aug 2010 14:11:20 -0400 Authentication-Results: cm-omr2 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.112.111.30] ([108.112.111.30:56962] helo=[108.112.111.30]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id AA/8A-32483-6422C6C4; Wed, 18 Aug 2010 14:11:20 -0400 To: "=?utf-8?B?UGhpbCBTaGFmZXI=?=" Message-ID: From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 18 Aug 2010 11:11:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_13_1282155094117" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:10:53 -0000 ------=_Part_13_1282155094117 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkaXNhZ3JlZS4gIFRoaXMgaXMgdmFsaWQgWE1MIGNvbnRlbnQsIHNvIHRoZSBzZXJ2ZXIgY2Fu bm90IGlnbm9yZSB0aGUgWE1MIGFuZCBqdXN0IGxvb2sgZm9yIHNvbWUgc3RyaW5nLiAgVGhpcyBj b3VsZCBiZSBsZWFmIGNvbnRlbnQgaW5zdGVhZCBvZiB0aGUgZnJhbWUgc3RhcnQgbXNnLgoKCkFu ZHkKCgotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tCkZyb206ICJQaGlsIFNoYWZlciIgPHBoaWxA anVuaXBlci5uZXQ+CkRhdGU6IFdlZCwgQXVnIDE4LCAyMDEwIDEwOjExClN1YmplY3Q6IFtOZXRj b25mXSBob3cgdG8gaGFuZGxlIFhNTCBwYXJzZSBlcnJvcnMKVG86ICJBbmR5IEJpZXJtYW4iIDxp ZXRmQGFuZHliaWVybWFuLmNvbT4KQ2M6ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5u ZXQ+LCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiwgIm5ldGNvbmZAaWV0Zi5vcmciIDxuZXRjb25mQGlldGYub3JnPgoKCiI9P3V0 Zi04P0I/UVc1a2VTQkNhV1Z5YldGdT89IiB3cml0ZXM6Cj5BRkFJSywgdGhlcmUgaXMgbm8gd2F5 IHRvIHB1dCBjaGFycyBpbiB0aGUgWE1MIHN0cmVhbSBmb3IgZnJhbWluZywgc28gdGhlcmUgaXMK Pm5vIHBvaW50IGluIGNoYW5naW5nIDQ3NDIuCgpUaGUgdHJhbnNwb3J0IGVuY29kaW5nIGNhbiBp bnNlcnQgd2hhdGV2ZXIgaXMgbmVlZGVkLiAgRm9yIGV4YW1wbGUsIEkKY291bGQgZGVmaW5lIGEg ZnJhbWluZyBwcm90b2NvbCB0aGF0IGluc2VydHMgIiNGcmFtZS1sZW5ndGgiIG1lc3NhZ2VzCmlu dG8gdGhlIHRleHQsIGFuZCAiI0VuZC1vZi1mcmFtZSIgYXQgdGhlIGVuZCBvZiBhIG1lc3NhZ2Uu ICBUaGVyZQp3b3VsZCBiZSBubyBjb25mdXNpb24gYWJvdXQgd2hlbiBhIG1lc3NhZ2UgZW5kcyBh bmQgbm8gb3ZlcmxhcCBiZXR3ZWVuCmNvbnRlbnQgYW5kIGZyYW1pbmcuCgojRnJhbWUtbGVuZ3Ro OiAxMDI0Ci4uLi4gMTAyNCBieXRlcyBvZiBjb250ZW50CiNGcmFtZS1sZW5ndGg6IDEwMjQKLi4u LiAxMDI0IGJ5dGVzIG9mIGNvbnRlbnQKI0ZyYW1lLWxlbmd0aDogNTYKLi4uLiA1NiBieXRlcyBv ZiBjb250ZW50CiNFbmQtb2YtZnJhbWUKClRoZSAid3JpdGUiIGNvZGUgaXMgc2ltcGxlOgoKICAg IGZwcmludGYoZnAsICIjRnJhbWUtbGVuZ3RoOiAldVxuJXMiLCBzdHJsZW4obXNnKSwgbXNnKTsK CmFuZCB0aGUgcmVhZGluZyBjb2RlIGlzIHNpbWlsYXJseSBzaW1wbGUuICBFbmQtb2YtZnJhbWUg ZGV0ZWN0aW9uCmlzIHNpbXBsZSBhbmQgcm9idXN0LgoKSWYgSSB3YW50IHRvIG1hbnVhbGx5IGNv bnN0cnVjdCBkYXRhLCBJIGNhbiBjYWxjdWxhdGUgdGhlIGxlbmd0aCBhbmQgYWRkIHRoZQppdCBz dGF0aWNhbGx5IHRvIHRoZSB0b3Agb2YgbXkgZmlsZSwgYW5kIGlmIEkgd2FudCB0byBjdXQtbi1w YXJzZSwgSSBjYW4KbWFrZSBhIHBlcmwgZnVuY3Rpb24gdG8gZG8gdGhpcyBmcmFtaW5nIGZvciBt ZS4KClllYWgsIEkga25vdzsgbm9uZSBvZiB0aGlzIGlzIG5ld3MgYW5kIEkndmUgYmVnZ2VkIGZv ciB0aGlzIGJlZm9yZSwKYnV0IHNvbWVob3cgSSBqdXN0IGNvdWxkbid0IHN0b3AgbXlzZWxmLgoK VGhhbmtzLAogUGhpbAoK ------=_Part_13_1282155094117 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkaXNhZ3JlZS4gJm5ic3A7VGhpcyBpcyB2YWxpZCBYTUwgY29udGVudCwgc28gdGhlIHNlcnZl ciBjYW5ub3QgaWdub3JlIHRoZSBYTUwgYW5kIGp1c3QgbG9vayBmb3Igc29tZSBzdHJpbmcuICZu YnNwO1RoaXMgY291bGQgYmUgbGVhZiBjb250ZW50IGluc3RlYWQgb2YgdGhlIGZyYW1lIHN0YXJ0 IG1zZy48YnI+PGJyPjxicj5BbmR5PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0t LTxicj5Gcm9tOiAmcXVvdDtQaGlsIFNoYWZlciZxdW90OyAmbHQ7cGhpbEBqdW5pcGVyLm5ldCZn dDs8YnI+RGF0ZTogV2VkLCBBdWcgMTgsIDIwMTAgMTA6MTE8YnI+U3ViamVjdDogW05ldGNvbmZd IGhvdyB0byBoYW5kbGUgWE1MIHBhcnNlIGVycm9yczxicj5UbzogJnF1b3Q7QW5keSBCaWVybWFu JnF1b3Q7ICZsdDtpZXRmQGFuZHliaWVybWFuLmNvbSZndDs8YnI+Q2M6ICZxdW90O0tlbnQgV2F0 c2VuJnF1b3Q7ICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7SnVlcmdlbiBTY2hv ZW53YWVsZGVyJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUm Z3Q7LCAmcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0 Ozxicj48YnI+PGJyPiZxdW90Oz0/dXRmLTg/Qj9RVzVrZVNCQ2FXVnliV0Z1Pz0mcXVvdDsgd3Jp dGVzOjxicj4mZ3Q7QUZBSUssIHRoZXJlIGlzIG5vIHdheSB0byBwdXQgY2hhcnMgaW4gdGhlIFhN TCBzdHJlYW0gZm9yIGZyYW1pbmcsIHNvIHRoZXJlIGlzPGJyPiZndDtubyBwb2ludCBpbiBjaGFu Z2luZyA0NzQyLjxicj48YnI+VGhlIHRyYW5zcG9ydCBlbmNvZGluZyBjYW4gaW5zZXJ0IHdoYXRl dmVyIGlzIG5lZWRlZC4gJm5ic3A7Rm9yIGV4YW1wbGUsIEk8YnI+Y291bGQgZGVmaW5lIGEgZnJh bWluZyBwcm90b2NvbCB0aGF0IGluc2VydHMgJnF1b3Q7I0ZyYW1lLWxlbmd0aCZxdW90OyBtZXNz YWdlczxicj5pbnRvIHRoZSB0ZXh0LCBhbmQgJnF1b3Q7I0VuZC1vZi1mcmFtZSZxdW90OyBhdCB0 aGUgZW5kIG9mIGEgbWVzc2FnZS4gJm5ic3A7VGhlcmU8YnI+d291bGQgYmUgbm8gY29uZnVzaW9u IGFib3V0IHdoZW4gYSBtZXNzYWdlIGVuZHMgYW5kIG5vIG92ZXJsYXAgYmV0d2Vlbjxicj5jb250 ZW50IGFuZCBmcmFtaW5nLjxicj48YnI+I0ZyYW1lLWxlbmd0aDogMTAyNDxicj4uLi4uIDEwMjQg Ynl0ZXMgb2YgY29udGVudDxicj4jRnJhbWUtbGVuZ3RoOiAxMDI0PGJyPi4uLi4gMTAyNCBieXRl cyBvZiBjb250ZW50PGJyPiNGcmFtZS1sZW5ndGg6IDU2PGJyPi4uLi4gNTYgYnl0ZXMgb2YgY29u dGVudDxicj4jRW5kLW9mLWZyYW1lPGJyPjxicj5UaGUgJnF1b3Q7d3JpdGUmcXVvdDsgY29kZSBp cyBzaW1wbGU6PGJyPjxicj4gJm5ic3A7ICZuYnNwO2ZwcmludGYoZnAsICZxdW90OyNGcmFtZS1s ZW5ndGg6ICV1XG4lcyZxdW90Oywgc3RybGVuKG1zZyksIG1zZyk7PGJyPjxicj5hbmQgdGhlIHJl YWRpbmcgY29kZSBpcyBzaW1pbGFybHkgc2ltcGxlLiAmbmJzcDtFbmQtb2YtZnJhbWUgZGV0ZWN0 aW9uPGJyPmlzIHNpbXBsZSBhbmQgcm9idXN0Ljxicj48YnI+SWYgSSB3YW50IHRvIG1hbnVhbGx5 IGNvbnN0cnVjdCBkYXRhLCBJIGNhbiBjYWxjdWxhdGUgdGhlIGxlbmd0aCBhbmQgYWRkIHRoZTxi cj5pdCBzdGF0aWNhbGx5IHRvIHRoZSB0b3Agb2YgbXkgZmlsZSwgYW5kIGlmIEkgd2FudCB0byBj dXQtbi1wYXJzZSwgSSBjYW48YnI+bWFrZSBhIHBlcmwgZnVuY3Rpb24gdG8gZG8gdGhpcyBmcmFt aW5nIGZvciBtZS48YnI+PGJyPlllYWgsIEkga25vdzsgbm9uZSBvZiB0aGlzIGlzIG5ld3MgYW5k IEkmIzM5O3ZlIGJlZ2dlZCBmb3IgdGhpcyBiZWZvcmUsPGJyPmJ1dCBzb21laG93IEkganVzdCBj b3VsZG4mIzM5O3Qgc3RvcCBteXNlbGYuPGJyPjxicj5UaGFua3MsPGJyPiBQaGlsPGJyPjxicj48 YnI+PGJyPg== ------=_Part_13_1282155094117-- From randy_presuhn@mindspring.com Wed Aug 18 11:29:52 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E673A69EF for ; Wed, 18 Aug 2010 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdVBuA2okOSf for ; Wed, 18 Aug 2010 11:29:51 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 747C73A686E for ; Wed, 18 Aug 2010 11:29:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=LUM0beenP2sjnp39ncpvZhHed01Be2ajcUCVUNL7TY7smRH1ONGv4ZHtmFYc+xEM; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.187.237.139] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OlnP6-00037O-GI for netconf@ietf.org; Wed, 18 Aug 2010 14:30:24 -0400 Message-ID: <005901cb3f03$6cf5f020$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: Date: Wed, 18 Aug 2010 11:30:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88829a3b650ee59d5fe56f2963ddc513285dc7b0c04f3875acc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.187.237.139 Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:29:53 -0000 Hi - > From: "Andy Bierman" > To: "Phil Shafer" > Cc: > Sent: Wednesday, August 18, 2010 11:11 AM > Subject: Re: [Netconf] how to handle XML parse errors > > I disagree. This is valid XML content, so the server cannot ignore the > XML and just look for some string. This could be leaf content instead > of the frame start msg. For recovery purposes the framing needs to be considered a distinct layer from the content processing. When the content layer gets confused or lost, it needs to defer to the framing layer, which should be designed so that it can't be tripped up by the content. Encapsulation with explicit lengths is an easy way to do this, as has already been suggested. This still leaves the possibility of something going wrong at the layer doing the framing, but terminating the association is a reasonable response when the framing layer gets confused. In Netconf, as long as framing and content processing remain entwined, this leads to the conclusion that if some kind of framing / bracketing error is detected, the safest response is to end the connection. Randy From phil@juniper.net Wed Aug 18 11:37:50 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 880683A68CC for ; Wed, 18 Aug 2010 11:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.794 X-Spam-Level: X-Spam-Status: No, score=-6.794 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br4xoJ4DyZic for ; Wed, 18 Aug 2010 11:37:49 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by core3.amsl.com (Postfix) with ESMTP id 1C0AA3A687B for ; Wed, 18 Aug 2010 11:37:44 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTGwonHkIyKyOGkBSvqeACMjZlThzK6NQ@postini.com; Wed, 18 Aug 2010 11:38:23 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.2.254.0; Wed, 18 Aug 2010 11:36:10 -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 o7IIa9U71017; Wed, 18 Aug 2010 11:36:09 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7IIHIvn065989; Wed, 18 Aug 2010 18:17:18 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008181817.o7IIHIvn065989@idle.juniper.net> To: =?utf-8?B?QW5keSBCaWVybWFu?= In-Reply-To: Date: Wed, 18 Aug 2010 14:17:18 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:37:50 -0000 "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >I disagree. This is valid XML content, so the server cannot ignore the XML and >just look for some string. This could be leaf content instead of the frame >start msg. I think you've missed my content completely. Most likely a framing error. ;^) In my code, when I go to write data to an ssh connection, I can easily find the length of the data and prepend that data with "#Frame-length: ", the number of bytes of data, and a newline. When I'm at the end of the data, I can easily send the string "#End-of-frame" and a newline. When I'm ready to read data, I can read a line of inline, inspect that line and see if it begins with "#Frame-length: ". If it does, then I can learn the number of bytes that follow, and then proceed to read that number of bytes. This data can then be passed to an upper layer as XML data (without the "#Frame.*" line). If the line is "#End-of-frame", then I can tell the upper layer and I've seen the end of the frame, which will translate into something similar to EOF. There's no escaping of data, no relying on the data to provide the framing, and no interaction between the framing and the content. Thanks, Phil From ietf@andybierman.com Wed Aug 18 12:22:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78BAB3A6A1B for ; Wed, 18 Aug 2010 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s84cqxb0DwzT for ; Wed, 18 Aug 2010 12:22:34 -0700 (PDT) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by core3.amsl.com (Postfix) with ESMTP id A4ED03A67EB for ; Wed, 18 Aug 2010 12:22:29 -0700 (PDT) Received: from cm-omr1 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7IJN475005417 for ; Wed, 18 Aug 2010 15:23:04 -0400 Authentication-Results: cm-omr1 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.112.111.30] ([108.112.111.30:44505] helo=[108.112.111.30]) by cm-omr1 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 87/72-29811-6133C6C4; Wed, 18 Aug 2010 15:23:04 -0400 To: "=?utf-8?B?UGhpbCBTaGFmZXI=?=" Message-ID: <87.72.29811.6133C6C4@cm-omr1> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 18 Aug 2010 12:23:18 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14_1282159398404" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:22:35 -0000 ------=_Part_14_1282159398404 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24ndCB0aGluayB0aGlzIG1ham9yIGNoYW5nZSB0byB0aGUgc3NoIHRyYW5zcG9ydCBpcyB3 b3J0aCB0aGUgZWZmb3J0LgpJIGRvbid0IHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIHN0YXJ0 IGEgc2Vzc2lvbiB1c2luZyB0aGUgb2xkIGZyYW1pbmcsCnRoZW4gc3dpdGNoIHRvIG5ldyBmcmFt aW5nIGlmIGJvdGggcGVlcnMgYWdyZWUgdG8gdXNlIGJhc2U6MS4xLgoKU3RhcnRpbmcgb3ZlciB3 aXRoIGEgbmV3IHBvcnQgbnVtYmVyIGlzIG5vdCBhbiBvcHRpb24gZm9yIDQ3NDFiaXMuCgoKQW5k eQoKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIlBoaWwgU2hhZmVyIiA8cGhpbEBq dW5pcGVyLm5ldD4KRGF0ZTogV2VkLCBBdWcgMTgsIDIwMTAgMTE6MTcKU3ViamVjdDogW05ldGNv bmZdIGhvdyB0byBoYW5kbGUgWE1MIHBhcnNlIGVycm9ycwpUbzogIkFuZHkgQmllcm1hbiIgPGll dGZAYW5keWJpZXJtYW4uY29tPgpDYzogIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5l dD4sICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+LCAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0Zi5vcmc+CgoKIj0/dXRm LTg/Qj9RVzVrZVNCQ2FXVnliV0Z1Pz0iIHdyaXRlczoKPkkgZGlzYWdyZWUuICBUaGlzIGlzIHZh bGlkIFhNTCBjb250ZW50LCBzbyB0aGUgc2VydmVyIGNhbm5vdCBpZ25vcmUgdGhlIFhNTCBhbmQK Pmp1c3QgbG9vayBmb3Igc29tZSBzdHJpbmcuICBUaGlzIGNvdWxkIGJlIGxlYWYgY29udGVudCBp bnN0ZWFkIG9mIHRoZSBmcmFtZQo+c3RhcnQgbXNnLgoKSSB0aGluayB5b3UndmUgbWlzc2VkIG15 IGNvbnRlbnQgY29tcGxldGVseS4gIE1vc3QgbGlrZWx5IGEKZnJhbWluZyBlcnJvci4gIDteKQoK SW4gbXkgY29kZSwgd2hlbiBJIGdvIHRvIHdyaXRlIGRhdGEgdG8gYW4gc3NoIGNvbm5lY3Rpb24s IEkgY2FuCmVhc2lseSBmaW5kIHRoZSBsZW5ndGggb2YgdGhlIGRhdGEgYW5kIHByZXBlbmQgdGhh dCBkYXRhIHdpdGgKIiNGcmFtZS1sZW5ndGg6ICIsIHRoZSBudW1iZXIgb2YgYnl0ZXMgb2YgZGF0 YSwgYW5kIGEgbmV3bGluZS4gIFdoZW4KSSdtIGF0IHRoZSBlbmQgb2YgdGhlIGRhdGEsIEkgY2Fu IGVhc2lseSBzZW5kIHRoZSBzdHJpbmcgIiNFbmQtb2YtZnJhbWUiCmFuZCBhIG5ld2xpbmUuCgpX aGVuIEknbSByZWFkeSB0byByZWFkIGRhdGEsIEkgY2FuIHJlYWQgYSBsaW5lIG9mIGlubGluZSwg aW5zcGVjdAp0aGF0IGxpbmUgYW5kIHNlZSBpZiBpdCBiZWdpbnMgd2l0aCAiI0ZyYW1lLWxlbmd0 aDogIi4gIElmIGl0IGRvZXMsCnRoZW4gSSBjYW4gbGVhcm4gdGhlIG51bWJlciBvZiBieXRlcyB0 aGF0IGZvbGxvdywgYW5kIHRoZW4gcHJvY2VlZAp0byByZWFkIHRoYXQgbnVtYmVyIG9mIGJ5dGVz LiAgVGhpcyBkYXRhIGNhbiB0aGVuIGJlIHBhc3NlZCB0byBhbgp1cHBlciBsYXllciBhcyBYTUwg ZGF0YSAod2l0aG91dCB0aGUgIiNGcmFtZS4qIiBsaW5lKS4gSWYgdGhlIGxpbmUKaXMgIiNFbmQt b2YtZnJhbWUiLCB0aGVuIEkgY2FuIHRlbGwgdGhlIHVwcGVyIGxheWVyIGFuZCBJJ3ZlIHNlZW4K dGhlIGVuZCBvZiB0aGUgZnJhbWUsIHdoaWNoIHdpbGwgdHJhbnNsYXRlIGludG8gc29tZXRoaW5n IHNpbWlsYXIKdG8gRU9GLgoKVGhlcmUncyBubyBlc2NhcGluZyBvZiBkYXRhLCBubyByZWx5aW5n IG9uIHRoZSBkYXRhIHRvIHByb3ZpZGUKdGhlIGZyYW1pbmcsIGFuZCBubyBpbnRlcmFjdGlvbiBi ZXR3ZWVuIHRoZSBmcmFtaW5nIGFuZCB0aGUKY29udGVudC4KClRoYW5rcywKIFBoaWwKCg== ------=_Part_14_1282159398404 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBkb24mIzM5O3QgdGhpbmsgdGhpcyBtYWpvciBjaGFuZ2UgdG8gdGhlIHNzaCB0cmFuc3BvcnQg aXMgd29ydGggdGhlIGVmZm9ydC48YnI+SSBkb24mIzM5O3QgdGhpbmsgaXQgaXMgYSBnb29kIGlk ZWEgdG8gc3RhcnQgYSBzZXNzaW9uIHVzaW5nIHRoZSBvbGQgZnJhbWluZyw8YnI+dGhlbiBzd2l0 Y2ggdG8gbmV3IGZyYW1pbmcgaWYgYm90aCBwZWVycyBhZ3JlZSB0byB1c2UgYmFzZToxLjEuPGJy Pjxicj5TdGFydGluZyBvdmVyIHdpdGggYSBuZXcgcG9ydCBudW1iZXIgaXMgbm90IGFuIG9wdGlv biBmb3IgNDc0MWJpcy48YnI+PGJyPjxicj5BbmR5PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVz c2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtQaGlsIFNoYWZlciZxdW90OyAmbHQ7cGhpbEBqdW5p cGVyLm5ldCZndDs8YnI+RGF0ZTogV2VkLCBBdWcgMTgsIDIwMTAgMTE6MTc8YnI+U3ViamVjdDog W05ldGNvbmZdIGhvdyB0byBoYW5kbGUgWE1MIHBhcnNlIGVycm9yczxicj5UbzogJnF1b3Q7QW5k eSBCaWVybWFuJnF1b3Q7ICZsdDtpZXRmQGFuZHliaWVybWFuLmNvbSZndDs8YnI+Q2M6ICZxdW90 O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7SnVl cmdlbiBTY2hvZW53YWVsZGVyJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGUmZ3Q7LCAmcXVvdDtuZXRjb25mQGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGll dGYub3JnJmd0Ozxicj48YnI+PGJyPiZxdW90Oz0/dXRmLTg/Qj9RVzVrZVNCQ2FXVnliV0Z1Pz0m cXVvdDsgd3JpdGVzOjxicj4mZ3Q7SSBkaXNhZ3JlZS4gJm5ic3A7VGhpcyBpcyB2YWxpZCBYTUwg Y29udGVudCwgc28gdGhlIHNlcnZlciBjYW5ub3QgaWdub3JlIHRoZSBYTUwgYW5kPGJyPiZndDtq dXN0IGxvb2sgZm9yIHNvbWUgc3RyaW5nLiAmbmJzcDtUaGlzIGNvdWxkIGJlIGxlYWYgY29udGVu dCBpbnN0ZWFkIG9mIHRoZSBmcmFtZTxicj4mZ3Q7c3RhcnQgbXNnLjxicj48YnI+SSB0aGluayB5 b3UmIzM5O3ZlIG1pc3NlZCBteSBjb250ZW50IGNvbXBsZXRlbHkuICZuYnNwO01vc3QgbGlrZWx5 IGE8YnI+ZnJhbWluZyBlcnJvci4gJm5ic3A7O14pPGJyPjxicj5JbiBteSBjb2RlLCB3aGVuIEkg Z28gdG8gd3JpdGUgZGF0YSB0byBhbiBzc2ggY29ubmVjdGlvbiwgSSBjYW48YnI+ZWFzaWx5IGZp bmQgdGhlIGxlbmd0aCBvZiB0aGUgZGF0YSBhbmQgcHJlcGVuZCB0aGF0IGRhdGEgd2l0aDxicj4m cXVvdDsjRnJhbWUtbGVuZ3RoOiAmcXVvdDssIHRoZSBudW1iZXIgb2YgYnl0ZXMgb2YgZGF0YSwg YW5kIGEgbmV3bGluZS4gJm5ic3A7V2hlbjxicj5JJiMzOTttIGF0IHRoZSBlbmQgb2YgdGhlIGRh dGEsIEkgY2FuIGVhc2lseSBzZW5kIHRoZSBzdHJpbmcgJnF1b3Q7I0VuZC1vZi1mcmFtZSZxdW90 Ozxicj5hbmQgYSBuZXdsaW5lLjxicj48YnI+V2hlbiBJJiMzOTttIHJlYWR5IHRvIHJlYWQgZGF0 YSwgSSBjYW4gcmVhZCBhIGxpbmUgb2YgaW5saW5lLCBpbnNwZWN0PGJyPnRoYXQgbGluZSBhbmQg c2VlIGlmIGl0IGJlZ2lucyB3aXRoICZxdW90OyNGcmFtZS1sZW5ndGg6ICZxdW90Oy4gJm5ic3A7 SWYgaXQgZG9lcyw8YnI+dGhlbiBJIGNhbiBsZWFybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHRoYXQg Zm9sbG93LCBhbmQgdGhlbiBwcm9jZWVkPGJyPnRvIHJlYWQgdGhhdCBudW1iZXIgb2YgYnl0ZXMu ICZuYnNwO1RoaXMgZGF0YSBjYW4gdGhlbiBiZSBwYXNzZWQgdG8gYW48YnI+dXBwZXIgbGF5ZXIg YXMgWE1MIGRhdGEgKHdpdGhvdXQgdGhlICZxdW90OyNGcmFtZS4qJnF1b3Q7IGxpbmUpLiBJZiB0 aGUgbGluZTxicj5pcyAmcXVvdDsjRW5kLW9mLWZyYW1lJnF1b3Q7LCB0aGVuIEkgY2FuIHRlbGwg dGhlIHVwcGVyIGxheWVyIGFuZCBJJiMzOTt2ZSBzZWVuPGJyPnRoZSBlbmQgb2YgdGhlIGZyYW1l LCB3aGljaCB3aWxsIHRyYW5zbGF0ZSBpbnRvIHNvbWV0aGluZyBzaW1pbGFyPGJyPnRvIEVPRi48 YnI+PGJyPlRoZXJlJiMzOTtzIG5vIGVzY2FwaW5nIG9mIGRhdGEsIG5vIHJlbHlpbmcgb24gdGhl IGRhdGEgdG8gcHJvdmlkZTxicj50aGUgZnJhbWluZywgYW5kIG5vIGludGVyYWN0aW9uIGJldHdl ZW4gdGhlIGZyYW1pbmcgYW5kIHRoZTxicj5jb250ZW50Ljxicj48YnI+VGhhbmtzLDxicj4gUGhp bDxicj48YnI+PGJyPjxicj4= ------=_Part_14_1282159398404-- From ietf@andybierman.com Wed Aug 18 12:27:22 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28A83A6A85 for ; Wed, 18 Aug 2010 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+RVx8FCjatN for ; Wed, 18 Aug 2010 12:27:21 -0700 (PDT) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by core3.amsl.com (Postfix) with ESMTP id 9E4E23A6A81 for ; Wed, 18 Aug 2010 12:27:20 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7IJRtl0027688 for ; Wed, 18 Aug 2010 15:27:55 -0400 Authentication-Results: cm-omr3 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [108.112.111.30] ([108.112.111.30:45875] helo=[108.112.111.30]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 0C/F2-27074-9343C6C4; Wed, 18 Aug 2010 15:27:55 -0400 To: "=?utf-8?B?QW5keSBCaWVybWFu?=" , "=?utf-8?B?UGhpbCBTaGFmZXI=?=" Message-ID: <0C.F2.27074.9343C6C4@cm-omr3> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 18 Aug 2010 12:28:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15_1282159689203" Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:27:22 -0000 ------=_Part_15_1282159689203 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Rm9yIHNlcnZlcnMgdGhhdCBzdHJlYW0gdGhlIHJlcGxpZXMgaW5zdGVhZCBvZiBidWZmZXJpbmcs IGtub3dpbmcgdGhlIHJlcGx5IGxlbmd0aCBhdCB0aGUgc3RhcnQgb2YgdGhlIG1lc3NhZ2UgaXMg bm90IHBvc3NpYmxlLgoKQW5keQoKLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLQpGcm9tOiAiQW5k eSBCaWVybWFuIiA8aWV0ZkBhbmR5Ymllcm1hbi5jb20+CkRhdGU6IFdlZCwgQXVnIDE4LCAyMDEw IDEyOjIzClN1YmplY3Q6IFtOZXRjb25mXSBob3cgdG8gaGFuZGxlIFhNTCBwYXJzZSBlcnJvcnMK VG86ICJQaGlsIFNoYWZlciIgPHBoaWxAanVuaXBlci5uZXQ+CkNjOiAibmV0Y29uZkBpZXRmLm9y ZyIgPG5ldGNvbmZAaWV0Zi5vcmc+CgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCg== ------=_Part_15_1282159689203 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline Rm9yIHNlcnZlcnMgdGhhdCBzdHJlYW0gdGhlIHJlcGxpZXMgaW5zdGVhZCBvZiBidWZmZXJpbmcs IGtub3dpbmcgdGhlIHJlcGx5IGxlbmd0aCBhdCB0aGUgc3RhcnQgb2YgdGhlIG1lc3NhZ2UgaXMg bm90IHBvc3NpYmxlLjxicj48YnI+QW5keTxicj48YnI+PGRpdiBpZD0iaHRjX2hlYWRlciIgc3R5 bGU9IiI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtBbmR5IEJpZXJt YW4mcXVvdDsgJmx0O2lldGZAYW5keWJpZXJtYW4uY29tJmd0Ozxicj5EYXRlOiBXZWQsIEF1ZyAx OCwgMjAxMCAxMjoyMzxicj5TdWJqZWN0OiBbTmV0Y29uZl0gaG93IHRvIGhhbmRsZSBYTUwgcGFy c2UgZXJyb3JzPGJyPlRvOiAmcXVvdDtQaGlsIFNoYWZlciZxdW90OyAmbHQ7cGhpbEBqdW5pcGVy Lm5ldCZndDs8YnI+Q2M6ICZxdW90O25ldGNvbmZAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldGNvbmZA aWV0Zi5vcmcmZ3Q7PGJyPjxicj48YnI+PC9kaXY+SSBkb24mIzM5O3QgdGhpbmsgdGhpcyBtYWpv ciBjaGFuZ2UgdG8gdGhlIHNzaCB0cmFuc3BvcnQgaXMgd29ydGggdGhlIGVmZm9ydC48YnI+SSBk b24mIzM5O3QgdGhpbmsgaXQgaXMgYSBnb29kIGlkZWEgdG8gc3RhcnQgYSBzZXNzaW9uIHVzaW5n IHRoZSBvbGQgZnJhbWluZyw8YnI+dGhlbiBzd2l0Y2ggdG8gbmV3IGZyYW1pbmcgaWYgYm90aCBw ZWVycyBhZ3JlZSB0byB1c2UgYmFzZToxLjEuPGJyPjxicj5TdGFydGluZyBvdmVyIHdpdGggYSBu ZXcgcG9ydCBudW1iZXIgaXMgbm90IGFuIG9wdGlvbiBmb3IgNDc0MWJpcy48YnI+PGJyPjxicj5B bmR5PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVvdDtQ aGlsIFNoYWZlciZxdW90OyAmbHQ7cGhpbEBqdW5pcGVyLm5ldCZndDs8YnI+RGF0ZTogV2VkLCBB dWcgMTgsIDIwMTAgMTE6MTc8YnI+U3ViamVjdDogW05ldGNvbmZdIGhvdyB0byBoYW5kbGUgWE1M IHBhcnNlIGVycm9yczxicj5UbzogJnF1b3Q7QW5keSBCaWVybWFuJnF1b3Q7ICZsdDtpZXRmQGFu ZHliaWVybWFuLmNvbSZndDs8YnI+Q2M6ICZxdW90O0tlbnQgV2F0c2VuJnF1b3Q7ICZsdDtrd2F0 c2VuQGp1bmlwZXIubmV0Jmd0OywgJnF1b3Q7SnVlcmdlbiBTY2hvZW53YWVsZGVyJnF1b3Q7ICZs dDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7LCAmcXVvdDtuZXRjb25m QGlldGYub3JnJnF1b3Q7ICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxicj48YnI+PGJyPiZxdW90 Oz0/dXRmLTg/Qj9RVzVrZVNCQ2FXVnliV0Z1Pz0mcXVvdDsgd3JpdGVzOjxicj4mZ3Q7SSBkaXNh Z3JlZS4gJm5ic3A7VGhpcyBpcyB2YWxpZCBYTUwgY29udGVudCwgc28gdGhlIHNlcnZlciBjYW5u b3QgaWdub3JlIHRoZSBYTUwgYW5kPGJyPiZndDtqdXN0IGxvb2sgZm9yIHNvbWUgc3RyaW5nLiAm bmJzcDtUaGlzIGNvdWxkIGJlIGxlYWYgY29udGVudCBpbnN0ZWFkIG9mIHRoZSBmcmFtZTxicj4m Z3Q7c3RhcnQgbXNnLjxicj48YnI+SSB0aGluayB5b3UmIzM5O3ZlIG1pc3NlZCBteSBjb250ZW50 IGNvbXBsZXRlbHkuICZuYnNwO01vc3QgbGlrZWx5IGE8YnI+ZnJhbWluZyBlcnJvci4gJm5ic3A7 O14pPGJyPjxicj5JbiBteSBjb2RlLCB3aGVuIEkgZ28gdG8gd3JpdGUgZGF0YSB0byBhbiBzc2gg Y29ubmVjdGlvbiwgSSBjYW48YnI+ZWFzaWx5IGZpbmQgdGhlIGxlbmd0aCBvZiB0aGUgZGF0YSBh bmQgcHJlcGVuZCB0aGF0IGRhdGEgd2l0aDxicj4mcXVvdDsjRnJhbWUtbGVuZ3RoOiAmcXVvdDss IHRoZSBudW1iZXIgb2YgYnl0ZXMgb2YgZGF0YSwgYW5kIGEgbmV3bGluZS4gJm5ic3A7V2hlbjxi cj5JJiMzOTttIGF0IHRoZSBlbmQgb2YgdGhlIGRhdGEsIEkgY2FuIGVhc2lseSBzZW5kIHRoZSBz dHJpbmcgJnF1b3Q7I0VuZC1vZi1mcmFtZSZxdW90Ozxicj5hbmQgYSBuZXdsaW5lLjxicj48YnI+ V2hlbiBJJiMzOTttIHJlYWR5IHRvIHJlYWQgZGF0YSwgSSBjYW4gcmVhZCBhIGxpbmUgb2YgaW5s aW5lLCBpbnNwZWN0PGJyPnRoYXQgbGluZSBhbmQgc2VlIGlmIGl0IGJlZ2lucyB3aXRoICZxdW90 OyNGcmFtZS1sZW5ndGg6ICZxdW90Oy4gJm5ic3A7SWYgaXQgZG9lcyw8YnI+dGhlbiBJIGNhbiBs ZWFybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHRoYXQgZm9sbG93LCBhbmQgdGhlbiBwcm9jZWVkPGJy PnRvIHJlYWQgdGhhdCBudW1iZXIgb2YgYnl0ZXMuICZuYnNwO1RoaXMgZGF0YSBjYW4gdGhlbiBi ZSBwYXNzZWQgdG8gYW48YnI+dXBwZXIgbGF5ZXIgYXMgWE1MIGRhdGEgKHdpdGhvdXQgdGhlICZx dW90OyNGcmFtZS4qJnF1b3Q7IGxpbmUpLiBJZiB0aGUgbGluZTxicj5pcyAmcXVvdDsjRW5kLW9m LWZyYW1lJnF1b3Q7LCB0aGVuIEkgY2FuIHRlbGwgdGhlIHVwcGVyIGxheWVyIGFuZCBJJiMzOTt2 ZSBzZWVuPGJyPnRoZSBlbmQgb2YgdGhlIGZyYW1lLCB3aGljaCB3aWxsIHRyYW5zbGF0ZSBpbnRv IHNvbWV0aGluZyBzaW1pbGFyPGJyPnRvIEVPRi48YnI+PGJyPlRoZXJlJiMzOTtzIG5vIGVzY2Fw aW5nIG9mIGRhdGEsIG5vIHJlbHlpbmcgb24gdGhlIGRhdGEgdG8gcHJvdmlkZTxicj50aGUgZnJh bWluZywgYW5kIG5vIGludGVyYWN0aW9uIGJldHdlZW4gdGhlIGZyYW1pbmcgYW5kIHRoZTxicj5j b250ZW50Ljxicj48YnI+VGhhbmtzLDxicj4gUGhpbDxicj48YnI+PGJyPjxicj4= ------=_Part_15_1282159689203-- From mbj@tail-f.com Thu Aug 19 00:06:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A431F3A68B9 for ; Thu, 19 Aug 2010 00:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suOmKCZleTol for ; Thu, 19 Aug 2010 00:06:35 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8C3533A68A9 for ; Thu, 19 Aug 2010 00:06:35 -0700 (PDT) Received: from localhost (c213-100-166-156.swipnet.se [213.100.166.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 0335B616005; Thu, 19 Aug 2010 09:07:08 +0200 (CEST) Date: Thu, 19 Aug 2010 09:07:07 +0200 (CEST) Message-Id: <20100819.090707.257030650.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> References: <20100817212620.GA29487@elstar.local> <201008181453.o7IEribS060278@idle.juniper.net> <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:06:36 -0000 Kent Watsen wrote: > > Phil Shafer writes: > > Any chance we can address the framing issue? It would be nice to > > have something real, workable, and robust here. > > > Isn't framing fundamentally supported by matching XML tags? ]]>]]> is only > there to support recovery, it's not intended to support framing - right? Logically, the transport layer is responsible for sending the contents of each "transport frame" to the message layer. With SSH, this content is whatever data is found between the ]]>]]> markers. The message layer takes this content and parses it as one XML document. If this parsing fails, the content is invalid. It is not clear from 4741 what the server should do if the message is invalid. If you just read 4741, you might think that the only option is to close the session, since there is no way to send an rpc-error back unless an was received. On the other hand, if you also read 4742, it talks about resynchronization in the event of an XML syntax or parsing error. If we want to change this now, we must also change 4742bis. But the ]]>]]> is used for this specific purpose, so if we change this, should we also remove ]]>]]>? After thinking some more about this, I would actually prefer to not change 4742, and update 4741 to say: If a server receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. FWIW, I have checked three existing implementations, and they all generate an rpc-error and continue with the session. /martin From j.schoenwaelder@jacobs-university.de Thu Aug 19 01:04:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647503A68C0 for ; Thu, 19 Aug 2010 01:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.786 X-Spam-Level: X-Spam-Status: No, score=-101.786 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAUvVux9p8k8 for ; Thu, 19 Aug 2010 01:04:39 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 43B503A67E1 for ; Thu, 19 Aug 2010 01:04:39 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE72CC0015; Thu, 19 Aug 2010 10:05:13 +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 cuJtEHmH+-L4; Thu, 19 Aug 2010 10:05:12 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 366ABC000D; Thu, 19 Aug 2010 10:05:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4209F144F6CD; Thu, 19 Aug 2010 10:04:57 +0200 (CEST) Date: Thu, 19 Aug 2010 10:04:56 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100819080455.GB2244@elstar.local> Mail-Followup-To: Martin Bjorklund , "kwatsen@juniper.net" , "phil@juniper.net" , "netconf@ietf.org" References: <20100817212620.GA29487@elstar.local> <201008181453.o7IEribS060278@idle.juniper.net> <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> <20100819.090707.257030650.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100819.090707.257030650.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:04:40 -0000 On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > After thinking some more about this, I would actually prefer to not > change 4742, and update 4741 to say: > > If a server receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. > > FWIW, I have checked three existing implementations, and they all > generate an rpc-error and continue with the session. Not all messages received by a server are messages. So what about this: > If a server receives an message that is not well-formed XML, > it MUST reply with an 'operation-failed' error. It surely would be nice to have a more precise error for this since operation-failed is a catch-all error and does not really indicate that the XML was malformed. I have not tested it, but I would not be surprised if different implementations return different errors. I agree with I think Randy that the framing and resynchronization is a transport issue and not a 4741 issue. If the framing does not allow reliable resynchronization to the next frame, then the transport I think should mandate to close the session. The question then still remains whether 4742 provides reliable framing (or should it be reliable enough framing). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 19 02:20:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99EC53A68E6 for ; Thu, 19 Aug 2010 02:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl9pjbo5cDiE for ; Thu, 19 Aug 2010 02:20:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 513273A63EC for ; Thu, 19 Aug 2010 02:20:07 -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 D0DFF616005; Thu, 19 Aug 2010 11:20:41 +0200 (CEST) Date: Thu, 19 Aug 2010 11:20:41 +0200 (CEST) Message-Id: <20100819.112041.216336369.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100819080455.GB2244@elstar.local> References: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> <20100819.090707.257030650.mbj@tail-f.com> <20100819080455.GB2244@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:20:09 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > > > After thinking some more about this, I would actually prefer to not > > change 4742, and update 4741 to say: > > > > If a server receives a message that is not well-formed XML, it MUST > > reply with an 'operation-failed' error. > > > > FWIW, I have checked three existing implementations, and they all > > generate an rpc-error and continue with the session. > > Not all messages received by a server are messages. So what > about this: > > > If a server receives an message that is not well-formed XML, > > it MUST reply with an 'operation-failed' error. What do you want the server to do with other (illegal) messages then? > It surely would be nice to have a more precise error for this since > operation-failed is a catch-all error and does not really indicate > that the XML was malformed. I have not tested it, but I would not be > surprised if different implementations return different errors. > > I agree with I think Randy that the framing and resynchronization is a > transport issue and not a 4741 issue. If the framing does not allow > reliable resynchronization to the next frame, then the transport I > think should mandate to close the session. The question then still > remains whether 4742 provides reliable framing (or should it be > reliable enough framing). IMO it is reliable enough. It is of course very primitive - scan for ]]>]]>, and when found, send the data to the higher layer. The only problem is well-known - the EOM marker can be part of a legal XML document. But we have discussed this before, and I do not want to change this now. /martin From j.schoenwaelder@jacobs-university.de Thu Aug 19 03:51:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B8A3A69FB for ; Thu, 19 Aug 2010 03:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.793 X-Spam-Level: X-Spam-Status: No, score=-101.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfhtDeeaeTuu for ; Thu, 19 Aug 2010 03:51:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6B34E3A69C5 for ; Thu, 19 Aug 2010 03:51:05 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1618BC000D; Thu, 19 Aug 2010 12:51:40 +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 mctgVQBs7PgK; Thu, 19 Aug 2010 12:51:38 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 70776C0007; Thu, 19 Aug 2010 12:51:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 969CD144FB95; Thu, 19 Aug 2010 12:51:23 +0200 (CEST) Date: Thu, 19 Aug 2010 12:51:22 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100819105122.GA2648@elstar.local> Mail-Followup-To: Martin Bjorklund , "kwatsen@juniper.net" , "phil@juniper.net" , "netconf@ietf.org" References: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> <20100819.090707.257030650.mbj@tail-f.com> <20100819080455.GB2244@elstar.local> <20100819.112041.216336369.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100819.112041.216336369.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:51:06 -0000 On Thu, Aug 19, 2010 at 11:20:41AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > > > > > After thinking some more about this, I would actually prefer to not > > > change 4742, and update 4741 to say: > > > > > > If a server receives a message that is not well-formed XML, it MUST > > > reply with an 'operation-failed' error. > > > > > > FWIW, I have checked three existing implementations, and they all > > > generate an rpc-error and continue with the session. > > > > Not all messages received by a server are messages. So what > > about this: > > > > > If a server receives an message that is not well-formed XML, > > > it MUST reply with an 'operation-failed' error. > > What do you want the server to do with other (illegal) messages then? What is illegal? I can send a mal-formed . Other specifications might add additional messages, like the message was added to the stream of server -> client messages. > IMO it is reliable enough. It is of course very primitive - scan for > ]]>]]>, and when found, send the data to the higher layer. The only > problem is well-known - the EOM marker can be part of a legal XML > document. But we have discussed this before, and I do not want to > change this now. So a well-known problem is not a problem anymore... ;-) /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@cesnet.cz Thu Aug 19 03:58:03 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7EC3A6784 for ; Thu, 19 Aug 2010 03:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W29JPtrEby1 for ; Thu, 19 Aug 2010 03:58:03 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id F28CA3A6814 for ; Thu, 19 Aug 2010 03:58:02 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id A2FEB3E038D; Thu, 19 Aug 2010 12:58:17 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20100819.112041.216336369.mbj@tail-f.com> References: <84600D05C20FF943918238042D7670FD36D721E667@EMBX01-HQ.jnpr.net> <20100819.090707.257030650.mbj@tail-f.com> <20100819080455.GB2244@elstar.local> <20100819.112041.216336369.mbj@tail-f.com> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Thu, 19 Aug 2010 12:58:34 +0200 Message-ID: <8739uadg2t.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:58:04 -0000 On Thu, 19 Aug 2010 11:20:41 +0200 (CEST), Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > > > > > After thinking some more about this, I would actually prefer to not > > > change 4742, and update 4741 to say: > > > > > > If a server receives a message that is not well-formed XML, it MUST > > > reply with an 'operation-failed' error. > > > > > > FWIW, I have checked three existing implementations, and they all > > > generate an rpc-error and continue with the session. > > > > Not all messages received by a server are messages. So what > > about this: > > > > > If a server receives an message that is not well-formed XML, > > > it MUST reply with an 'operation-failed' error. > > What do you want the server to do with other (illegal) messages then? There may not be any message to refer to - it could be complete rubbish, so IMO it would be better to return a special error ("parse error", "malformed frame" or similar), without any message-id. Lada > > > It surely would be nice to have a more precise error for this since > > operation-failed is a catch-all error and does not really indicate > > that the XML was malformed. I have not tested it, but I would not be > > surprised if different implementations return different errors. > > > > I agree with I think Randy that the framing and resynchronization is a > > transport issue and not a 4741 issue. If the framing does not allow > > reliable resynchronization to the next frame, then the transport I > > think should mandate to close the session. The question then still > > remains whether 4742 provides reliable framing (or should it be > > reliable enough framing). > > IMO it is reliable enough. It is of course very primitive - scan for > ]]>]]>, and when found, send the data to the higher layer. The only > problem is well-known - the EOM marker can be part of a legal XML > document. But we have discussed this before, and I do not want to > change this now. > > > /martin > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From mbj@tail-f.com Thu Aug 19 04:08:09 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9123A68F1 for ; Thu, 19 Aug 2010 04:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIhr7+QtMjBj for ; Thu, 19 Aug 2010 04:08:08 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 1D9863A6885 for ; Thu, 19 Aug 2010 04:08:08 -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 2D5EB616005; Thu, 19 Aug 2010 13:08:42 +0200 (CEST) Date: Thu, 19 Aug 2010 13:08:41 +0200 (CEST) Message-Id: <20100819.130841.23364834.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <8739uadg2t.fsf@cesnet.cz> References: <20100819080455.GB2244@elstar.local> <20100819.112041.216336369.mbj@tail-f.com> <8739uadg2t.fsf@cesnet.cz> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:08:09 -0000 Ladislav Lhotka wrote: > On Thu, 19 Aug 2010 11:20:41 +0200 (CEST), Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > > > > > > > After thinking some more about this, I would actually prefer to not > > > > change 4742, and update 4741 to say: > > > > > > > > If a server receives a message that is not well-formed XML, it MUST > > > > reply with an 'operation-failed' error. > > > > > > > > FWIW, I have checked three existing implementations, and they all > > > > generate an rpc-error and continue with the session. > > > > > > Not all messages received by a server are messages. So what > > > about this: > > > > > > > If a server receives an message that is not well-formed XML, > > > > it MUST reply with an 'operation-failed' error. > > > > What do you want the server to do with other (illegal) messages then? > > There may not be any message to refer to - it could be complete > rubbish Right. Except for the error tag, do you approve the proposed text: If a server receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. /martin From lhotka@cesnet.cz Thu Aug 19 04:34:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4DDE3A68DB for ; Thu, 19 Aug 2010 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaSet4XEs4aM for ; Thu, 19 Aug 2010 04:34:26 -0700 (PDT) Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz [195.113.161.162]) by core3.amsl.com (Postfix) with ESMTP id E785B3A6879 for ; Thu, 19 Aug 2010 04:34:21 -0700 (PDT) Received: from localhost (missotis.lhotkovi.cz [172.29.2.201]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 50C533E038D; Thu, 19 Aug 2010 13:34:32 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund In-Reply-To: <20100819.130841.23364834.mbj@tail-f.com> References: <20100819080455.GB2244@elstar.local> <20100819.112041.216336369.mbj@tail-f.com> <8739uadg2t.fsf@cesnet.cz> <20100819.130841.23364834.mbj@tail-f.com> User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1 (i486-pc-linux-gnu) Date: Thu, 19 Aug 2010 13:34:49 +0200 Message-ID: <87zkwibzty.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf@ietf.org Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:34:37 -0000 On Thu, 19 Aug 2010 13:08:41 +0200 (CEST), Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > On Thu, 19 Aug 2010 11:20:41 +0200 (CEST), Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Thu, Aug 19, 2010 at 09:07:07AM +0200, Martin Bjorklund wrote: > > > > > > > > > After thinking some more about this, I would actually prefer to not > > > > > change 4742, and update 4741 to say: > > > > > > > > > > If a server receives a message that is not well-formed XML, it MUST > > > > > reply with an 'operation-failed' error. > > > > > > > > > > FWIW, I have checked three existing implementations, and they all > > > > > generate an rpc-error and continue with the session. > > > > > > > > Not all messages received by a server are messages. So what > > > > about this: > > > > > > > > > If a server receives an message that is not well-formed XML, > > > > > it MUST reply with an 'operation-failed' error. > > > > > > What do you want the server to do with other (illegal) messages then? > > > > There may not be any message to refer to - it could be complete > > rubbish > > Right. Except for the error tag, do you approve the proposed text: > > If a server receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. My understanding is that "message" is a well-formed document in the Message layer. On the other hand, the term "frame" is not used in 4741bis, so I don't know. BTW, what happens if the client continues feeding data and never sends "]]>]]>"? Shouldn't there be some maximum frame length? Lada > > > /martin > -- Ladislav Lhotka, CESNET PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Thu Aug 19 04:53:01 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECF33A67A7 for ; Thu, 19 Aug 2010 04:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC-5EXDXr3fb for ; Thu, 19 Aug 2010 04:53:00 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A95093A67CF for ; Thu, 19 Aug 2010 04:52:59 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4FFF1C0017; Thu, 19 Aug 2010 13:53:34 +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 7zducdG4ucbm; Thu, 19 Aug 2010 13:53:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C18CC000D; Thu, 19 Aug 2010 13:53:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 49A5F144FD88; Thu, 19 Aug 2010 13:53:18 +0200 (CEST) Date: Thu, 19 Aug 2010 13:53:18 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20100819115318.GB2648@elstar.local> Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , "netconf@ietf.org" References: <20100819080455.GB2244@elstar.local> <20100819.112041.216336369.mbj@tail-f.com> <8739uadg2t.fsf@cesnet.cz> <20100819.130841.23364834.mbj@tail-f.com> <87zkwibzty.fsf@cesnet.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zkwibzty.fsf@cesnet.cz> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:53:01 -0000 On Thu, Aug 19, 2010 at 01:34:49PM +0200, Ladislav Lhotka wrote: > My understanding is that "message" is a well-formed document in > the Message layer. On the other hand, the term "frame" is not used in > 4741bis, so I don't know. Quoting 4741bis: Layer Example +-------------+ +-----------------+ +----------------+ (4) | Content | | Configuration | | Notification | | | | data | | data | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------+ | (3) | Operations | | | | | | | | | +-------------+ +-----------------+ | | | | +-------------+ +-----------------+ +----------------+ (2) | Messages | | , | | | | | | | | | +-------------+ +-----------------+ +----------------+ | | | +-------------+ +-----------------------------------------+ (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | | Transports | | | +-------------+ +-----------------------------------------+ > BTW, what happens if the client continues feeding data and never sends > "]]>]]>"? Shouldn't there be some maximum frame length? There is a too-big error: error-tag: too-big error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle. I assume request means message and response means message. So if you send a too big or , the behaviour will be implementation dependent (the notification will likely be dropped and a server likely reacts with closing the session on an insane hello). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 19 04:54:39 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEBE3A6937 for ; Thu, 19 Aug 2010 04:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2w0LwMALrg2m for ; Thu, 19 Aug 2010 04:54:38 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 019533A6A09 for ; Thu, 19 Aug 2010 04:54:37 -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 8295E616005; Thu, 19 Aug 2010 13:55:12 +0200 (CEST) Date: Thu, 19 Aug 2010 13:55:12 +0200 (CEST) Message-Id: <20100819.135512.93132008.mbj@tail-f.com> To: lhotka@cesnet.cz From: Martin Bjorklund In-Reply-To: <87zkwibzty.fsf@cesnet.cz> References: <8739uadg2t.fsf@cesnet.cz> <20100819.130841.23364834.mbj@tail-f.com> <87zkwibzty.fsf@cesnet.cz> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 11:54:39 -0000 Ladislav Lhotka wrote: > My understanding is that "message" is a well-formed document in > the Message layer. Sorry, here's the complete change: OLD: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. NEW: All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If a peer receives a message that is not well-formed XML, it MUST reply with an 'operation-failed' error. > BTW, what happens if the client continues feeding data and never sends > "]]>]]>"? Shouldn't there be some maximum frame length? The max frame length has to be implemenation specific. There is already a 'too-big' error tag to handle this case. /martin From j.schoenwaelder@jacobs-university.de Thu Aug 19 05:39:47 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6963A68E7 for ; Thu, 19 Aug 2010 05:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.808 X-Spam-Level: X-Spam-Status: No, score=-101.808 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eup7oxbqSQN9 for ; Thu, 19 Aug 2010 05:39:46 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 46A383A68E1 for ; Thu, 19 Aug 2010 05:39:46 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 873CAC0018; Thu, 19 Aug 2010 14:40:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2TRhCVHxhQKD; Thu, 19 Aug 2010 14:40:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 66F48C000D; Thu, 19 Aug 2010 14:40:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 58CDA145006A; Thu, 19 Aug 2010 14:40:05 +0200 (CEST) Date: Thu, 19 Aug 2010 14:40:05 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20100819124005.GA2859@elstar.local> Mail-Followup-To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <8739uadg2t.fsf@cesnet.cz> <20100819.130841.23364834.mbj@tail-f.com> <87zkwibzty.fsf@cesnet.cz> <20100819.135512.93132008.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100819.135512.93132008.mbj@tail-f.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:39:47 -0000 On Thu, Aug 19, 2010 at 01:55:12PM +0200, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > My understanding is that "message" is a well-formed document in > > the Message layer. > > Sorry, here's the complete change: > > OLD: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. > > NEW: > > All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If > a peer receives a message that is not well-formed XML, it MUST > reply with an 'operation-failed' error. Sorry, how do I reply to a or message with an 'operation-failed' error? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Thu Aug 19 06:20:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 741393A685C for ; Thu, 19 Aug 2010 06:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8t3WLkU8eQc for ; Thu, 19 Aug 2010 06:20:35 -0700 (PDT) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id 6A63F3A6910 for ; Thu, 19 Aug 2010 06:20:35 -0700 (PDT) Received: (qmail 40532 invoked from network); 19 Aug 2010 13:21:08 -0000 Received: from [192.168.0.10] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 19 Aug 2010 06:21:08 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: wcXuI58VM1mmwKleYjGDoYEq5h_Vb65.pEReUmC6_K8GtCB zpJO9TpQRfT6J2scN7mJmj8ribTG09OGIV1oh.DtVOK8R1DDkmpg2TwRi859 x8KCkC9eAIsPOc8e1xVc5Y.xT8In0igZyNlVV6D1BzdGVibrZRT9fWGtTw3w l.mEx0fSM8RSMjqYGnl5QlrD7q4ON91gBh_baKK_ooATYwy0IF5tCAUlDt_R TNkMw7aqXG0pN9i.9CCJyW715KDauCER32avG_CzT4mIJP2gskp4BgO73.31 b1oTbCxDjXfS_W0MEiHgteNild948LOGrvqS8Fg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6D2FC4.3060801@andybierman.com> Date: Thu, 19 Aug 2010 06:21:08 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Martin Bjorklund , "lhotka@cesnet.cz" , "netconf@ietf.org" References: <8739uadg2t.fsf@cesnet.cz> <20100819.130841.23364834.mbj@tail-f.com> <87zkwibzty.fsf@cesnet.cz> <20100819.135512.93132008.mbj@tail-f.com> <20100819124005.GA2859@elstar.local> In-Reply-To: <20100819124005.GA2859@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:20:36 -0000 On 08/19/2010 05:40 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 19, 2010 at 01:55:12PM +0200, Martin Bjorklund wrote: >> Ladislav Lhotka wrote: >>> My understanding is that "message" is a well-formed document in >>> the Message layer. >> >> Sorry, here's the complete change: >> >> OLD: >> >> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. >> >> NEW: >> >> All NETCONF messages MUST be well-formed XML, encoded in UTF-8. If >> a peer receives a message that is not well-formed XML, it MUST >> reply with an 'operation-failed' error. > > Sorry, how do I reply to a or message with an > 'operation-failed' error? > The session should be dropped. received in the wrong state: /* only process this message in hello wait state */ if (scb->state != SES_ST_HELLO_WAIT) { if (LOGINFO) { log_info("\nagt_hello dropped, wrong state " "(%d) for session %d", scb->state, scb->sid); } mytotals->inBadHellos++; agt_ses_request_close(scb->sid, scb->sid, SES_TR_BAD_HELLO); return; } Yuma logs a message, bumps a counter, and drops the session. A sysSessionEnd notification will also go out with an error code such as 'bad-hello'. The same sort of thing is done if the 'top' element is not registered so it is unknown. Unless there is an received,there won't be an . Mandating exact errors is all very nice, but they are only for . > /js > Andy From phil@juniper.net Thu Aug 19 08:44:11 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6DC3A68B6 for ; Thu, 19 Aug 2010 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.744 X-Spam-Level: X-Spam-Status: No, score=-6.744 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgjsIUtfBNsL for ; Thu, 19 Aug 2010 08:44:10 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by core3.amsl.com (Postfix) with ESMTP id 5790E3A6958 for ; Thu, 19 Aug 2010 08:44:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKTG1RXm87lvI6xwU+iDlJVMSRFiDQbVTl@postini.com; Thu, 19 Aug 2010 08:44:45 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.2.254.0; Thu, 19 Aug 2010 08:42:53 -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 o7JFgqU84360; Thu, 19 Aug 2010 08:42:52 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7JFO0Sd081782; Thu, 19 Aug 2010 15:24:00 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008191524.o7JFO0Sd081782@idle.juniper.net> To: =?utf-8?B?QW5keSBCaWVybWFu?= In-Reply-To: <0C.F2.27074.9343C6C4@cm-omr3> Date: Thu, 19 Aug 2010 11:24:00 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: =?utf-8?B?bmV0Y29uZkBpZXRmLm9yZw==?= Subject: Re: [Netconf] =?utf-8?q?how_to_handle_XML_parse_errors?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 15:44:11 -0000 "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >For servers that stream the replies instead of buffering, knowing the reply >length at the start of the message is not possible. If you could reread my proposal, you'll notice that one can use multiple "Frame-length" headers in a single message, allowing what HTTP affectionately calls "chunking". The server reads a chunk, writes that chunk, and repeats until it's ready to send the "#End-of-frame" message. Thanks, Phil From ietf@andybierman.com Thu Aug 19 09:17:41 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8783A695D for ; Thu, 19 Aug 2010 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+JsTR10mepF for ; Thu, 19 Aug 2010 09:17:40 -0700 (PDT) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 3C7CB3A6889 for ; Thu, 19 Aug 2010 09:17:40 -0700 (PDT) Received: (qmail 20626 invoked from network); 19 Aug 2010 16:18:12 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 19 Aug 2010 09:18:12 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: kvoEDiUVM1mAPge.iDbzSGnnBd64bdN4q6y33eNqkFHMYc2 Y7hFabSWsXR9JsnBL6LQzxiVTiD0XZgLXT5ghhcvnJFvqq.s0fyJBCun5qoi JD2LkRwrK_2Moy_MnZ1TPS8xV0JrTCX997k3.iCS3QHxV8intsmf92JIiRsl .H.PJjz8rkbJXm_Hg5ShOM2hFxT7ISSEf7cCk0C2eCd24hHvJpJYtu3B40Q_ hYRK53WoWg0v6JGlF7H3DP9_N9_2b X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C6D5941.1000804@andybierman.com> Date: Thu, 19 Aug 2010 09:18:09 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Phil Shafer References: <201008191524.o7JFO0Sd081782@idle.juniper.net> In-Reply-To: <201008191524.o7JFO0Sd081782@idle.juniper.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:17:41 -0000 On 08/19/2010 08:24 AM, Phil Shafer wrote: > "=?utf-8?B?QW5keSBCaWVybWFu?=" writes: >> For servers that stream the replies instead of buffering, knowing the reply >> length at the start of the message is not possible. > > If you could reread my proposal, you'll notice that one can use > multiple "Frame-length" headers in a single message, allowing what > HTTP affectionately calls "chunking". The server reads a chunk, > writes that chunk, and repeats until it's ready to send the > "#End-of-frame" message. > I don't think is worth changing. This is a major non-backward compatible change. NETCONF 1.1 is a minor bugfix, something you remind us of quite often. Making a major change like this because in theory there could be lots of buggy manager applications blindly injecting XML into NETCONF messages is not very compelling to me. I don't believe there are any such NETCONF manager applications out there to worry about. The issue we are resolving is whether the server should follow specific error handling procedures in base:1.1, because in base:1.0 they are unspecified and left to the server implementor to decide. IMO, we do not have any consensus to make a change so we should leave 4741bis unspecified (up to the server). > Thanks, > Phil > > Andy From wjhns1@hardakers.net Thu Aug 19 09:42:56 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0C83A693D for ; Thu, 19 Aug 2010 09:42:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRC3UhQOfM1m for ; Thu, 19 Aug 2010 09:42:55 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 988333A6840 for ; Thu, 19 Aug 2010 09:42:55 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 1885E98066; Thu, 19 Aug 2010 09:43:30 -0700 (PDT) From: Wes Hardaker To: Ladislav Lhotka Organization: Sparta References: <20100812.145524.70210866.mbj@tail-f.com> <4C65A665.8030304@andybierman.com> <4C682CA6.2040703@andybierman.com> <84600D05C20FF943918238042D7670FD36D70880AA@EMBX01-HQ.jnpr.net> <8762z9z1pi.fsf@cesnet.cz> <878w43994r.fsf@cesnet.cz> Date: Thu, 19 Aug 2010 09:43:29 -0700 In-Reply-To: <878w43994r.fsf@cesnet.cz> (Ladislav Lhotka's message of "Wed, 18 Aug 2010 18:29:56 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "netconf@ietf.org" Subject: Re: [Netconf] how to handle XML parse errors X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:42:56 -0000 >>>>> On Wed, 18 Aug 2010 18:29:56 +0200, Ladislav Lhotka said: LL> While we both agree that the server should close the session upon LL> receiving a malformed message I think that's all we *need* to agree on, so I'll stop my side of the argument :-) -- Wes Hardaker Cobham Analytic Solutions From root@core3.amsl.com Mon Aug 23 10:00:02 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F01A23A68F8; Mon, 23 Aug 2010 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100823170001.F01A23A68F8@core3.amsl.com> Date: Mon, 23 Aug 2010 10:00:01 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-4741bis-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : Network Configuration Protocol (NETCONF) Author(s) : R. Enns, et al. Filename : draft-ietf-netconf-4741bis-04.txt Pages : 121 Date : 2010-08-23 The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as Remote Procedure Calls (RPC). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-4741bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-4741bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-23094635.I-D@ietf.org> --NextPart-- From dromasca@avaya.com Wed Aug 25 00:58:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25D43A693D for ; Wed, 25 Aug 2010 00:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjDEvmQjmuBZ for ; Wed, 25 Aug 2010 00:58:52 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 8346C3A6A73 for ; Wed, 25 Aug 2010 00:58:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,267,1280721600"; d="scan'208";a="204351624" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 25 Aug 2010 03:59:23 -0400 X-IronPort-AV: E=Sophos;i="4.56,267,1280721600"; d="scan'208";a="507687070" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Aug 2010 03:59:22 -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, 25 Aug 2010 09:59:20 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS: netconf charter Thread-Index: ActD2pokQuBS429sTNuOaIugvTajewAT+TDg From: "Romascanu, Dan (Dan)" To: "netconf" Subject: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 07:58:53 -0000 Please address the issue raised by Russ in his DISCUSS.=20 My take is that authenticating users with an identity based ACM is not precluded by the charter, and it is the subset of NETCONF operations and content which is to be pre-configured by the operator. The wording however may not be clear if Russ got confused by the text. Please answer timely, as the IESG telechat is scheduled for tomorrow at 11:30AM ET, and the WG chairs (who are on vacation now) wanted to have the charter approved in the meeting.=20 Thanks and Regards, Dan -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Wednesday, August 25, 2010 1:21 AM To: Romascanu, Dan (Dan) Cc: IESG Subject: DISCUSS: netconf charter Item 3 in the charter talks about access control based on the identity of particular users that are pre-configured by the opertor. Some form of authenitcation is needed to work ahnd-in-hand with an identity-based access control mechanism. Please add aunthenication to the discussion. From j.schoenwaelder@jacobs-university.de Wed Aug 25 02:26:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE0D13A681D for ; Wed, 25 Aug 2010 02:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.861 X-Spam-Level: X-Spam-Status: No, score=-101.861 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Is0gkGF9gAW for ; Wed, 25 Aug 2010 02:26:05 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B14463A6AB4 for ; Wed, 25 Aug 2010 02:26:05 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F528C0009; Wed, 25 Aug 2010 11:26:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QeN42H2zmMJ3; Wed, 25 Aug 2010 11:26:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E4C6C000F; Wed, 25 Aug 2010 11:26:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ABCFA1462531; Wed, 25 Aug 2010 11:26:22 +0200 (CEST) Date: Wed, 25 Aug 2010 11:26:22 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100825092622.GA70538@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2010 09:26:07 -0000 On Wed, Aug 25, 2010 at 09:59:20AM +0200, Romascanu, Dan (Dan) wrote: > Please address the issue raised by Russ in his DISCUSS. > > My take is that authenticating users with an identity based ACM is not > precluded by the charter, and it is the subset of NETCONF operations and > content which is to be pre-configured by the operator. The wording > however may not be clear if Russ got confused by the text. > > Please answer timely, as the IESG telechat is scheduled for tomorrow at > 11:30AM ET, and the WG chairs (who are on vacation now) wanted to have > the charter approved in the meeting. s/particular/authenticated/ /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 25 08:32:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663DA3A6A4C for ; Wed, 25 Aug 2010 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrIrUQRACTRN for ; Wed, 25 Aug 2010 08:32:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id E5EF13A6988 for ; Wed, 25 Aug 2010 08:32:06 -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 o7PFWbLe031822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Aug 2010 17:32:37 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7PFWb6b018393; Wed, 25 Aug 2010 17:32:37 +0200 Received: from DEMUEXC006.nsn-intra.net ([10.150.128.18]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 17:32:37 +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, 25 Aug 2010 17:32:29 +0200 Message-ID: <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> In-Reply-To: <20100825092622.GA70538@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: DISCUSS: netconf charter thread-index: ActEN6Y42vYmZqW3TfSOQwVSs7izhAAMWJQw References: <20100825092622.GA70538@elstar.local> From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Juergen Schoenwaelder" , "Romascanu, Dan (Dan)" , "netconf" X-OriginalArrivalTime: 25 Aug 2010 15:32:37.0330 (UTC) FILETIME=[BF15F320:01CB446A] Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 15:32:13 -0000 Hi All, nice to hear that the group is working even when the chairs=20 are on vacation ;) I would like to propose to change the first paragraph in point 3 (or any modified version which Russ is willing to accept) Netconf Access Control Model (NACM) Requirements and Solution. OLD: There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured (by operator) subset of all available NETCONF operations and content. NEW: There is a need for standard mechanisms to restrict NETCONF protocol access for authenticated users to a pre- configured (by operator) subset of all available NETCONF operations and content. For this purpose authentication=20 methods for use with the NETCONF protocol will be specified=20 to work hand-in-hand with the identity-based access control=20 mechanism. Cheers, Mehmet > -----Original Message----- > From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On > Behalf Of ext Juergen Schoenwaelder > Sent: Wednesday, August 25, 2010 11:26 AM > To: Romascanu, Dan (Dan) > Cc: netconf > Subject: Re: [Netconf] FW: DISCUSS: netconf charter >=20 > On Wed, Aug 25, 2010 at 09:59:20AM +0200, Romascanu, Dan (Dan) wrote: > > Please address the issue raised by Russ in his DISCUSS. > > > > My take is that authenticating users with an identity based ACM is > not > > precluded by the charter, and it is the subset of NETCONF operations > and > > content which is to be pre-configured by the operator. The wording > > however may not be clear if Russ got confused by the text. > > > > Please answer timely, as the IESG telechat is scheduled for tomorrow > at > > 11:30AM ET, and the WG chairs (who are on vacation now) wanted to > have > > the charter approved in the meeting. >=20 > s/particular/authenticated/ >=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 Wed Aug 25 09:01:57 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DA9F3A6AD6 for ; Wed, 25 Aug 2010 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXzuqu6G77O5 for ; Wed, 25 Aug 2010 09:01:56 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0C9933A6B20 for ; Wed, 25 Aug 2010 09:01:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 832CBC0009; Wed, 25 Aug 2010 18:02:28 +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 fIITejuvEvFf; Wed, 25 Aug 2010 18:02:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99F77C0007; Wed, 25 Aug 2010 18:02:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1466914639B7; Wed, 25 Aug 2010 18:02:05 +0200 (CEST) Date: Wed, 25 Aug 2010 18:02:05 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20100825160205.GA2514@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , "Romascanu, Dan (Dan)" , netconf , "ext Bert Wijnen (IETF)" References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2010 16:01:57 -0000 On Wed, Aug 25, 2010 at 05:32:29PM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > Hi All, > > nice to hear that the group is working even when the chairs > are on vacation ;) > > I would like to propose to change the first paragraph in point 3 > (or any modified version which Russ is willing to accept) > Netconf Access Control Model (NACM) Requirements and Solution. > > OLD: > There is a need for standard mechanisms to restrict > NETCONF protocol access for particular users to a pre- > configured (by operator) subset of all available NETCONF > operations and content. > > NEW: > There is a need for standard mechanisms to restrict > NETCONF protocol access for authenticated users to a pre- > configured (by operator) subset of all available NETCONF > operations and content. For this purpose authentication > methods for use with the NETCONF protocol will be specified > to work hand-in-hand with the identity-based access control > mechanism. So what is this "identity-based" access control thing then? And as far as I understand, we are rechartering to do access control work, not authentication work. I guess I do not understand why the second sentence is useful. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Wed Aug 25 09:14:07 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CEB3A68AE for ; Wed, 25 Aug 2010 09:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y33y4I3y0CkQ for ; Wed, 25 Aug 2010 09:14:06 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 16D053A6879 for ; Wed, 25 Aug 2010 09:14:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,269,1280721600"; d="scan'208";a="234648125" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Aug 2010 12:14:38 -0400 X-IronPort-AV: E=Sophos;i="4.56,269,1280721600"; d="scan'208";a="507886630" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Aug 2010 12:14:37 -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, 25 Aug 2010 18:14:15 +0200 Message-ID: In-Reply-To: <20100825160205.GA2514@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: DISCUSS: netconf charter Thread-Index: ActEbu1YvRrrdv2sS2SxhpVNBmvIGAAAWFmw References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Ersue, Mehmet (NSN - DE/Munich)" Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:14:07 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Wednesday, August 25, 2010 7:02 PM > To: Ersue, Mehmet (NSN - DE/Munich) > Cc: Romascanu, Dan (Dan); netconf; ext Bert Wijnen (IETF) > Subject: Re: [Netconf] FW: DISCUSS: netconf charter >=20 > On Wed, Aug 25, 2010 at 05:32:29PM +0200, Ersue, Mehmet (NSN=20 > - DE/Munich) wrote: > > Hi All, > >=20 > > nice to hear that the group is working even when the chairs are on=20 > > vacation ;) > >=20 > > I would like to propose to change the first paragraph in=20 > point 3 (or=20 > > any modified version which Russ is willing to accept)=20 > Netconf Access=20 > > Control Model (NACM) Requirements and Solution. > >=20 > > OLD: > > There is a need for standard mechanisms to restrict > > NETCONF protocol access for particular users to a pre- > > configured (by operator) subset of all available NETCONF > > operations and content. > >=20 > > NEW: > > There is a need for standard mechanisms to restrict > > NETCONF protocol access for authenticated users to a pre- > > configured (by operator) subset of all available NETCONF > > operations and content. For this purpose authentication=20 > > methods for use with the NETCONF protocol will be specified=20 > > to work hand-in-hand with the identity-based access control=20 > > mechanism. >=20 > So what is this "identity-based" access control thing then?=20 > And as far as I understand, we are rechartering to do access=20 > control work, not authentication work. I guess I do not=20 > understand why the second sentence is useful. >=20 > /js >=20 My understanding is that if the network has a mechanism to authenticate users access, the access mechanisms protocols to be defined here will need to work 'hand-in-hand' with it.=20 Dan From ietf@andybierman.com Wed Aug 25 09:25:35 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEEB03A6879 for ; Wed, 25 Aug 2010 09:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbnSIFw3E7wO for ; Wed, 25 Aug 2010 09:25:34 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by core3.amsl.com (Postfix) with ESMTP id B08893A681F for ; Wed, 25 Aug 2010 09:25:34 -0700 (PDT) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id o7PGQ6Ak003203 for ; Wed, 25 Aug 2010 12:26:06 -0400 Authentication-Results: cm-omr7 smtp.user=ietf@andybierman.com; auth=pass (LOGIN) X-Authenticated-UID: ietf@andybierman.com Received: from [174.144.78.102] ([174.144.78.102:48859] helo=[174.144.78.102]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 6E/9E-13420-B14457C4; Wed, 25 Aug 2010 12:26:06 -0400 To: "=?utf-8?B?Um9tYXNjYW51LCBEYW4gKERhbik=?=" , "=?utf-8?B?SnVlcmdlbiBTY2hvZW53YWVsZGVy?=" , "=?utf-8?B?RXJzdWUsIE1laG1ldCAoTlNOIC0gREUvTXVuaWNoKQ==?=" Message-ID: <6E.9E.13420.B14457C4@cm-omr7> From: "=?utf-8?B?QW5keSBCaWVybWFu?=" Date: Wed, 25 Aug 2010 09:26:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_16_1282753580522" Cc: netconf Subject: Re: [Netconf] =?utf-8?q?FW=3A_DISCUSS=3A_netconf_charter?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 16:25:36 -0000 ------=_Part_16_1282753580522 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIEp1ZXJnZW4gYWJvdXQgcy9wYXJ0aWN1bGFyL2F1dGhlbnRpY2F0ZWQuCgpX ZSBhcmUgbm90IGFkZGluZyBuZXcgYXV0aCBtZWNoYW5pc21zLiAgV2UgYWxyZWFkeSBoYXZlIHNv bWUgdGV4dCBhYm91dCBkZXJpdmluZyBhIHVzZXIgaWRlbnRpdHkuCk90aGVyIHRoYW4gdGhhdCwg d2Ugc2hvdWxkIGtlZXAgdGhlIHNjb3BlIGxpbWl0ZWQuCgoKQW5keQoKCi0tLS0tIFJlcGx5IG1l c3NhZ2UgLS0tLS0KRnJvbTogIlJvbWFzY2FudSwgRGFuIChEYW4pIiA8ZHJvbWFzY2FAYXZheWEu Y29tPgpEYXRlOiBXZWQsIEF1ZyAyNSwgMjAxMCAwOToxNApTdWJqZWN0OiBbTmV0Y29uZl0gRlc6 IERJU0NVU1M6IG5ldGNvbmYgY2hhcnRlcgpUbzogIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4sICJFcnN1ZSwgTWVobWV0IChOU04g LSBERS9NdW5pY2gpIiA8bWVobWV0LmVyc3VlQG5zbi5jb20+CkNjOiAibmV0Y29uZiIgPG5ldGNv bmZAaWV0Zi5vcmc+CgoKIAoKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciAKPiBbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5p dmVyc2l0eS5kZV0gCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjUsIDIwMTAgNzowMiBQTQo+ IFRvOiBFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpCj4gQ2M6IFJvbWFzY2FudSwgRGFu IChEYW4pOyBuZXRjb25mOyBleHQgQmVydCBXaWpuZW4gKElFVEYpCj4gU3ViamVjdDogUmU6IFtO ZXRjb25mXSBGVzogRElTQ1VTUzogbmV0Y29uZiBjaGFydGVyCj4gCj4gT24gV2VkLCBBdWcgMjUs IDIwMTAgYXQgMDU6MzI6MjlQTSArMDIwMCwgRXJzdWUsIE1laG1ldCAoTlNOIAo+IC0gREUvTXVu aWNoKSB3cm90ZToKPiA+IEhpIEFsbCwKPiA+IAo+ID4gbmljZSB0byBoZWFyIHRoYXQgdGhlIGdy b3VwIGlzIHdvcmtpbmcgZXZlbiB3aGVuIHRoZSBjaGFpcnMgYXJlIG9uIAo+ID4gdmFjYXRpb24g OykKPiA+IAo+ID4gSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdG8gY2hhbmdlIHRoZSBmaXJzdCBw YXJhZ3JhcGggaW4gCj4gcG9pbnQgMyAob3IgCj4gPiBhbnkgbW9kaWZpZWQgdmVyc2lvbiB3aGlj aCBSdXNzIGlzIHdpbGxpbmcgdG8gYWNjZXB0KSAKPiBOZXRjb25mIEFjY2VzcyAKPiA+IENvbnRy b2wgTW9kZWwgKE5BQ00pIFJlcXVpcmVtZW50cyBhbmQgU29sdXRpb24uCj4gPiAKPiA+IE9MRDoK PiA+ICAgICAgIFRoZXJlIGlzIGEgbmVlZCBmb3Igc3RhbmRhcmQgbWVjaGFuaXNtcyB0byByZXN0 cmljdAo+ID4gICAgICAgTkVUQ09ORiBwcm90b2NvbCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNl cnMgdG8gYSBwcmUtCj4gPiAgICAgICBjb25maWd1cmVkIChieSBvcGVyYXRvcikgc3Vic2V0IG9m IGFsbCBhdmFpbGFibGUgTkVUQ09ORgo+ID4gICAgICAgb3BlcmF0aW9ucyBhbmQgY29udGVudC4K PiA+IAo+ID4gTkVXOgo+ID4gICAgICAgVGhlcmUgaXMgYSBuZWVkIGZvciBzdGFuZGFyZCBtZWNo YW5pc21zIHRvIHJlc3RyaWN0Cj4gPiAgICAgICBORVRDT05GIHByb3RvY29sIGFjY2VzcyBmb3Ig YXV0aGVudGljYXRlZCB1c2VycyB0byBhIHByZS0KPiA+ICAgICAgIGNvbmZpZ3VyZWQgKGJ5IG9w ZXJhdG9yKSBzdWJzZXQgb2YgYWxsIGF2YWlsYWJsZSBORVRDT05GCj4gPiAgICAgICBvcGVyYXRp b25zIGFuZCBjb250ZW50LiBGb3IgdGhpcyBwdXJwb3NlIGF1dGhlbnRpY2F0aW9uIAo+ID4gICAg ICAgbWV0aG9kcyBmb3IgdXNlIHdpdGggdGhlIE5FVENPTkYgcHJvdG9jb2wgd2lsbCBiZSBzcGVj aWZpZWQgCj4gPiAgICAgICB0byB3b3JrIGhhbmQtaW4taGFuZCB3aXRoIHRoZSBpZGVudGl0eS1i YXNlZCBhY2Nlc3MgY29udHJvbCAKPiA+ICAgICAgIG1lY2hhbmlzbS4KPiAKPiBTbyB3aGF0IGlz IHRoaXMgImlkZW50aXR5LWJhc2VkIiBhY2Nlc3MgY29udHJvbCB0aGluZyB0aGVuPyAKPiBBbmQg YXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgd2UgYXJlIHJlY2hhcnRlcmluZyB0byBkbyBhY2Nlc3Mg Cj4gY29udHJvbCB3b3JrLCBub3QgYXV0aGVudGljYXRpb24gd29yay4gSSBndWVzcyBJIGRvIG5v dCAKPiB1bmRlcnN0YW5kIHdoeSB0aGUgc2Vjb25kIHNlbnRlbmNlIGlzIHVzZWZ1bC4KPiAKPiAv anMKPiAKCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpZiB0aGUgbmV0d29yayBoYXMgYSBtZWNo YW5pc20gdG8gYXV0aGVudGljYXRlCnVzZXJzIGFjY2VzcywgdGhlIGFjY2VzcyBtZWNoYW5pc21z IHByb3RvY29scyB0byBiZSBkZWZpbmVkIGhlcmUgd2lsbApuZWVkIHRvIHdvcmsgJ2hhbmQtaW4t aGFuZCcgd2l0aCBpdC4gCgpEYW4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYKCg== ------=_Part_16_1282753580522 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SSBhZ3JlZSB3aXRoIEp1ZXJnZW4gYWJvdXQgcy9wYXJ0aWN1bGFyL2F1dGhlbnRpY2F0ZWQuPGJy Pjxicj5XZSBhcmUgbm90IGFkZGluZyBuZXcgYXV0aCBtZWNoYW5pc21zLiAmbmJzcDtXZSBhbHJl YWR5IGhhdmUgc29tZSB0ZXh0IGFib3V0IGRlcml2aW5nIGEgdXNlciBpZGVudGl0eS48YnI+T3Ro ZXIgdGhhbiB0aGF0LCB3ZSBzaG91bGQga2VlcCB0aGUgc2NvcGUgbGltaXRlZC48YnI+PGJyPjxi cj5BbmR5PGJyPjxicj48YnI+LS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj5Gcm9tOiAmcXVv dDtSb21hc2NhbnUsIERhbiAoRGFuKSZxdW90OyAmbHQ7ZHJvbWFzY2FAYXZheWEuY29tJmd0Ozxi cj5EYXRlOiBXZWQsIEF1ZyAyNSwgMjAxMCAwOToxNDxicj5TdWJqZWN0OiBbTmV0Y29uZl0gRlc6 IERJU0NVU1M6IG5ldGNvbmYgY2hhcnRlcjxicj5UbzogJnF1b3Q7SnVlcmdlbiBTY2hvZW53YWVs ZGVyJnF1b3Q7ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7LCAm cXVvdDtFcnN1ZSwgTWVobWV0IChOU04gLSBERS9NdW5pY2gpJnF1b3Q7ICZsdDttZWhtZXQuZXJz dWVAbnNuLmNvbSZndDs8YnI+Q2M6ICZxdW90O25ldGNvbmYmcXVvdDsgJmx0O25ldGNvbmZAaWV0 Zi5vcmcmZ3Q7PGJyPjxicj48YnI+IDxicj48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4mZ3Q7IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8YnI+Jmd0OyBbbWFpbHRv Omouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0gPGJyPiZndDsgU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMjUsIDIwMTAgNzowMiBQTTxicj4mZ3Q7IFRvOiBFcnN1ZSwgTWVobWV0 IChOU04gLSBERS9NdW5pY2gpPGJyPiZndDsgQ2M6IFJvbWFzY2FudSwgRGFuIChEYW4pOyBuZXRj b25mOyBleHQgQmVydCBXaWpuZW4gKElFVEYpPGJyPiZndDsgU3ViamVjdDogUmU6IFtOZXRjb25m XSBGVzogRElTQ1VTUzogbmV0Y29uZiBjaGFydGVyPGJyPiZndDsgPGJyPiZndDsgT24gV2VkLCBB dWcgMjUsIDIwMTAgYXQgMDU6MzI6MjlQTSArMDIwMCwgRXJzdWUsIE1laG1ldCAoTlNOIDxicj4m Z3Q7IC0gREUvTXVuaWNoKSB3cm90ZTo8YnI+Jmd0OyAmZ3Q7IEhpIEFsbCw8YnI+Jmd0OyAmZ3Q7 IDxicj4mZ3Q7ICZndDsgbmljZSB0byBoZWFyIHRoYXQgdGhlIGdyb3VwIGlzIHdvcmtpbmcgZXZl biB3aGVuIHRoZSBjaGFpcnMgYXJlIG9uIDxicj4mZ3Q7ICZndDsgdmFjYXRpb24gOyk8YnI+Jmd0 OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgdG8gY2hhbmdlIHRo ZSBmaXJzdCBwYXJhZ3JhcGggaW4gPGJyPiZndDsgcG9pbnQgMyAob3IgPGJyPiZndDsgJmd0OyBh bnkgbW9kaWZpZWQgdmVyc2lvbiB3aGljaCBSdXNzIGlzIHdpbGxpbmcgdG8gYWNjZXB0KSA8YnI+ Jmd0OyBOZXRjb25mIEFjY2VzcyA8YnI+Jmd0OyAmZ3Q7IENvbnRyb2wgTW9kZWwgKE5BQ00pIFJl cXVpcmVtZW50cyBhbmQgU29sdXRpb24uPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IE9MRDo8 YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZXJlIGlzIGEgbmVlZCBmb3Igc3Rh bmRhcmQgbWVjaGFuaXNtcyB0byByZXN0cmljdDxicj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgTkVUQ09ORiBwcm90b2NvbCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNlcnMgdG8gYSBw cmUtPGJyPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBjb25maWd1cmVkIChieSBvcGVy YXRvcikgc3Vic2V0IG9mIGFsbCBhdmFpbGFibGUgTkVUQ09ORjxicj4mZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgb3BlcmF0aW9ucyBhbmQgY29udGVudC48YnI+Jmd0OyAmZ3Q7IDxicj4m Z3Q7ICZndDsgTkVXOjxicj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlcmUgaXMg YSBuZWVkIGZvciBzdGFuZGFyZCBtZWNoYW5pc21zIHRvIHJlc3RyaWN0PGJyPiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBORVRDT05GIHByb3RvY29sIGFjY2VzcyBmb3IgYXV0aGVudGlj YXRlZCB1c2VycyB0byBhIHByZS08YnI+Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNv bmZpZ3VyZWQgKGJ5IG9wZXJhdG9yKSBzdWJzZXQgb2YgYWxsIGF2YWlsYWJsZSBORVRDT05GPGJy PiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvcGVyYXRpb25zIGFuZCBjb250ZW50LiBG b3IgdGhpcyBwdXJwb3NlIGF1dGhlbnRpY2F0aW9uIDxicj4mZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgbWV0aG9kcyBmb3IgdXNlIHdpdGggdGhlIE5FVENPTkYgcHJvdG9jb2wgd2lsbCBi ZSBzcGVjaWZpZWQgPGJyPiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byB3b3JrIGhh bmQtaW4taGFuZCB3aXRoIHRoZSBpZGVudGl0eS1iYXNlZCBhY2Nlc3MgY29udHJvbCA8YnI+Jmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1lY2hhbmlzbS48YnI+Jmd0OyA8YnI+Jmd0OyBT byB3aGF0IGlzIHRoaXMgJnF1b3Q7aWRlbnRpdHktYmFzZWQmcXVvdDsgYWNjZXNzIGNvbnRyb2wg dGhpbmcgdGhlbj8gPGJyPiZndDsgQW5kIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHdlIGFyZSBy ZWNoYXJ0ZXJpbmcgdG8gZG8gYWNjZXNzIDxicj4mZ3Q7IGNvbnRyb2wgd29yaywgbm90IGF1dGhl bnRpY2F0aW9uIHdvcmsuIEkgZ3Vlc3MgSSBkbyBub3QgPGJyPiZndDsgdW5kZXJzdGFuZCB3aHkg dGhlIHNlY29uZCBzZW50ZW5jZSBpcyB1c2VmdWwuPGJyPiZndDsgPGJyPiZndDsgL2pzPGJyPiZn dDsgPGJyPjxicj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgaWYgdGhlIG5ldHdvcmsgaGFzIGEg bWVjaGFuaXNtIHRvIGF1dGhlbnRpY2F0ZTxicj51c2VycyBhY2Nlc3MsIHRoZSBhY2Nlc3MgbWVj aGFuaXNtcyBwcm90b2NvbHMgdG8gYmUgZGVmaW5lZCBoZXJlIHdpbGw8YnI+bmVlZCB0byB3b3Jr ICYjMzk7aGFuZC1pbi1oYW5kJiMzOTsgd2l0aCBpdC4gPGJyPjxicj5EYW48YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+TmV0Y29uZiBtYWlsaW5n IGxpc3Q8YnI+TmV0Y29uZkBpZXRmLm9yZzxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZjwvYT48YnI+PGJyPjxicj48YnI+ ------=_Part_16_1282753580522-- From j.schoenwaelder@jacobs-university.de Wed Aug 25 14:52:05 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3AE3A6B5C for ; Wed, 25 Aug 2010 14:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.913 X-Spam-Level: X-Spam-Status: No, score=-101.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSUaO92Fnhkj for ; Wed, 25 Aug 2010 14:52:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 51B6D3A6837 for ; Wed, 25 Aug 2010 14:52:04 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 46E6CC000A; Wed, 25 Aug 2010 23:52:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id oVqiadFSUKix; Wed, 25 Aug 2010 23:52:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 959A4C0009; Wed, 25 Aug 2010 23:52:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6F2D91463F53; Wed, 25 Aug 2010 23:52:14 +0200 (CEST) Date: Wed, 25 Aug 2010 23:52:13 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100825215213.GA2857@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , "Ersue, Mehmet (NSN - DE/Munich)" , netconf , "ext Bert Wijnen (IETF)" References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 25 Aug 2010 21:52:05 -0000 On Wed, Aug 25, 2010 at 06:14:15PM +0200, Romascanu, Dan (Dan) wrote: > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Wednesday, August 25, 2010 7:02 PM > > To: Ersue, Mehmet (NSN - DE/Munich) > > Cc: Romascanu, Dan (Dan); netconf; ext Bert Wijnen (IETF) > > Subject: Re: [Netconf] FW: DISCUSS: netconf charter > > > > On Wed, Aug 25, 2010 at 05:32:29PM +0200, Ersue, Mehmet (NSN > > - DE/Munich) wrote: > > > Hi All, > > > > > > nice to hear that the group is working even when the chairs are on > > > vacation ;) > > > > > > I would like to propose to change the first paragraph in > > point 3 (or > > > any modified version which Russ is willing to accept) > > Netconf Access > > > Control Model (NACM) Requirements and Solution. > > > > > > OLD: > > > There is a need for standard mechanisms to restrict > > > NETCONF protocol access for particular users to a pre- > > > configured (by operator) subset of all available NETCONF > > > operations and content. > > > > > > NEW: > > > There is a need for standard mechanisms to restrict > > > NETCONF protocol access for authenticated users to a pre- > > > configured (by operator) subset of all available NETCONF > > > operations and content. For this purpose authentication > > > methods for use with the NETCONF protocol will be specified > > > to work hand-in-hand with the identity-based access control > > > mechanism. > > > > So what is this "identity-based" access control thing then? > > And as far as I understand, we are rechartering to do access > > control work, not authentication work. I guess I do not > > understand why the second sentence is useful. > > > > /js > > > > My understanding is that if the network has a mechanism to authenticate > users access, the access mechanisms protocols to be defined here will > need to work 'hand-in-hand' with it. I still do not see why the new sentence is needed nor do I have a clue what work 'hand-in-hand' means. Those who argue for the addition of this sentence should explain it better. I maintain the position that we are not rechartering to do authentication work. But this is what the new sentence says. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Wed Aug 25 15:58:56 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E053A694C for ; Wed, 25 Aug 2010 15:58:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpyDjc3gSyWP for ; Wed, 25 Aug 2010 15:58:56 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id C67473A68A5 for ; Wed, 25 Aug 2010 15:58:55 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id BB69F980A4; Wed, 25 Aug 2010 15:59:27 -0700 (PDT) From: Wes Hardaker To: "Romascanu\, Dan \(Dan\)" Organization: Sparta References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> Date: Wed, 25 Aug 2010 15:59:27 -0700 In-Reply-To: <20100825215213.GA2857@elstar.local> (Juergen Schoenwaelder's message of "Wed, 25 Aug 2010 23:52:13 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:58:56 -0000 >>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen Schoenwaelder said: JS> I still do not see why the new sentence is needed nor do I have a clue JS> what work 'hand-in-hand' means. Those who argue for the addition of JS> this sentence should explain it better. I maintain the position that JS> we are not rechartering to do authentication work. But this is what JS> the new sentence says. Authentication and authorization must play well together. Hand-in-hand to me does make sense because at some point you have to deal with user-naming and privileges based on delivery methods, which hasn't been done yet within netconf. IE, you may want to treat "juergen" differently over telnet than "juergen" over ssh. Possibly because of the security differences or possibly because they're actually authenticating via two different databases. The WG has yet to make the decision if something like the vacmSecurityToGroupTable is needed for netconf, which does include at least some information about the authentication method (in the SNMP case, just the model, but it's not "zero" knowledge). But, certainly one choice is to have "juergen" always be "juergen" according to access control because we don't want to care about database incompatibilities between two different distinct authentication mechanisms. That, to me, is sort of what the text hints at, though I have no idea if the original author intended me to interpret it this way. -- Wes Hardaker Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Thu Aug 26 00:31:29 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1047B3A6A7D for ; Thu, 26 Aug 2010 00:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.917 X-Spam-Level: X-Spam-Status: No, score=-101.917 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05t2fR-BUTbG for ; Thu, 26 Aug 2010 00:31:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CCCE23A6954 for ; Thu, 26 Aug 2010 00:31:25 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B813BC0009; Thu, 26 Aug 2010 09:31:57 +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 CternzwNxSJb; Thu, 26 Aug 2010 09:31:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 71A80C0002; Thu, 26 Aug 2010 09:31:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 364BF1464858; Thu, 26 Aug 2010 09:31:35 +0200 (CEST) Date: Thu, 26 Aug 2010 09:31:34 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20100826073134.GA3556@elstar.local> Mail-Followup-To: Wes Hardaker , "Romascanu, Dan (Dan)" , netconf References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2010 07:31:29 -0000 On Thu, Aug 26, 2010 at 12:59:27AM +0200, Wes Hardaker wrote: > >>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen Schoenwaelder said: > > JS> I still do not see why the new sentence is needed nor do I have a clue > JS> what work 'hand-in-hand' means. Those who argue for the addition of > JS> this sentence should explain it better. I maintain the position that > JS> we are not rechartering to do authentication work. But this is what > JS> the new sentence says. > > Authentication and authorization must play well together. Hand-in-hand > to me does make sense because at some point you have to deal with > user-naming and privileges based on delivery methods, which hasn't been > done yet within netconf. IE, you may want to treat "juergen" > differently over telnet than "juergen" over ssh. Possibly because of > the security differences or possibly because they're actually > authenticating via two different databases. > > The WG has yet to make the decision if something like the > vacmSecurityToGroupTable is needed for netconf, which does include at > least some information about the authentication method (in the SNMP case, > just the model, but it's not "zero" knowledge). > > But, certainly one choice is to have "juergen" always be "juergen" > according to access control because we don't want to care about database > incompatibilities between two different distinct authentication > mechanisms. That, to me, is sort of what the text hints at, though I > have no idea if the original author intended me to interpret it this way. Assuming for a moment that this interpretation is what the orignal author intended and that there is a specific reason to have this specific requirement hard coded in the charter, then I would still appreciate a more direct wording, e.g.: The access control mechanism must be able to distinguish users authenticated in different authentication realms. I am just trying to make sure that the WG understands the charter text so that we avoid any debates about what the charter means later on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Aug 26 02:36:40 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91883A6B0D for ; Thu, 26 Aug 2010 02:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsoAOZajrrz7 for ; Thu, 26 Aug 2010 02:35:49 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 6C6943A6403 for ; Thu, 26 Aug 2010 02:34:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="234779819" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2010 05:33:49 -0400 X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="502019098" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Aug 2010 05:33:49 -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: Thu, 26 Aug 2010 11:33:29 +0200 Message-ID: In-Reply-To: <20100826073134.GA3556@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: DISCUSS: netconf charter Thread-Index: ActE8MXyGB9U16xETmCt/isxwU1YFgAEKe9w References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> <20100826073134.GA3556@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Wes Hardaker" Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 09:36:42 -0000 Unfortunately, what I am getting from these discussions is that the WG did not reach a consensus on these issues. Despite the original request of the chairs (who are both on vacation) the charter cannot be approved today. I will ask to be sent for external review, so that the WG can debate and agree in the next two weeks on the exact scope and words in the charter.=20 Dan =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, August 26, 2010 10:32 AM > To: Wes Hardaker > Cc: Romascanu, Dan (Dan); netconf > Subject: Re: [Netconf] FW: DISCUSS: netconf charter >=20 > On Thu, Aug 26, 2010 at 12:59:27AM +0200, Wes Hardaker wrote: > > >>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen=20 > Schoenwaelder said: > >=20 > > JS> I still do not see why the new sentence is needed nor=20 > do I have a=20 > > JS> clue what work 'hand-in-hand' means. Those who argue for the=20 > > JS> addition of this sentence should explain it better. I=20 > maintain the=20 > > JS> position that we are not rechartering to do=20 > authentication work.=20 > > JS> But this is what the new sentence says. > >=20 > > Authentication and authorization must play well together. =20 > > Hand-in-hand to me does make sense because at some point=20 > you have to=20 > > deal with user-naming and privileges based on delivery=20 > methods, which=20 > > hasn't been done yet within netconf. IE, you may want to=20 > treat "juergen" > > differently over telnet than "juergen" over ssh. Possibly=20 > because of=20 > > the security differences or possibly because they're actually=20 > > authenticating via two different databases. > >=20 > > The WG has yet to make the decision if something like the=20 > > vacmSecurityToGroupTable is needed for netconf, which does=20 > include at=20 > > least some information about the authentication method (in the SNMP=20 > > case, just the model, but it's not "zero" knowledge). > >=20 > > But, certainly one choice is to have "juergen" always be "juergen" > > according to access control because we don't want to care about=20 > > database incompatibilities between two different distinct=20 > > authentication mechanisms. That, to me, is sort of what the text=20 > > hints at, though I have no idea if the original author=20 > intended me to interpret it this way. >=20 > Assuming for a moment that this interpretation is what the=20 > orignal author intended and that there is a specific reason=20 > to have this specific requirement hard coded in the charter,=20 > then I would still appreciate a more direct wording, e.g.: >=20 > The access control mechanism must be able to distinguish users > authenticated in different authentication realms. >=20 > I am just trying to make sure that the WG understands the=20 > charter text so that we avoid any debates about what the=20 > charter means later on. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 From j.schoenwaelder@jacobs-university.de Thu Aug 26 02:46:58 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D5A3A6403 for ; Thu, 26 Aug 2010 02:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.929 X-Spam-Level: X-Spam-Status: No, score=-101.929 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJNAjfa7u60J for ; Thu, 26 Aug 2010 02:46:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 5676F3A6359 for ; Thu, 26 Aug 2010 02:46:57 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9246BC0010; Thu, 26 Aug 2010 11:47:29 +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 93UqvQcTFZpZ; Thu, 26 Aug 2010 11:47:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7852CC000A; Thu, 26 Aug 2010 11:47:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 118211464DEF; Thu, 26 Aug 2010 11:47:07 +0200 (CEST) Date: Thu, 26 Aug 2010 11:47:07 +0200 From: Juergen Schoenwaelder To: "Romascanu, Dan (Dan)" Message-ID: <20100826094707.GC4022@elstar.local> Mail-Followup-To: "Romascanu, Dan (Dan)" , Wes Hardaker , netconf References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> <20100826073134.GA3556@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2010 09:46:58 -0000 On Thu, Aug 26, 2010 at 11:33:29AM +0200, Romascanu, Dan (Dan) wrote: > Unfortunately, what I am getting from these discussions is that the WG > did not reach a consensus on these issues. Despite the original request > of the chairs (who are both on vacation) the charter cannot be approved > today. I will ask to be sent for external review, so that the WG can > debate and agree in the next two weeks on the exact scope and words in > the charter. It seems it is not clear what the issue is. Perhaps you can clarify during the discussion today and ask Russ in particular whether s/particular/authenticated/ is already resolving his comment. Otherwise, the WG needs a clearer description from the IESG or Russ what the issue is. Without that, the WG will just not know how to resolve this comment because we do not understand what it means. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Aug 26 03:01:23 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EACE43A680B for ; Thu, 26 Aug 2010 03:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIYpJDXCGTnJ for ; Thu, 26 Aug 2010 03:01:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2154B3A6359 for ; Thu, 26 Aug 2010 03:01:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="234783734" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Aug 2010 06:01:55 -0400 X-IronPort-AV: E=Sophos;i="4.56,272,1280721600"; d="scan'208";a="508291480" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Aug 2010 06:01:54 -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: Thu, 26 Aug 2010 12:01:34 +0200 Message-ID: In-Reply-To: <20100826094707.GC4022@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: DISCUSS: netconf charter Thread-Index: ActFA7UsoPIQarP0ToaZ0Y8MJtCF5wAAeMwQ References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> <20100826073134.GA3556@elstar.local> <20100826094707.GC4022@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 10:01:24 -0000 =20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de]=20 > Sent: Thursday, August 26, 2010 12:47 PM > To: Romascanu, Dan (Dan) > Cc: Wes Hardaker; netconf > Subject: Re: [Netconf] FW: DISCUSS: netconf charter >=20 > On Thu, Aug 26, 2010 at 11:33:29AM +0200, Romascanu, Dan (Dan) wrote: >=20 > > Unfortunately, what I am getting from these discussions is=20 > that the WG=20 > > did not reach a consensus on these issues. Despite the original=20 > > request of the chairs (who are both on vacation) the=20 > charter cannot be=20 > > approved today. I will ask to be sent for external review,=20 > so that the=20 > > WG can debate and agree in the next two weeks on the exact=20 > scope and=20 > > words in the charter. >=20 > It seems it is not clear what the issue is. Perhaps you can=20 > clarify during the discussion today and ask Russ in particular whether >=20 > s/particular/authenticated/ >=20 > is already resolving his comment. Otherwise, the WG needs a=20 > clearer description from the IESG or Russ what the issue is.=20 > Without that, the WG will just not know how to resolve this=20 > comment because we do not understand what it means. >=20 > /js >=20 OK. Dan From ietf@andybierman.com Thu Aug 26 04:46:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45903A6AA5 for ; Thu, 26 Aug 2010 04:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-1Rz9a+w1wi for ; Thu, 26 Aug 2010 04:46:12 -0700 (PDT) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id C42873A6AB0 for ; Thu, 26 Aug 2010 04:46:12 -0700 (PDT) Received: (qmail 72969 invoked from network); 26 Aug 2010 11:46:43 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 26 Aug 2010 04:46:43 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: dbCTCmkVM1mc.4mxkgp5wqhscXYwWcNAKhV5_UdawoJqZtq UUHDwf.LRfmO020jHj.QNVuOeDQ1E8miwZYo22f0.nphBhRzK7wj3hreVFBu K4QiP35ALjnG2PbLV.IgsK44t6GuvwYrFnibNgK5Hx_vyvmSyqau86PRVllR zQj.7JGRYDnew3Oebu706y7W1BMrA7gyZEiCmv6keuSK8Kve.lu80F2ADd4A XCa8L1CDpBsFtwk6xxaNbxC3tu6_k18HhifOuMa4yDKeM.m2kfQpp1QuQ8ww ptA9fk_chmW.ZK5pO X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C765422.2000700@andybierman.com> Date: Thu, 26 Aug 2010 04:46:42 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Wes Hardaker References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 11:46:13 -0000 On 08/25/2010 03:59 PM, Wes Hardaker wrote: >>>>>> On Wed, 25 Aug 2010 23:52:13 +0200, Juergen Schoenwaelder said: > > JS> I still do not see why the new sentence is needed nor do I have a clue > JS> what work 'hand-in-hand' means. Those who argue for the addition of > JS> this sentence should explain it better. I maintain the position that > JS> we are not rechartering to do authentication work. But this is what > JS> the new sentence says. > > Authentication and authorization must play well together. Hand-in-hand > to me does make sense because at some point you have to deal with > user-naming and privileges based on delivery methods, which hasn't been > done yet within netconf. IE, you may want to treat "juergen" > differently over telnet than "juergen" over ssh. Possibly because of > the security differences or possibly because they're actually > authenticating via two different databases. > The intent of the current charter text was that NETCONF NACM will authorize access for subsets of the entire conceptual content-store, for a user which has already been authenticated. > The WG has yet to make the decision if something like the > vacmSecurityToGroupTable is needed for netconf, which does include at > least some information about the authentication method (in the SNMP case, > just the model, but it's not "zero" knowledge). > We standardize what is common, and what has WG consensus. The YANG augment-stmt is there for a reason. Vendors can always add additional functionality, which in turn, can be standardized in the future. > But, certainly one choice is to have "juergen" always be "juergen" > according to access control because we don't want to care about database > incompatibilities between two different distinct authentication > mechanisms. That, to me, is sort of what the text hints at, though I > have no idea if the original author intended me to interpret it this way. Or we can leave this as am implementation detail like we decided at the last IETF. Operators will configure their systems correctly, for their particular environment. There may not be a 1-name-fits-all solution, so we should not gate success or failure on solving this non-NETCONF-specific problem. Andy From j.schoenwaelder@jacobs-university.de Thu Aug 26 06:00:08 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5763A6970 for ; Thu, 26 Aug 2010 06:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.633 X-Spam-Level: X-Spam-Status: No, score=-101.633 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMixwg6HRv6b for ; Thu, 26 Aug 2010 06:00:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 42FE33A67E2 for ; Thu, 26 Aug 2010 06:00:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57BF5C0011; Thu, 26 Aug 2010 15:00:39 +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 YGYGSWu3qd-S; Thu, 26 Aug 2010 15:00:37 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B59EC0014; Thu, 26 Aug 2010 15:00:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 41FBD14657B8; Thu, 26 Aug 2010 15:00:17 +0200 (CEST) Date: Thu, 26 Aug 2010 15:00:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100826130016.GA5691@elstar.local> Mail-Followup-To: Andy Bierman , Wes Hardaker , netconf References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> <4C765422.2000700@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C765422.2000700@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2010 13:00:08 -0000 On Thu, Aug 26, 2010 at 01:46:42PM +0200, Andy Bierman wrote: [...] > Or we can leave this as am implementation detail like we decided at the > last IETF. Operators will configure their systems correctly, for their > particular environment. There may not be a 1-name-fits-all solution, > so we should not gate success or failure on solving this non-NETCONF-specific > problem. Andy, the ISMS WG has gone through all this and the result is that it is configurable whether you want to distinguish ssh:foo from tls:foo or not. So the decision rests with the operator. I think it would be good to provide a similar configuration option in NETCONF land and I would not mind if this would be spelled out as a requirements that the WG is to document as part of the solution document. That said, only the IESG knows whether this is so important that it needs to be required in the charter - and this is what this thread is about. Perhaps they were even hinting at something totally different. I hope we will know by the end of the day. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Thu Aug 26 06:02:06 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD3D3A67E2 for ; Thu, 26 Aug 2010 06:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+i1mykn1deH for ; Thu, 26 Aug 2010 06:02:06 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id A39693A6970 for ; Thu, 26 Aug 2010 06:02:05 -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 2A810616007; Thu, 26 Aug 2010 15:02:37 +0200 (CEST) Date: Thu, 26 Aug 2010 15:02:36 +0200 (CEST) Message-Id: <20100826.150236.147065199.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20100826130016.GA5691@elstar.local> References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> X-Mailer: Mew version 7.0.50 on Emacs 23.1 / 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] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:02:06 -0000 Juergen Schoenwaelder wrote: > On Thu, Aug 26, 2010 at 01:46:42PM +0200, Andy Bierman wrote: > > [...] > > > Or we can leave this as am implementation detail like we decided at the > > last IETF. Operators will configure their systems correctly, for their > > particular environment. There may not be a 1-name-fits-all solution, > > so we should not gate success or failure on solving this non-NETCONF-specific > > problem. > > Andy, > > the ISMS WG has gone through all this and the result is that it is > configurable whether you want to distinguish ssh:foo from tls:foo or > not. So the decision rests with the operator. > > I think it would be good to provide a similar configuration option in > NETCONF land and I would not mind if this would be spelled out as a > requirements that the WG is to document as part of the solution > document. +1 /martin From dromasca@avaya.com Thu Aug 26 06:08:33 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9503A6985 for ; Thu, 26 Aug 2010 06:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.194 X-Spam-Level: X-Spam-Status: No, score=-102.194 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVqOpg87bghM for ; Thu, 26 Aug 2010 06:08:33 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 9B4603A6982 for ; Thu, 26 Aug 2010 06:08:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,273,1280721600"; d="scan'208";a="204585223" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Aug 2010 09:09:04 -0400 X-IronPort-AV: E=Sophos;i="4.56,273,1280721600"; d="scan'208";a="508363397" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Aug 2010 09:09:03 -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: Thu, 26 Aug 2010 15:08:50 +0200 Message-ID: In-Reply-To: <20100826130016.GA5691@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] FW: DISCUSS: netconf charter Thread-Index: ActFHrHbzBQVgcCHSamDbbThtJguoQAAQrVw References: <20100825092622.GA70538@elstar.local><80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net><20100825160205.GA2514@elstar.local><20100825215213.GA2857@elstar.local><4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> From: "Romascanu, Dan (Dan)" To: "Juergen Schoenwaelder" , "Andy Bierman" Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:08:34 -0000 In the latest news - Russ found the one word change suggested by Juergen as acceptable.=20 Dan =20 > -----Original Message----- > From: netconf-bounces@ietf.org=20 > [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, August 26, 2010 4:00 PM > To: Andy Bierman > Cc: netconf > Subject: Re: [Netconf] FW: DISCUSS: netconf charter >=20 > On Thu, Aug 26, 2010 at 01:46:42PM +0200, Andy Bierman wrote: >=20 > [...] > =20 > > Or we can leave this as am implementation detail like we decided at=20 > > the last IETF. Operators will configure their systems=20 > correctly, for=20 > > their particular environment. There may not be a 1-name-fits-all=20 > > solution, so we should not gate success or failure on solving this=20 > > non-NETCONF-specific problem. >=20 > Andy, >=20 > the ISMS WG has gone through all this and the result is that=20 > it is configurable whether you want to distinguish ssh:foo=20 > from tls:foo or not. So the decision rests with the operator. >=20 > I think it would be good to provide a similar configuration=20 > option in NETCONF land and I would not mind if this would be=20 > spelled out as a requirements that the WG is to document as=20 > part of the solution document. >=20 > That said, only the IESG knows whether this is so important=20 > that it needs to be required in the charter - and this is=20 > what this thread is about. Perhaps they were even hinting at=20 > something totally different. > I hope we will know by the end of the day. >=20 > /js >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 From wjhns1@hardakers.net Thu Aug 26 06:40:11 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5433A697A for ; Thu, 26 Aug 2010 06:40:11 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joBdASXSs-xX for ; Thu, 26 Aug 2010 06:40:10 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id 3ACC03A698C for ; Thu, 26 Aug 2010 06:40:10 -0700 (PDT) Received: from localhost (wjh.hardakers.net [10.0.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id 0A1EC980D5; Thu, 26 Aug 2010 06:40:42 -0700 (PDT) From: Wes Hardaker To: Andy Bierman Organization: Sparta References: <20100825092622.GA70538@elstar.local> <80A0822C5E9A4440A5117C2F4CD36A64DD0C78@DEMUEXC006.nsn-intra.net> <20100825160205.GA2514@elstar.local> <20100825215213.GA2857@elstar.local> <4C765422.2000700@andybierman.com> Date: Thu, 26 Aug 2010 06:40:41 -0700 In-Reply-To: <4C765422.2000700@andybierman.com> (Andy Bierman's message of "Thu, 26 Aug 2010 04:46:42 -0700") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netconf Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:40:11 -0000 >>>>> On Thu, 26 Aug 2010 04:46:42 -0700, Andy Bierman said: AB> The intent of the current charter text was that NETCONF NACM will AB> authorize access for subsets of the entire conceptual content-store, AB> for a user which has already been authenticated. Andy, FYI I think we're in agreement. The only question left is "are you going to define what a user is?" since that hasn't been done yet (and you'll be make decisions about it). Not standardizing that and letting it be implementation specific, as you said, is certainly an option. -- Wes Hardaker Cobham Analytic Solutions From mark.scott@ericsson.com Thu Aug 26 09:29:32 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 098313A69EB for ; Thu, 26 Aug 2010 09:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLM267FIJx3N for ; Thu, 26 Aug 2010 09:29:31 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 2356A3A69E2 for ; Thu, 26 Aug 2010 09:29:31 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o7QGa9GZ015771; Thu, 26 Aug 2010 11:36:12 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.1.39]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 26 Aug 2010 12:29:37 -0400 From: Mark Scott To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Date: Thu, 26 Aug 2010 12:29:37 -0400 Thread-Topic: [Netconf] FW: DISCUSS: netconf charter Thread-Index: ActFHvpCPKgHxjtyQBOtlsUgZhxYqwAFlNmw Message-ID: <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> In-Reply-To: <20100826.150236.147065199.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: 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] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 16:29:32 -0000 Juergen, +1 more for a configuration option in NETCONF. On assumption we want to reuse ISMS approach can you direct me to those spe= cific requirements? (e.g. is this configurable per user/principal? per gro= up? per transport? per server?) I had a quick look through the USM and per-transport docs but couldn't loca= te the specifics. thank you, Mark -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf = Of Martin Bjorklund Sent: August-26-10 9:03 AM To: j.schoenwaelder@jacobs-university.de Cc: netconf@ietf.org Subject: Re: [Netconf] FW: DISCUSS: netconf charter Juergen Schoenwaelder wrote: > On Thu, Aug 26, 2010 at 01:46:42PM +0200, Andy Bierman wrote: >=20 > [...] > =20 > > Or we can leave this as am implementation detail like we decided at the > > last IETF. Operators will configure their systems correctly, for their > > particular environment. There may not be a 1-name-fits-all solution, > > so we should not gate success or failure on solving this non-NETCONF-sp= ecific > > problem. >=20 > Andy, >=20 > the ISMS WG has gone through all this and the result is that it is > configurable whether you want to distinguish ssh:foo from tls:foo or > not. So the decision rests with the operator. >=20 > I think it would be good to provide a similar configuration option in > NETCONF land and I would not mind if this would be spelled out as a > requirements that the WG is to document as part of the solution > document. +1 /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From j.schoenwaelder@jacobs-university.de Thu Aug 26 10:18:23 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ECA93A6AAE for ; Thu, 26 Aug 2010 10:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.934 X-Spam-Level: X-Spam-Status: No, score=-101.934 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLzuVO9eNty2 for ; Thu, 26 Aug 2010 10:18:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id ABCF73A68DA for ; Thu, 26 Aug 2010 10:18:20 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3E82C0011; Thu, 26 Aug 2010 19:18:52 +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 kZafvFkV1iF4; Thu, 26 Aug 2010 19:18:51 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8213C0002; Thu, 26 Aug 2010 19:18:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2F7DB14663A3; Thu, 26 Aug 2010 19:18:27 +0200 (CEST) Date: Thu, 26 Aug 2010 19:18:27 +0200 From: Juergen Schoenwaelder To: Mark Scott Message-ID: <20100826171825.GA7112@elstar.local> Mail-Followup-To: Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 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, 26 Aug 2010 17:18:24 -0000 On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: > On assumption we want to reuse ISMS approach can you direct me to > those specific requirements? (e.g. is this configurable per > user/principal? per group? per transport? per server?) > > I had a quick look through the USM and per-transport docs but > couldn't locate the specifics. The VACM [RFC3415] maps a (securityModel, securityName) tuple it into a group. This means for the security models USM, CSM, and TSM, the tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different groups (but they can also map to the same group of course). For secure transports such as TLS or SSH, the Transport Security Model (TSM) [RFC5591] provides a prefixing mechanism where security names of a given secure transport may be prefixed by the TSM, that is VACM will end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via ssh or tls. This prefixing can be turned off so that that both tuples become (tsm, joe), regardless which transport joe is using. The configuration choice is rather coarse grained - you either get the prefixes for all secure transports or none of them. Hence, if it is necessary to distinguish joe coming in over different transports, you have to enable the prefixing and that might lead to additional VACM rules to achieve the proper mapping into VACM groups. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From dromasca@avaya.com Thu Aug 26 10:43:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A943A68CD for ; Thu, 26 Aug 2010 10:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68IeF5+0jyqA for ; Thu, 26 Aug 2010 10:43:35 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id CDC9F3A689E for ; Thu, 26 Aug 2010 10:43:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,275,1280721600"; d="scan'208";a="204642211" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 26 Aug 2010 13:44:06 -0400 X-IronPort-AV: E=Sophos;i="4.56,275,1280721600"; d="scan'208";a="502272260" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Aug 2010 13:43:50 -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: Thu, 26 Aug 2010 19:43:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering of NETCONF was approved ... Thread-Index: ActFRjDMRZfZ+IhHR4efB7tC+EpUBQ== From: "Romascanu, Dan (Dan)" To: "netconf" Subject: [Netconf] Rechartering of NETCONF was approved ... X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:43:36 -0000 ... by the IESG with the one word replacement suggested by Juergen. The announcement will go out next week. Thanks for the support and good luck in working on the rechartered items. Dan From ietf@andybierman.com Thu Aug 26 22:44:28 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4B43A6A74 for ; Thu, 26 Aug 2010 22:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gG0Fr5YC4hS for ; Thu, 26 Aug 2010 22:44:26 -0700 (PDT) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id 9F4E23A6832 for ; Thu, 26 Aug 2010 22:44:25 -0700 (PDT) Received: (qmail 17511 invoked from network); 27 Aug 2010 05:44:57 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 26 Aug 2010 22:44:57 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: zn7Km98VM1n.0tRko69hz6Kx5euSyXO.vJ7y6qlVx6lyLEg AiHl.56iuO7S3gv9LjVzULndfWVQoLdGT18Yc1.iflkPGiP4EktYM.bCkbJ. hhLpTcKyenSPxfytASnpf15F9ugScQ_k8h0XMy6rbpsd0QNJT0YbOuct2FRE Cy8k0WgCMSVRk5BZydZxaVbdLcqVO6e9I9Go.2RYqjHp34QOttExOwWfQRxn cq0aCfuGbzF1lbrhjj3aQI_XfzrCQiMMcM2uayZw9BoAADWaJQbXydkJhyHW ilzTn X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C7750D6.7060502@andybierman.com> Date: Thu, 26 Aug 2010 22:44:54 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> In-Reply-To: <20100826171825.GA7112@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 05:44:28 -0000 On 08/26/2010 10:18 AM, Juergen Schoenwaelder wrote: > On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: > >> On assumption we want to reuse ISMS approach can you direct me to >> those specific requirements? (e.g. is this configurable per >> user/principal? per group? per transport? per server?) >> >> I had a quick look through the USM and per-transport docs but >> couldn't locate the specifics. > > The VACM [RFC3415] maps a (securityModel, securityName) tuple it into > a group. This means for the security models USM, CSM, and TSM, the > tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different > groups (but they can also map to the same group of course). > > For secure transports such as TLS or SSH, the Transport Security Model > (TSM) [RFC5591] provides a prefixing mechanism where security names of > a given secure transport may be prefixed by the TSM, that is VACM will > end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via > ssh or tls. This prefixing can be turned off so that that both tuples > become (tsm, joe), regardless which transport joe is using. > > The configuration choice is rather coarse grained - you either get the > prefixes for all secure transports or none of them. Hence, if it is > necessary to distinguish joe coming in over different transports, you > have to enable the prefixing and that might lead to additional VACM > rules to achieve the proper mapping into VACM groups. > IMO, this is a slippery slope. We are better off keeping the access control model as simple as possible, not as configurable and fancy as possible. That's how VACM got out of control. That's how lots of complicated SMIv2 MIB modules got out of control. Is this sort of what you are talking about? -- in concrete YANG terms: Add to nacm.yang somewhere: import ietf-netconf-monitoring { prefix nmon; } list transport-user-to-group { description "List of mapping entries. Each entry conceptually assigns a particular NETCONF transport type and a user identity tuple to a NACM group. The server will process this list in order, until there are no more entries, or until a transport type and user identity match the current NETCONF request being processed by the server."; key "transport-ref user-identity"; ordered-by user; leaf transport-ref { description "Identifies the NETCONF transport for this entry. The special string '*' indicates that this entry is associated with all supported NETCONF transport mappings."; type union { type string { pattern "\*"; } type identityref { base nmon:transport; } } } leaf user-identity { description "Identifies the user/principal associated with this entry."; type union { // TBD: need to define constrained list of user identity types // (strings w/ patterns?) type string { pattern "...."; } type string { pattern "...."; } type string { length "1..max"; } } } leaf group-name { description "The group assigned to this transport/user-identity mapping."; mandatory true; type leafref { path /nacm/groups/group/name; require-instance false; } } } > /js > Andy From j.schoenwaelder@jacobs-university.de Thu Aug 26 23:56:37 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31CDF3A6B60 for ; Thu, 26 Aug 2010 23:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.937 X-Spam-Level: X-Spam-Status: No, score=-101.937 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZbv-XdAkG+d for ; Thu, 26 Aug 2010 23:56:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B38923A6B21 for ; Thu, 26 Aug 2010 23:56:35 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48637C0014; Fri, 27 Aug 2010 08:57:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id esDKZabcC2tv; Fri, 27 Aug 2010 08:57:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6E0F6C0002; Fri, 27 Aug 2010 08:57:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B6F2E1466FDA; Fri, 27 Aug 2010 08:56:45 +0200 (CEST) Date: Fri, 27 Aug 2010 08:56:45 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100827065644.GA8237@elstar.local> Mail-Followup-To: Andy Bierman , Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> <4C7750D6.7060502@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7750D6.7060502@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 06:56:37 -0000 On Fri, Aug 27, 2010 at 07:44:54AM +0200, Andy Bierman wrote: > On 08/26/2010 10:18 AM, Juergen Schoenwaelder wrote: > > On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: > > > >> On assumption we want to reuse ISMS approach can you direct me to > >> those specific requirements? (e.g. is this configurable per > >> user/principal? per group? per transport? per server?) > >> > >> I had a quick look through the USM and per-transport docs but > >> couldn't locate the specifics. > > > > The VACM [RFC3415] maps a (securityModel, securityName) tuple it into > > a group. This means for the security models USM, CSM, and TSM, the > > tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different > > groups (but they can also map to the same group of course). > > > > For secure transports such as TLS or SSH, the Transport Security Model > > (TSM) [RFC5591] provides a prefixing mechanism where security names of > > a given secure transport may be prefixed by the TSM, that is VACM will > > end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via > > ssh or tls. This prefixing can be turned off so that that both tuples > > become (tsm, joe), regardless which transport joe is using. > > > > The configuration choice is rather coarse grained - you either get the > > prefixes for all secure transports or none of them. Hence, if it is > > necessary to distinguish joe coming in over different transports, you > > have to enable the prefixing and that might lead to additional VACM > > rules to achieve the proper mapping into VACM groups. > > IMO, this is a slippery slope. We are better off keeping > the access control model as simple as possible, not as configurable > and fancy as possible. That's how VACM got out of control. > That's how lots of complicated SMIv2 MIB modules got out of control. >From those configs I have seen, I believe that the security name to group name mapping is the most used part of VACM. People really get scared when they look at view tree family masks. - I believe we need a user name to group mapping to support a role based access control model. - I believe such a user name to group mapping should support the RADIUS Management-Policy-Id attribute [RFC5607] so that the user name to group mapping can be maintained on a RADIUS server. - If we seriously support different authentication realms, we might provide a mechanism to deal with user name conflicts; a suitable default makes this a no brainer for most people. However, given the discussion we had recently on the SSH transport, we might choose to simply mark this as implementation dependent since there is already an implementation dependent mapping from the SSH authenticated user name to the system's account name; so colliding user names in different authentication realms could potentially be resolved at this 'layer'. Perhaps it is time to note down requirements. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietf@andybierman.com Fri Aug 27 09:25:42 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5047F3A6A1A for ; Fri, 27 Aug 2010 09:25:42 -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.314, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp09NIvSoDDG for ; Fri, 27 Aug 2010 09:25:41 -0700 (PDT) Received: from smtp108.sbc.mail.gq1.yahoo.com (smtp108.sbc.mail.gq1.yahoo.com [67.195.14.111]) by core3.amsl.com (Postfix) with SMTP id 1840D3A69E1 for ; Fri, 27 Aug 2010 09:25:41 -0700 (PDT) Received: (qmail 24407 invoked from network); 27 Aug 2010 16:26:10 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 27 Aug 2010 09:26:10 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: cOT.YgcVM1nzRgXNJRNxTWnj3mJYa6Z4tL5oxY22tNsDPFn 6dW2GT6FGtE6HdgzyOM4QZ4NfzVcVF0jsghcVCmSeshhoTJU.y.8C_1nTqza RfPuBfELhCigMp365vLBjP7rfY2bR2SA.x.1YIZ7GwX1f9f_5HSbW0vH6nUS 20TdUWVjioqwtGc4KPunjRi2Lf.E4ntmr0tAvYtu3D5Ru6qlWfHJNBVDslY6 BvcmQYulD9Eq0w2sdYdvCl2mbbpdZ X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C77E71C.9080200@andybierman.com> Date: Fri, 27 Aug 2010 09:26:04 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> <4C7750D6.7060502@andybierman.com> <20100827065644.GA8237@elstar.local> In-Reply-To: <20100827065644.GA8237@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:25:42 -0000 On 08/26/2010 11:56 PM, Juergen Schoenwaelder wrote: > On Fri, Aug 27, 2010 at 07:44:54AM +0200, Andy Bierman wrote: >> On 08/26/2010 10:18 AM, Juergen Schoenwaelder wrote: >>> On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: >>> >>>> On assumption we want to reuse ISMS approach can you direct me to >>>> those specific requirements? (e.g. is this configurable per >>>> user/principal? per group? per transport? per server?) >>>> >>>> I had a quick look through the USM and per-transport docs but >>>> couldn't locate the specifics. >>> >>> The VACM [RFC3415] maps a (securityModel, securityName) tuple it into >>> a group. This means for the security models USM, CSM, and TSM, the >>> tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different >>> groups (but they can also map to the same group of course). >>> >>> For secure transports such as TLS or SSH, the Transport Security Model >>> (TSM) [RFC5591] provides a prefixing mechanism where security names of >>> a given secure transport may be prefixed by the TSM, that is VACM will >>> end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via >>> ssh or tls. This prefixing can be turned off so that that both tuples >>> become (tsm, joe), regardless which transport joe is using. >>> >>> The configuration choice is rather coarse grained - you either get the >>> prefixes for all secure transports or none of them. Hence, if it is >>> necessary to distinguish joe coming in over different transports, you >>> have to enable the prefixing and that might lead to additional VACM >>> rules to achieve the proper mapping into VACM groups. >> >> IMO, this is a slippery slope. We are better off keeping >> the access control model as simple as possible, not as configurable >> and fancy as possible. That's how VACM got out of control. >> That's how lots of complicated SMIv2 MIB modules got out of control. > >>From those configs I have seen, I believe that the security name to > group name mapping is the most used part of VACM. People really get > scared when they look at view tree family masks. > > - I believe we need a user name to group mapping to support a role based > access control model. > > - I believe such a user name to group mapping should support the > RADIUS Management-Policy-Id attribute [RFC5607] so that the user > name to group mapping can be maintained on a RADIUS server. > > - If we seriously support different authentication realms, we might > provide a mechanism to deal with user name conflicts; a suitable > default makes this a no brainer for most people. > > However, given the discussion we had recently on the SSH transport, > we might choose to simply mark this as implementation dependent > since there is already an implementation dependent mapping from the > SSH authenticated user name to the system's account name; so > colliding user names in different authentication realms could > potentially be resolved at this 'layer'. > > Perhaps it is time to note down requirements. Are you volunteering? Sometimes in this WG (and others) it is very easy for people to rattle of a bunch of nice-to-have requirements for a charter item, and then disappear from the WG. Multiple people have to do the work: - agree on the concepts - agree on the details - write the text - review the text - repeat over many revisions of the draft(s). We spend an awful amount of time and energy hammering out nice-to-have, optional-to-implement, bells and whistles. IMO, we need to rapidly deploy a must-have framework, and get domain-specific WGs (and vendors) to fill it in with real config knobs. NACM should not block other work, such as interfaces and system modules either. Since we can't make tough decisions, we throw every bell and every hood ornament we can think of into every module. This may be more satisfying to the WG at the time, but I am not so sure it helps deployment and interoperability to spend so much time on optional features. > > /js > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 27 11:15:36 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE4213A6A28 for ; Fri, 27 Aug 2010 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.941 X-Spam-Level: X-Spam-Status: No, score=-101.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnUJuayfF14K for ; Fri, 27 Aug 2010 11:15:34 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 359DA3A6A1D for ; Fri, 27 Aug 2010 11:15:34 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 99D92C0019; Fri, 27 Aug 2010 20:16:05 +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 KXSQKQPAPRZ7; Fri, 27 Aug 2010 20:16:03 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC70DC0018; Fri, 27 Aug 2010 20:16:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B18E5146837E; Fri, 27 Aug 2010 20:15:43 +0200 (CEST) Date: Fri, 27 Aug 2010 20:15:43 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100827181543.GA10644@elstar.local> Mail-Followup-To: Andy Bierman , Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> <4C7750D6.7060502@andybierman.com> <20100827065644.GA8237@elstar.local> <4C77E71C.9080200@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C77E71C.9080200@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:15:36 -0000 On Fri, Aug 27, 2010 at 06:26:04PM +0200, Andy Bierman wrote: > On 08/26/2010 11:56 PM, Juergen Schoenwaelder wrote: > > On Fri, Aug 27, 2010 at 07:44:54AM +0200, Andy Bierman wrote: > >> On 08/26/2010 10:18 AM, Juergen Schoenwaelder wrote: > >>> On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: > >>> > >>>> On assumption we want to reuse ISMS approach can you direct me to > >>>> those specific requirements? (e.g. is this configurable per > >>>> user/principal? per group? per transport? per server?) > >>>> > >>>> I had a quick look through the USM and per-transport docs but > >>>> couldn't locate the specifics. > >>> > >>> The VACM [RFC3415] maps a (securityModel, securityName) tuple it into > >>> a group. This means for the security models USM, CSM, and TSM, the > >>> tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different > >>> groups (but they can also map to the same group of course). > >>> > >>> For secure transports such as TLS or SSH, the Transport Security Model > >>> (TSM) [RFC5591] provides a prefixing mechanism where security names of > >>> a given secure transport may be prefixed by the TSM, that is VACM will > >>> end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via > >>> ssh or tls. This prefixing can be turned off so that that both tuples > >>> become (tsm, joe), regardless which transport joe is using. > >>> > >>> The configuration choice is rather coarse grained - you either get the > >>> prefixes for all secure transports or none of them. Hence, if it is > >>> necessary to distinguish joe coming in over different transports, you > >>> have to enable the prefixing and that might lead to additional VACM > >>> rules to achieve the proper mapping into VACM groups. > >> > >> IMO, this is a slippery slope. We are better off keeping > >> the access control model as simple as possible, not as configurable > >> and fancy as possible. That's how VACM got out of control. > >> That's how lots of complicated SMIv2 MIB modules got out of control. > > > >>From those configs I have seen, I believe that the security name to > > group name mapping is the most used part of VACM. People really get > > scared when they look at view tree family masks. > > > > - I believe we need a user name to group mapping to support a role based > > access control model. > > > > - I believe such a user name to group mapping should support the > > RADIUS Management-Policy-Id attribute [RFC5607] so that the user > > name to group mapping can be maintained on a RADIUS server. > > > > - If we seriously support different authentication realms, we might > > provide a mechanism to deal with user name conflicts; a suitable > > default makes this a no brainer for most people. > > > > However, given the discussion we had recently on the SSH transport, > > we might choose to simply mark this as implementation dependent > > since there is already an implementation dependent mapping from the > > SSH authenticated user name to the system's account name; so > > colliding user names in different authentication realms could > > potentially be resolved at this 'layer'. > > > > Perhaps it is time to note down requirements. > > Are you volunteering? > Sometimes in this WG (and others) it is very easy for people to > rattle of a bunch of nice-to-have requirements for a charter item, > and then disappear from the WG. > > Multiple people have to do the work: > - agree on the concepts > - agree on the details > - write the text > - review the text > - repeat over many revisions of the draft(s). > > We spend an awful amount of time and energy hammering out nice-to-have, > optional-to-implement, bells and whistles. IMO, we need to rapidly deploy > a must-have framework, and get domain-specific WGs (and vendors) to > fill it in with real config knobs. NACM should not block other work, > such as interfaces and system modules either. > > Since we can't make tough decisions, we throw every bell and every > hood ornament we can think of into every module. This may be more > satisfying to the WG at the time, but I am not so sure it helps > deployment and interoperability to spend so much time on optional features. If your rant is targeting me (which I assume since I took part in the drafting of the charter text), then let me tell you that I strongly disagree with your statement. That said, it would be nice to know what you think the "nice-to-have requirements for a charter item" are. Actually, I do not understand the your charter rant at all; the ACM stuff is pretty much the text your had on your slide in Maastricht. /js (whose motivation to help just dropped significantly) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Fri Aug 27 13:20:53 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B513A3A687B for ; Fri, 27 Aug 2010 13:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.618 X-Spam-Level: X-Spam-Status: No, score=-6.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIPIzYdGjDf9 for ; Fri, 27 Aug 2010 13:20:52 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with ESMTP id 7F07E3A67F4 for ; Fri, 27 Aug 2010 13:20:49 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKTHgePqoHXstYSnHAfNKJHq6VLw7InXm2@postini.com; Fri, 27 Aug 2010 13:21:25 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.2.254.0; Fri, 27 Aug 2010 13:17:14 -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 o7RKHDU98111; Fri, 27 Aug 2010 13:17:13 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id o7RJwCjO042547; Fri, 27 Aug 2010 19:58:13 GMT (envelope-from phil@idle.juniper.net) Message-ID: <201008271958.o7RJwCjO042547@idle.juniper.net> To: Andy Bierman In-Reply-To: <4C77E71C.9080200@andybierman.com> Date: Fri, 27 Aug 2010 15:58:12 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:20:54 -0000 Andy Bierman writes: >We spend an awful amount of time and energy hammering out nice-to-have, >optional-to-implement, bells and whistles. IMO, we need to rapidly deploy >a must-have framework, and get domain-specific WGs (and vendors) to >fill it in with real config knobs. So we're after "quick and dirty"? Or is "rapidly" supposed to be read in the context of IETF timelines? >NACM should not block other work, >such as interfaces and system modules either. NACM should be orthogonal to other work. >Since we can't make tough decisions, we throw every bell and every >hood ornament we can think of into every module. This may be more >satisfying to the WG at the time, but I am not so sure it helps >deployment and interoperability to spend so much time on optional features. I completely disagree. YANG gives many tools to handle optional parts (augment, features, etc), so it's easier to say "we want to make this common in our model but not everyone needs to do it" or "this part is left for future work". But part of creating useful models is understanding how and where folks will need to extend and adapt it, so having this list of "hood ornaments" has a value to the modeler. If you want to support TACACS, RADIUS, and LDAP-based authentication, you need to understand how these are used in the real world. Leaving it for the TACACS modeler to come in later and retrofit their model into your framework can be disasterous. In addition, we have found that many times what we think are areas of proprietary behaviour are, in fact, rather common among the various implementations, so developing the list of "bells" may enhance the WG's understanding of what exactly they are modeling. Thanks, Phil (who is definitely not volunteering) From ietf@andybierman.com Fri Aug 27 13:35:13 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3CC3A68AF for ; Fri, 27 Aug 2010 13:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJO0Wyip2ztt for ; Fri, 27 Aug 2010 13:35:11 -0700 (PDT) Received: from smtp103.sbc.mail.gq1.yahoo.com (smtp103.sbc.mail.gq1.yahoo.com [67.195.15.62]) by core3.amsl.com (Postfix) with SMTP id 0A07E3A687E for ; Fri, 27 Aug 2010 13:35:11 -0700 (PDT) Received: (qmail 65911 invoked from network); 27 Aug 2010 20:35:40 -0000 Received: from [192.168.0.9] (ietf@75.84.164.152 with plain) by smtp103.sbc.mail.gq1.yahoo.com with SMTP; 27 Aug 2010 13:35:40 -0700 PDT X-Yahoo-SMTP: Z6xhxCCswBAlhcxjVNwaQtp4EKpLdTUUf5Nx_pGy81o- X-YMail-OSG: GA6fuDMVM1mL1.qo2PJx_5ut9Mxx1oJTnBxIYG5P2iHXsNO 5rQwOliJRTYrwiMqB5lafU0EO3ZBFaA3VL8gVFC3DUpba0Qbzaso7aebA4MT Jt7_BH.Qxftr1vCc.9aaItzHeU5xtNCBqOkk3A4ke2MkvSGr8pObhTyfyYXH 3EYmHuqzeADhxqeZqcX1pqmvAqLLJSLpUCU6bGqDY5UX98xOS1_xj_ur2Zjg 1OHAQFZ0zZ0nT0Edjwdr.kM2cbKJtdJ7djqz.zDuisB5m0G3s3aD7UJkwlU4 Pv.dF X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C782195.7070808@andybierman.com> Date: Fri, 27 Aug 2010 13:35:33 -0700 From: Andy Bierman User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> <4C7750D6.7060502@andybierman.com> <20100827065644.GA8237@elstar.local> <4C77E71C.9080200@andybierman.com> <20100827181543.GA10644@elstar.local> In-Reply-To: <20100827181543.GA10644@elstar.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 20:35:13 -0000 On 08/27/2010 11:15 AM, Juergen Schoenwaelder wrote: > On Fri, Aug 27, 2010 at 06:26:04PM +0200, Andy Bierman wrote: >> On 08/26/2010 11:56 PM, Juergen Schoenwaelder wrote: >>> On Fri, Aug 27, 2010 at 07:44:54AM +0200, Andy Bierman wrote: >>>> On 08/26/2010 10:18 AM, Juergen Schoenwaelder wrote: >>>>> On Thu, Aug 26, 2010 at 06:29:37PM +0200, Mark Scott wrote: >>>>> >>>>>> On assumption we want to reuse ISMS approach can you direct me to >>>>>> those specific requirements? (e.g. is this configurable per >>>>>> user/principal? per group? per transport? per server?) >>>>>> >>>>>> I had a quick look through the USM and per-transport docs but >>>>>> couldn't locate the specifics. >>>>> >>>>> The VACM [RFC3415] maps a (securityModel, securityName) tuple it into >>>>> a group. This means for the security models USM, CSM, and TSM, the >>>>> tuples (usm, joe), (csm, joe), (tsm, joe) may map to a different >>>>> groups (but they can also map to the same group of course). >>>>> >>>>> For secure transports such as TLS or SSH, the Transport Security Model >>>>> (TSM) [RFC5591] provides a prefixing mechanism where security names of >>>>> a given secure transport may be prefixed by the TSM, that is VACM will >>>>> end up with (tsm, ssh:joe) and (tsm, tls:joe) if joe authenticates via >>>>> ssh or tls. This prefixing can be turned off so that that both tuples >>>>> become (tsm, joe), regardless which transport joe is using. >>>>> >>>>> The configuration choice is rather coarse grained - you either get the >>>>> prefixes for all secure transports or none of them. Hence, if it is >>>>> necessary to distinguish joe coming in over different transports, you >>>>> have to enable the prefixing and that might lead to additional VACM >>>>> rules to achieve the proper mapping into VACM groups. >>>> >>>> IMO, this is a slippery slope. We are better off keeping >>>> the access control model as simple as possible, not as configurable >>>> and fancy as possible. That's how VACM got out of control. >>>> That's how lots of complicated SMIv2 MIB modules got out of control. >>> >>> >From those configs I have seen, I believe that the security name to >>> group name mapping is the most used part of VACM. People really get >>> scared when they look at view tree family masks. >>> >>> - I believe we need a user name to group mapping to support a role based >>> access control model. >>> >>> - I believe such a user name to group mapping should support the >>> RADIUS Management-Policy-Id attribute [RFC5607] so that the user >>> name to group mapping can be maintained on a RADIUS server. >>> >>> - If we seriously support different authentication realms, we might >>> provide a mechanism to deal with user name conflicts; a suitable >>> default makes this a no brainer for most people. >>> >>> However, given the discussion we had recently on the SSH transport, >>> we might choose to simply mark this as implementation dependent >>> since there is already an implementation dependent mapping from the >>> SSH authenticated user name to the system's account name; so >>> colliding user names in different authentication realms could >>> potentially be resolved at this 'layer'. >>> >>> Perhaps it is time to note down requirements. >> >> Are you volunteering? >> Sometimes in this WG (and others) it is very easy for people to >> rattle of a bunch of nice-to-have requirements for a charter item, >> and then disappear from the WG. >> >> Multiple people have to do the work: >> - agree on the concepts >> - agree on the details >> - write the text >> - review the text >> - repeat over many revisions of the draft(s). >> >> We spend an awful amount of time and energy hammering out nice-to-have, >> optional-to-implement, bells and whistles. IMO, we need to rapidly deploy >> a must-have framework, and get domain-specific WGs (and vendors) to >> fill it in with real config knobs. NACM should not block other work, >> such as interfaces and system modules either. >> >> Since we can't make tough decisions, we throw every bell and every >> hood ornament we can think of into every module. This may be more >> satisfying to the WG at the time, but I am not so sure it helps >> deployment and interoperability to spend so much time on optional features. > > If your rant is targeting me (which I assume since I took part in the > drafting of the charter text), then let me tell you that I strongly > disagree with your statement. > > That said, it would be nice to know what you think the "nice-to-have > requirements for a charter item" are. Actually, I do not understand > the your charter rant at all; the ACM stuff is pretty much the text > your had on your slide in Maastricht. > The rant is not directed at you or your charter text. Are you offering to write a draft or provide text for NACM? Does the WG even agree to these new requirements? NMS developers are still hesitant to use optional-to-implement server APIs, just like in SNMP days. Yet we are very quick to use lots of optional-to-implement definitions in the YANG data models and protocols. I think this level of effort should only be spent on mandatory-to-implement YANG content. We would get something done a lot faster, and time is a factor we should not ignore. IMO, all the extra time could be eliminated by using optional-to-implement as a last resort, instead of the first choice. We will agree on much less, and the YANG modules will be smaller. The NMS developers will also be more likely to use the finished product. > /js (whose motivation to help just dropped significantly) > Andy From j.schoenwaelder@jacobs-university.de Fri Aug 27 15:13:30 2010 Return-Path: X-Original-To: netconf@core3.amsl.com Delivered-To: netconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D6813A687E for ; Fri, 27 Aug 2010 15:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.944 X-Spam-Level: X-Spam-Status: No, score=-101.944 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXXucIUP3PuI for ; Fri, 27 Aug 2010 15:13:29 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC4063A687B for ; Fri, 27 Aug 2010 15:13:28 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FA4CC0017; Sat, 28 Aug 2010 00:14:00 +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 3JBibFC4VeiR; Sat, 28 Aug 2010 00:13:59 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5344C0002; Sat, 28 Aug 2010 00:13:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EC04214687AA; Sat, 28 Aug 2010 00:13:39 +0200 (CEST) Date: Sat, 28 Aug 2010 00:13:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20100827221339.GB10842@elstar.local> Mail-Followup-To: Andy Bierman , Mark Scott , Martin Bjorklund , "netconf@ietf.org" References: <4C765422.2000700@andybierman.com> <20100826130016.GA5691@elstar.local> <20100826.150236.147065199.mbj@tail-f.com> <75C89D709A9670428520E1CF8DD1344F208ED01D85@EUSAACMS0714.eamcs.ericsson.se> <20100826171825.GA7112@elstar.local> <4C7750D6.7060502@andybierman.com> <20100827065644.GA8237@elstar.local> <4C77E71C.9080200@andybierman.com> <20100827181543.GA10644@elstar.local> <4C782195.7070808@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C782195.7070808@andybierman.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "netconf@ietf.org" Subject: Re: [Netconf] FW: DISCUSS: netconf charter X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 22:13:30 -0000 On Fri, Aug 27, 2010 at 10:35:33PM +0200, Andy Bierman wrote: > The rant is not directed at you or your charter text. > Are you offering to write a draft or provide text for NACM? > Does the WG even agree to these new requirements? I have been trying to be constructive but I obviously failed badly. And in case you forgot, the chairs have the task to determine concensus in the IETF. /js (who prefers to go to sleep instead of continuing this thread) -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wwwrun@core3.amsl.com Tue Aug 31 11:05:38 2010 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 287343A68DF; Tue, 31 Aug 2010 11:05:37 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100831180538.287343A68DF@core3.amsl.com> Date: Tue, 31 Aug 2010 11:05:38 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] WG Action: RECHARTER: Network Configuration (netconf) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 18:05:38 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Network Configuration (netconf) --------------------------------------------------- Current Status: Active Working Group Chairs: Bert Wijnen (bertietf@bwijnen.net) Mehmet Ersue (mehmet.ersue@nsn.com) Operations and Management Area Directors: Dan Romascanu (dromasca@avaya.com) Ronald Bonica (rbonica@juniper.net) Operations and Management Area Advisor: Dan Romascanu (dromasca@avaya.com) 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. 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. NETCONF implementations have shown that the specification in RFC4741 is not 100% clear and has lead to different interpretations and implementations. Also some errors have been uncovered. So the WG will do an rfc4741bis with following constraints: - bug fixes are to be done - clarifications can be done - extensions can be done only when needed to fix bugs or inconsistencies (i.e. we are not doing a NETCONF V2) - The work was started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). 2. A technical errata has been posted on rfc4742. The work on rfc4741bis also uncovered some additional fixes/clarifications that need to be made to rfc4742, the WG has been working on rfc4742bis and is nearly done with this work item. 3. Netconf Access Control Model (NACM) Requirements and Solution. There is a need for standard mechanisms to restrict NETCONF protocol access for authenticated users to a pre- configured (by operator) subset of all available NETCONF operations and content. The WG will produce a document which identifies the access control requirements specific to the NETCONF protocol, as defined in [4741bis]. This document will also provide a standard YANG data model which addresses these requirements. It is possible that the WG will not reach solution consensus on every possible requirement identified in the document. In this case, it is expected that the solution will evolve over time to meet the the remaining unmet requirements. 4. The NETCONF server may want to notify interested clients about particular NETCONF protocol/server events. The WG will work on a NETCONF specific YANG module(s) to define suitable notifications. 5. As implementation and deployment experience gained with the NETCONF monitoring data model, the WG may revise the NETCONF monitoring data model to add additional objects that can be used to check the status of the server and to discover additional information about the server implementation. The WG may choose to revise the NETCONF monitoring data model. Goals and Milestones: Aug 2010 WG Last Call on rfc4741bis Aug 2010 Send with-defaults to IESG for consideration as Proposed Standard Sep 2010 first WG draft (rev 00) on NACM posted Sep 2010 rfc4741bis to IESG for consideration as Proposed Standard Sep 2010 Send rfc4742bis to IESG for consideration as proposed Standard Sep 2010 first WG draft (rev 00) on NETCONF specific YANG modules posted Jan 2011 WGLC for NACM document Jan 2011 WGLC for NETCONF specific notifications document Mar 2011 (if needed last) WGLC for NACM document Mar 2011 (if needed last) WGLC for NETCONF specific notifications document Apr 2011 submit NACM document to IESG for consideration as Proposed Standard Apr 2011 submit NETCONF specific notifications document to IESG for consideration as Proposed Standard