From netconf-bounces@ietf.org Wed Jan 7 08:38:57 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F923A68FE; Wed, 7 Jan 2009 08:38:57 -0800 (PST) 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 9BCE33A6A2C for ; Wed, 7 Jan 2009 08:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 cn+-JpVV8Umj for ; Wed, 7 Jan 2009 08:38:55 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id AB9FA3A68FE for ; Wed, 7 Jan 2009 08:38:55 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 0eH71b00717dt5G53gejpu; Wed, 07 Jan 2009 16:38:43 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 0gei1b0130UQ6dC3ZgeiTv; Wed, 07 Jan 2009 16:38:43 +0000 From: "David B Harrington" To: "'Tomoyuki Iijima'" , References: <109392.47949.qm@web36704.mail.mud.yahoo.com> <4951CF6F.9080203@hitachi.com> Date: Wed, 7 Jan 2009 11:38:41 -0500 Message-ID: <02ac01c970e6$667a2640$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclljJ9YwqmnlvqWRGC02FNOa76CZwLThOyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4951CF6F.9080203@hitachi.com> Cc: '?? ??' , netconf@ietf.org Subject: Re: [Netconf] soap or ssh 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Tomoyuki Iijima > > [...] So, if you want to develop a NETCONF device which has > interoperability > with other NETCONF implementations, RFC 4741 says that you need to > support SSH transport mapping in addition to SOAP transport mapping. I think this is incorrect advice. if you want to develop a NETCONF device which has interoperability with other NETCONF implementations, RFC 4741 says that you need to support SSH transport mapping. Period. It does not say "in addition to SOAP transport mapping." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 7 08:38:57 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F923A68FE; Wed, 7 Jan 2009 08:38:57 -0800 (PST) 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 9BCE33A6A2C for ; Wed, 7 Jan 2009 08:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 cn+-JpVV8Umj for ; Wed, 7 Jan 2009 08:38:55 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id AB9FA3A68FE for ; Wed, 7 Jan 2009 08:38:55 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id 0eH71b00717dt5G53gejpu; Wed, 07 Jan 2009 16:38:43 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id 0gei1b0130UQ6dC3ZgeiTv; Wed, 07 Jan 2009 16:38:43 +0000 From: "David B Harrington" To: "'Tomoyuki Iijima'" , References: <109392.47949.qm@web36704.mail.mud.yahoo.com> <4951CF6F.9080203@hitachi.com> Date: Wed, 7 Jan 2009 11:38:41 -0500 Message-ID: <02ac01c970e6$667a2640$6905a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AclljJ9YwqmnlvqWRGC02FNOa76CZwLThOyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4951CF6F.9080203@hitachi.com> Cc: '?? ??' , netconf@ietf.org Subject: Re: [Netconf] soap or ssh 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Tomoyuki Iijima > > [...] So, if you want to develop a NETCONF device which has > interoperability > with other NETCONF implementations, RFC 4741 says that you need to > support SSH transport mapping in addition to SOAP transport mapping. I think this is incorrect advice. if you want to develop a NETCONF device which has interoperability with other NETCONF implementations, RFC 4741 says that you need to support SSH transport mapping. Period. It does not say "in addition to SOAP transport mapping." David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 8 10:01:31 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5013A68B0; Thu, 8 Jan 2009 10:01:31 -0800 (PST) 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 9ACBE3A63D3 for ; Thu, 8 Jan 2009 10:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Fjgf4i4jarj2 for ; Thu, 8 Jan 2009 10:01:29 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E5E5D28C0F0 for ; Thu, 8 Jan 2009 10:01:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,235,1231131600"; d="scan'208";a="157135400" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 08 Jan 2009 13:01:05 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 08 Jan 2009 13:01:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 19:01:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Charter for IETF Review Thread-Index: AclxuxJRPgmHwdVPQlms1VCRmpkvsQ== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] New Charter for IETF Review 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org The IESG telechat discussed the re-chartering proposal for NETCONF and decided it is best to send it to IETF review. You should see an announcement soon. The final discussion for approval of the charter is planned for the 1/29 telechat. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 8 10:01:31 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D5013A68B0; Thu, 8 Jan 2009 10:01:31 -0800 (PST) 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 9ACBE3A63D3 for ; Thu, 8 Jan 2009 10:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 Fjgf4i4jarj2 for ; Thu, 8 Jan 2009 10:01:29 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id E5E5D28C0F0 for ; Thu, 8 Jan 2009 10:01:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,235,1231131600"; d="scan'208";a="157135400" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 08 Jan 2009 13:01:05 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 08 Jan 2009 13:01:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 Jan 2009 19:01:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Charter for IETF Review Thread-Index: AclxuxJRPgmHwdVPQlms1VCRmpkvsQ== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] New Charter for IETF Review 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org The IESG telechat discussed the re-chartering proposal for NETCONF and decided it is best to send it to IETF review. You should see an announcement soon. The final discussion for approval of the charter is planned for the 1/29 telechat. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 15 05:23:28 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A713A691C; Thu, 15 Jan 2009 05:23:28 -0800 (PST) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0AFD128C117; Thu, 15 Jan 2009 05:00:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20090115130002.0AFD128C117@core3.amsl.com> Date: Thu, 15 Jan 2009 05:00:02 -0800 (PST) X-Mailman-Approved-At: Thu, 15 Jan 2009 05:23:27 -0800 Cc: netconf@ietf.org Subject: [Netconf] WG Review: Recharter of Network Configuration (netconf) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org A modified charter has been submitted for the Network Configuration (netconf) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, January 22, 2009. Network Configuration (netconf) ================================ Last Modified: 2008-12-16 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/netconf Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe 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. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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 can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data 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 final version of NETCONF Notifications document to IESG for consideration as Proposed Standard Done -00 draft for fine Grain Locking Done -00 draft for NETCONF over TLS Done -00 draft for NETCONF Monitoring Done -00 draft for Schema Advertisement Done Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 N.A. WG Last Call on Schema Advertisement after IETF72 Schema Advertisement has been merged into Monitoring Done WG Last Call on NETCONF over TLS after IETF72 Done Netconf over TLS to IESG for consideration as Proposed Standards Dec 2008 WG Last Call on Fine Grain Locking after IETF73 Dec 2008 Send Partial Locking to IESG for consideration as Proposed Standards Jan 2009 Initial WG draft for with-defaults capability Feb 2009 Initial WG draft for rfc4741bis Mar 2009 WG Last Call on NETCONF Monitoring after IETF73 Apr 2009 WG Last Call on rfc4741bis Apr 2009 WG Last Call on with-defaults Jun 2009 rfc4741bis to IESG for considerations as Proposed Standard Jun 2009 with-defaults capability to IESG for considerations as Proposed Standard _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 15 05:23:28 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A713A691C; Thu, 15 Jan 2009 05:23:28 -0800 (PST) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0AFD128C117; Thu, 15 Jan 2009 05:00:01 -0800 (PST) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20090115130002.0AFD128C117@core3.amsl.com> Date: Thu, 15 Jan 2009 05:00:02 -0800 (PST) X-Mailman-Approved-At: Thu, 15 Jan 2009 05:23:27 -0800 Cc: netconf@ietf.org Subject: [Netconf] WG Review: Recharter of Network Configuration (netconf) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org A modified charter has been submitted for the Network Configuration (netconf) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, January 22, 2009. Network Configuration (netconf) ================================ Last Modified: 2008-12-16 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/netconf Chair(s): Bert Wijnen Mehmet Ersue Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Technical Advisor(s): Charlie Kaufman Mailing Lists: General Discussion: netconf@ietf.org To Subscribe: netconf-request@ietf.org In Body: in msg body: subscribe 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. In the current phase of the incremental development of NETCONF the workgroup will focus on following items: 1. 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. 2. 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. 3. 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. 4. 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. 5. 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. 6. 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 can be started based on the discussion in IETF #73 (see http://www.ietf.org/proceedings/08nov/slides/netconf-3.pdf). Note: A technical errata has been posted on rfc4742. If the work on rfc4741bis uncovers any additional fixes/clarifications that need to be made to rfc4742, the WG may consider to also do a rfc4742bis as part of this work-item. The following items have been identified as important but are currently not considered in scope for re-chartering and may be candidates for work when there is community consensus to take them on: - NETCONF Notification content - Access Control requirements - NETCONF access to SMI-based MIB data 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 final version of NETCONF Notifications document to IESG for consideration as Proposed Standard Done -00 draft for fine Grain Locking Done -00 draft for NETCONF over TLS Done -00 draft for NETCONF Monitoring Done -00 draft for Schema Advertisement Done Early Review of client authentication approach (for NETCONF over TLS) with the security community at IETF 71 N.A. WG Last Call on Schema Advertisement after IETF72 Schema Advertisement has been merged into Monitoring Done WG Last Call on NETCONF over TLS after IETF72 Done Netconf over TLS to IESG for consideration as Proposed Standards Dec 2008 WG Last Call on Fine Grain Locking after IETF73 Dec 2008 Send Partial Locking to IESG for consideration as Proposed Standards Jan 2009 Initial WG draft for with-defaults capability Feb 2009 Initial WG draft for rfc4741bis Mar 2009 WG Last Call on NETCONF Monitoring after IETF73 Apr 2009 WG Last Call on rfc4741bis Apr 2009 WG Last Call on with-defaults Jun 2009 rfc4741bis to IESG for considerations as Proposed Standard Jun 2009 with-defaults capability to IESG for considerations as Proposed Standard _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 15 08:42:52 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1833A6A3E; Thu, 15 Jan 2009 08:42:52 -0800 (PST) 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 4BD1228C266 for ; Thu, 15 Jan 2009 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=-0.751, 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 WqND5VkvHnMn for ; Thu, 15 Jan 2009 08:42:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3FD7828C25D for ; Thu, 15 Jan 2009 08:42:48 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0FGgWX0003040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Jan 2009 17:42:32 +0100 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 n0FGgWgJ003518 for ; Thu, 15 Jan 2009 17:42:32 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 17:42:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C97730.42527C55" Date: Thu, 15 Jan 2009 17:42:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5378 and Draft Submissions Thread-Index: Acl2zqcXsvHexWU2TSibsFRswrshQwAYMfPw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 15 Jan 2009 16:42:31.0880 (UTC) FILETIME=[42C03C80:01C97730] Subject: [Netconf] FW: RFC 5378 and Draft Submissions 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: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C97730.42527C55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Document authors: Please be aware of the discussion on RFC 5378 and its impact=20 on Draft Submissions (see below and attachments). Cheers, Mehmet -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext Russ Housley Sent: Wednesday, January 14, 2009 5:00 PM To: wgchairs@ietf.org Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem WG Chairs: Please make sure that your WG, and especially your document authors,=20 are aware of this situation. Please follow the discussion on the=20 IETF Discussion list, and keep the WG informed about the way forward=20 as it develops. Thanks, Russ >From: "Ed Juskevicius" >To: "'IETF Discussion'" , , > , , , > >Date: Thu, 8 Jan 2009 16:43:50 -0500 >Cc: 'Trustees' >Subject: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and > comments on a proposed Work-Around to the Pre-5378 Problem > >The purpose of this message is twofold: > >1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in November 2008, > and >2) To invite community review and discussion on a potential work-around > being considered by the IETF Trustees. > >Some I-D authors are having difficulty implementing RFC 5378. An >example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > >If an I-D author includes pre-5378 material in a new document, then s/he >must represent or warrant that all of the authors who created the >pre-5378 material have granted rights for that material to the IETF Trust. >If s/he cannot make this assertion, then s/he has a problem. > >This situation has halted the progression of some Internet-Drafts and >interrupted the publication of some RFCs. The Trustees of the IETF Trust >are investigating ways to implement a temporary work-around so that IETF >work can continue to progress. A permanent solution to this "pre-5378 >problem" may require an update to RFC 5378, for example new work by the >community to create a 5378-bis document. > >The remainder of this message provides an outline of the temporary work- >around being considered by the Trustees. > >RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the >authority to develop legend text for authors to use in situations where >they wish to limit the granting of rights to modify and prepare >derivatives of the documents they submit. The Trustees used this >authority in 2008 to develop and adopt the current "Legal Provisions >Relating to IETF Documents" which are posted at: >http://trustee.ietf.org/license-info/. > >The Trustees are now considering the creation of optional new legend text >which could be used by authors experiencing the "pre-5378 problem". > >The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > >So, how could the creation and use of some new legend text help people >work-around the pre-5378 problem? > >The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem should add > new legend text to the contribution, to clearly flag that it includes > pre-5378 material for which all of the rights needed under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > >The proposed wording for the new legend text is now available for your >review and comments in section 6.c.iii of a draft revision to the >IETF Trust's "Legal Provisions Relating to IETF Documents" located at >http://trustee.ietf.org/policyandprocedures.html. > >Please note that the above document also contains new text in section 5.c >dealing with "License Limitations". > >If your review and feedback on this proposed work-around is positive, >then the new text may be adopted by the Trustees in early February 2009, >and then be published as an official revision to the Legal Provisions >document. If so adopted, Internet-Drafts with pre-5378 material may >advance within the Internet standards process and get published as RFCs >where otherwise qualified to do so. Unless covered by sections 6.c.i or >6.c.ii, authors of documents in which there is no pre-5378 >material must provide a RFC 5378 license with no limitation on >modifications outside the IETF standards process. > >The IETF Trust will not grant the right to modify or prepare derivative >works of any specific RFC or other IETF Contribution outside the IETF >standards process until RFC 5378 rights pertaining to that document have >been obtained from all authors and after compliance by the IETF Trust >with RFC 5377. The Trustees will establish one or more mechanisms by >which authors of pre-5378 documents may grant RFC 5378 rights. > >The Trustees hereby invite your review, comments and suggestions on this >proposed work-around to the "pre-5378 problem". The period for this review >is 30 days. Microsoft WORD and PDF versions of the proposed revisions are >attached to this message. Copies are also available on the IETF Trust >website under the heading "DRAFT Policy and Procedures Being Developed" at: >http://trustee.ietf.org/policyandprocedures.html > >All feedback submitted before the end of February 7th will be considered by >the Trustees. A decision on whether to move forward with this proposal will >be made and communicated to you before the end of February 15th. > >Please give this your attention. > >Regards and Happy New Year ! > >Ed Juskevicius, on behalf of the IETF Trustees >edj.etc@gmail.com ------_=_NextPart_001_01C97730.42527C55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:03:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:03:04 +0100 Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0EJ34M0030358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2009 20:03:04 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0EJ330w006074; Wed, 14 Jan 2009 20:03:03 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CD228C1E3; Wed, 14 Jan 2009 11:02:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D272528C1C0 for ; Wed, 14 Jan 2009 11:02:45 -0800 (PST) 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 pmv16h+5suRP for ; Wed, 14 Jan 2009 11:02:45 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id CB44628C1D4 for ; Wed, 14 Jan 2009 11:02:44 -0800 (PST) Received: (qmail 4925 invoked by uid 0); 14 Jan 2009 19:02:24 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 14 Jan 2009 19:02:24 -0000 Content-class: urn:content-classes:message Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Date: Wed, 14 Jan 2009 20:02:25 +0100 Message-ID: <20090114190244.CB44628C1D4@core3.amsl.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Thread-Index: Acl2errBd8Fc93xMSIK92rFy7YlQbw== References: <20090114162344.8B60C3A63CB@core3.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext Russ Housley" Sender: To: "Spencer Dawkins" Cc: Sorry that I was unclear. It is important that all contributors know=20 the terms under which contributions are made. So, I mean the=20 requirements in RFC 5378 and the problems that some people have had with = them. If people want to engage in the discussion of the work-around, please=20 direct them to the thread on the IETF Discussion mail list. I think=20 that a separate discussion in each working group would be = counterproductive. Russ At 11:27 AM 1/14/2009, Spencer Dawkins wrote: >Russ, > >By "this situation", do you mean the requirements in 5378 (current=20 >BCP), or the trustee's search for a work-around? > >I'm asking so that I don't send multiple messages to my working = group... > >Thanks, > >Spencer > > >>WG Chairs: >> >>Please make sure that your WG, and especially your document=20 >>authors, are aware of this situation. Please follow the discussion=20 >>on the IETF Discussion list, and keep the WG informed about the way=20 >>forward as it develops. >> >>Thanks, >> Russ > > ------_=_NextPart_001_01C97730.42527C55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 06:03:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 06:03:49 +0100 Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0F53mjr004475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2009 06:03:48 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0F53lEp009928; Thu, 15 Jan 2009 06:03:48 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ACE028C1CD; Wed, 14 Jan 2009 21:04:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0913A688A for ; Wed, 14 Jan 2009 21:04:00 -0800 (PST) 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 uSQsmh+Z67I2 for ; Wed, 14 Jan 2009 21:03:59 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id 7D7B83A6809 for ; Wed, 14 Jan 2009 21:03:59 -0800 (PST) Received: by gxk14 with SMTP id 14so846023gxk.13 for ; Wed, 14 Jan 2009 21:03:43 -0800 (PST) Received: by 10.151.11.17 with SMTP id o17mr3276652ybi.91.1231995823024; Wed, 14 Jan 2009 21:03:43 -0800 (PST) Received: by 10.151.75.6 with HTTP; Wed, 14 Jan 2009 21:03:42 -0800 (PST) Content-class: urn:content-classes:message Subject: Fwd: RFC 5378 and Draft From netconf-bounces@ietf.org Thu Jan 15 08:42:52 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1833A6A3E; Thu, 15 Jan 2009 08:42:52 -0800 (PST) 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 4BD1228C266 for ; Thu, 15 Jan 2009 08:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=-0.751, 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 WqND5VkvHnMn for ; Thu, 15 Jan 2009 08:42:50 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3FD7828C25D for ; Thu, 15 Jan 2009 08:42:48 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0FGgWX0003040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 15 Jan 2009 17:42:32 +0100 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 n0FGgWgJ003518 for ; Thu, 15 Jan 2009 17:42:32 +0100 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 17:42:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C97730.42527C55" Date: Thu, 15 Jan 2009 17:42:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5378 and Draft Submissions Thread-Index: Acl2zqcXsvHexWU2TSibsFRswrshQwAYMfPw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 15 Jan 2009 16:42:31.0880 (UTC) FILETIME=[42C03C80:01C97730] Subject: [Netconf] FW: RFC 5378 and Draft Submissions 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: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C97730.42527C55 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Document authors: Please be aware of the discussion on RFC 5378 and its impact=20 on Draft Submissions (see below and attachments). Cheers, Mehmet -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext Russ Housley Sent: Wednesday, January 14, 2009 5:00 PM To: wgchairs@ietf.org Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem WG Chairs: Please make sure that your WG, and especially your document authors,=20 are aware of this situation. Please follow the discussion on the=20 IETF Discussion list, and keep the WG informed about the way forward=20 as it develops. Thanks, Russ >From: "Ed Juskevicius" >To: "'IETF DiscSubmissions Date: Thu, 15 Jan 2009 06:03:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5378 and Draft Submissions Thread-Index: Acl2zqcXsvHexWU2TSibsFRswrshQw== References: List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext Eric Rescorla" Sender: To: "Working Group Chairs" FYI ---------- Forwarded message ---------- From: Eric Rescorla Date: Wed, Jan 14, 2009 at 9:03 PM Subject: RFC 5378 and Draft Submissions To: tls@ietf.org IETF Chair Russ Housley has asked WG chairs to apprise their WGs of the following information. If you've been following the IETF mailing list, you may be aware of the ongoing discussion about the impact of RFC 5378 on revised draft submissions. Briefly, RFC 5378 requires Contributors to grant a more expansive set of rights than were granted by RFC 3978, and 4748. If you are submitting a document which contains text contributed by others prior to the publication of RFC 5378 you may need to obtain additional rights from the copyright holders of that text in order to contribute under the 5378 terms. The IESG and the IETF Trustees are working to resolve those issues (see http://trustee.ietf.org/docs/Background-to-Draft-Update-to-IETF-Trust-Leg= al-Provisions.txt). However, at present I would advise care prior to submitting any draft which contains material derived from an RFC, draft, or mailing list message published prior to November 10, 2008. Speaking personally, I have chosen not to submit new versions of most of my drafts until matters are resolved. Please take any general discussion of RFC 5378 to ietf@ietf.org -Ekr [As WG Chair] ------_=_NextPart_001_01C97730.42527C55 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C97730.42527C55-- ussion'" , , > , , , > >Date: Thu, 8 Jan 2009 16:43:50 -0500 >Cc: 'Trustees' >Subject: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and > comments on a proposed Work-Around to the Pre-5378 Problem > >The purpose of this message is twofold: > >1) To summarize the issues that some members of our community > have experienced since the publication of RFC 5378 in November 2008, > and >2) To invite community review and discussion on a potential work-around > being considered by the IETF Trustees. > >Some I-D authors are having difficulty implementing RFC 5378. An >example of the difficulty is as follows: > > - an author wants to include pre-5378 content in a new submission > or contribution to the IETF, but > - s/he is not certain that all of the author(s) of the earlier > material have agreed to license it to the IETF Trust according > to RFC 5378. > >If an I-D author includes pre-5378 material in a new document, then s/he >must represent or warrant that all of the authors who created the >pre-5378 material have granted rights for that material to the IETF Trust. >If s/he cannot make this assertion, then s/he has a problem. > >This situation has halted the progression of some Internet-Drafts and >interrupted the publication of some RFCs. The Trustees of the IETF Trust >are investigating ways to implement a temporary work-around so that IETF >work can continue to progress. A permanent solution to this "pre-5378 >problem" may require an update to RFC 5378, for example new work by the >community to create a 5378-bis document. > >The remainder of this message provides an outline of the temporary work- >around being considered by the Trustees. > >RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the >authority to develop legend text for authors to use in situations where >they wish to limit the granting of rights to modify and prepare >derivatives of the documents they submit. The Trustees used this >authority in 2008 to develop and adopt the current "Legal Provisions >Relating to IETF Documents" which are posted at: >http://trustee.ietf.org/license-info/. > >The Trustees are now considering the creation of optional new legend text >which could be used by authors experiencing the "pre-5378 problem". > >The new legend text, if implemented, would do the following: > > a. Provide Authors and Contributors with a way to identify (to the > IETF Trust) that their contributions contain material from pre-5378 > documents for which RFC 5378 rights to modify the material outside > the IETF standards process may not have been granted, and > > b. Provide the IETF Trust and the community with a clear indication > of every document containing pre-5378 content and having the > "pre-5378 problem". > >So, how could the creation and use of some new legend text help people >work-around the pre-5378 problem? > >The proposed answer is as follows: > > 1. Anyone having a contribution with the "pre-5378" problem should add > new legend text to the contribution, to clearly flag that it includes > pre-5378 material for which all of the rights needed under RFC 5378 > may not have been granted, and > > 2. The IETF Trust will consider authors and contributors (with the > pre-5378 problem) to have met their RFC 5378 obligations if the > new legend text appears on their documents, and > > 3. Authors and contributors should only resort to adding the new > legend text to their documents (per #1) if they cannot develop > certainty that all of the author(s) of pre-5378 material in > their documents have agreed to license the pre-5378 content to > the IETF Trust according to RFC 5378. > >The proposed wording for the new legend text is now available for your >review and comments in section 6.c.iii of a draft revision to the >IETF Trust's "Legal Provisions Relating to IETF Documents" located at >http://trustee.ietf.org/policyandprocedures.html. > >Please note that the above document also contains new text in section 5.c >dealing with "License Limitations". > >If your review and feedback on this proposed work-around is positive, >then the new text may be adopted by the Trustees in early February 2009, >and then be published as an official revision to the Legal Provisions >document. If so adopted, Internet-Drafts with pre-5378 material may >advance within the Internet standards process and get published as RFCs >where otherwise qualified to do so. Unless covered by sections 6.c.i or >6.c.ii, authors of documents in which there is no pre-5378 >material must provide a RFC 5378 license with no limitation on >modifications outside the IETF standards process. > >The IETF Trust will not grant the right to modify or prepare derivative >works of any specific RFC or other IETF Contribution outside the IETF >standards process until RFC 5378 rights pertaining to that document have >been obtained from all authors and after compliance by the IETF Trust >with RFC 5377. The Trustees will establish one or more mechanisms by >which authors of pre-5378 documents may grant RFC 5378 rights. > >The Trustees hereby invite your review, comments and suggestions on this >proposed work-around to the "pre-5378 problem". The period for this review >is 30 days. Microsoft WORD and PDF versions of the proposed revisions are >attached to this message. Copies are also available on the IETF Trust >website under the heading "DRAFT Policy and Procedures Being Developed" at: >http://trustee.ietf.org/policyandprocedures.html > >All feedback submitted before the end of February 7th will be considered by >the Trustees. A decision on whether to move forward with this proposal will >be made and communicated to you before the end of February 15th. > >Please give this your attention. > >Regards and Happy New Year ! > >Ed Juskevicius, on behalf of the IETF Trustees >edj.etc@gmail.com ------_=_NextPart_001_01C97730.42527C55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc023.nsn-intra.net ([10.150.128.36]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:03:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jan 2009 20:03:04 +0100 Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0EJ34M0030358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2009 20:03:04 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0EJ330w006074; Wed, 14 Jan 2009 20:03:03 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1CD228C1E3; Wed, 14 Jan 2009 11:02:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D272528C1C0 for ; Wed, 14 Jan 2009 11:02:45 -0800 (PST) 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 pmv16h+5suRP for ; Wed, 14 Jan 2009 11:02:45 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id CB44628C1D4 for ; Wed, 14 Jan 2009 11:02:44 -0800 (PST) Received: (qmail 4925 invoked by uid 0); 14 Jan 2009 19:02:24 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.143.189) by woodstock.binhost.com with SMTP; 14 Jan 2009 19:02:24 -0000 Content-class: urn:content-classes:message Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Date: Wed, 14 Jan 2009 20:02:25 +0100 Message-ID: <20090114190244.CB44628C1D4@core3.amsl.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANNOUNCEMENT: The IETF Trustees invite your review andcomments on a proposed Work-Around to the Pre-5378 Problem Thread-Index: Acl2errBd8Fc93xMSIK92rFy7YlQbw== References: <20090114162344.8B60C3A63CB@core3.amsl.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext Russ Housley" Sender: To: "Spencer Dawkins" Cc: Sorry that I was unclear. It is important that all contributors know=20 the terms under which contributions are made. So, I mean the=20 requirements in RFC 5378 and the problems that some people have had with = them. If people want to engage in the discussion of the work-around, please=20 direct them to the thread on the IETF Discussion mail list. I think=20 that a separate discussion in each working group would be = counterproductive. Russ At 11:27 AM 1/14/2009, Spencer Dawkins wrote: >Russ, > >By "this situation", do you mean the requirements in 5378 (current=20 >BCP), or the trustee's search for a work-around? > >I'm asking so that I don't send multiple messages to my working = group... > >Thanks, > >Spencer > > >>WG Chairs: >> >>Please make sure that your WG, and especially your document=20 >>authors, are aware of this situation. Please follow the discussion=20 >>on the IETF Discussion list, and keep the WG informed about the way=20 >>forward as it develops. >> >>Thanks, >> Russ > > ------_=_NextPart_001_01C97730.42527C55 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from demuexc022.nsn-intra.net ([10.150.128.35]) by DEMUEXC005.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 06:03:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jan 2009 06:03:49 +0100 Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0F53mjr004475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2009 06:03:48 +0100 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0F53lEp009928; Thu, 15 Jan 2009 06:03:48 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ACE028C1CD; Wed, 14 Jan 2009 21:04:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0913A688A for ; Wed, 14 Jan 2009 21:04:00 -0800 (PST) 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 uSQsmh+Z67I2 for ; Wed, 14 Jan 2009 21:03:59 -0800 (PST) Received: from mail-gx0-f21.google.com (mail-gx0-f21.google.com [209.85.217.21]) by core3.amsl.com (Postfix) with ESMTP id 7D7B83A6809 for ; Wed, 14 Jan 2009 21:03:59 -0800 (PST) Received: by gxk14 with SMTP id 14so846023gxk.13 for ; Wed, 14 Jan 2009 21:03:43 -0800 (PST) Received: by 10.151.11.17 with SMTP id o17mr3276652ybi.91.1231995823024; Wed, 14 Jan 2009 21:03:43 -0800 (PST) Received: by 10.151.75.6 with HTTP; Wed, 14 Jan 2009 21:03:42 -0800 (PST) Content-class: urn:content-classes:message Subject: Fwd: RFC 5378 and Draft Submissions Date: Thu, 15 Jan 2009 06:03:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 5378 and Draft Submissions Thread-Index: Acl2zqcXsvHexWU2TSibsFRswrshQw== References: List-Help: List-Subscribe: , List-Unsubscribe: , From: "ext Eric Rescorla" Sender: To: "Working Group Chairs" FYI ---------- Forwarded message ---------- From: Eric Rescorla Date: Wed, Jan 14, 2009 at 9:03 PM Subject: RFC 5378 and Draft Submissions To: tls@ietf.org IETF Chair Russ Housley has asked WG chairs to apprise their WGs of the following information. If you've been following the IETF mailing list, you may be aware of the ongoing discussion about the impact of RFC 5378 on revised draft submissions. Briefly, RFC 5378 requires Contributors to grant a more expansive set of rights than were granted by RFC 3978, and 4748. If you are submitting a document which contains text contributed by others prior to the publication of RFC 5378 you may need to obtain additional rights from the copyright holders of that text in order to contribute under the 5378 terms. The IESG and the IETF Trustees are working to resolve those issues (see http://trustee.ietf.org/docs/Background-to-Draft-Update-to-IETF-Trust-Leg= al-Provisions.txt). However, at present I would advise care prior to submitting any draft which contains material derived from an RFC, draft, or mailing list message published prior to November 10, 2008. Speaking personally, I have chosen not to submit new versions of most of my drafts until matters are resolved. Please take any general discussion of RFC 5378 to ietf@ietf.org -Ekr [As WG Chair] ------_=_NextPart_001_01C97730.42527C55 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ------_=_NextPart_001_01C97730.42527C55-- From netconf-bounces@ietf.org Mon Jan 19 08:58:38 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5703A69CE; Mon, 19 Jan 2009 08:58:38 -0800 (PST) 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 75EF63A69CE for ; Mon, 19 Jan 2009 08:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 KQFgb6Lc8M78 for ; Mon, 19 Jan 2009 08:58:36 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 737FA3A69AC for ; Mon, 19 Jan 2009 08:58:36 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LOxS7-0006mB-3j for netconf@ietf.org; Mon, 19 Jan 2009 17:58:19 +0100 Message-ID: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <493EA615.8050807@ericsson.com> In-Reply-To: <493EA615.8050807@ericsson.com> Date: Mon, 19 Jan 2009 17:57:54 +0100 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: multipart/mixed; boundary="===============0745080150==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0745080150== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0751_01C97A5F.73F7A0E0" This is a multi-part message in MIME format. ------=_NextPart_000_0751_01C97A5F.73F7A0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This new version is now available for over a month. I know that the = holiday season was part of that. Nevertheless, by now people should have had = time to check the new version and ensure that - any earlier comments have been addressed or answered - no new concerns have been introduced. All WG members, pls review and make sure we have your input BEFORE Feb 1st. While looking at the diff file at: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-partial-lock/draft-ie= tf-netconf-partial-lock-05-from-04.diff.html I immediately saw these 2 nits: - I notice in section 2.1 (page 4) that you changed=20 =20 into partial-unlock But in the last para of section 2,1 you do talk about Inconsistent? - This sentence (3rd bullet page 7): The NETCONF server implements access control, and the locking = user does not have sufficient access rights. .... Do you mean s/does not/must/ ?? Bert ------=_NextPart_000_0751_01C97A5F.73F7A0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This new version is now available for over a = month. I=20 know that the holiday
season was part of that. Nevertheless, by now people = should=20 have had time
to check the new version and ensure = that
- any earlier comments have been addressed or=20 answered
- no new concerns have been introduced.
 
All WG members, pls review and make sure we have = your input=20 BEFORE
Feb 1st.
 
While looking at the diff file at:
http://tools.ietf.o= rg/wg/netconf/draft-ietf-netconf-partial-lock/draft-ietf-netconf-partial-= lock-05-from-04.diff.html
 
I immediately saw these 2 nits:
 
-  I notice in section 2.1 (page 4) that you = changed=20
     =  <partial-unlock>=20
   into
     =20  partial-unlock
   But in the last para of section 2,1 you = do talk=20 about <partial-lock>
   Inconsistent?
 
-  This sentence (3rd bullet page = 7):
        The = NETCONF server=20 implements access control, and the locking=20 user
        does not have = sufficient=20 access rights.  ....
   Do you mean s/does not/must/ = ??
 
Bert
------=_NextPart_000_0751_01C97A5F.73F7A0E0-- --===============0745080150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0745080150==-- From netconf-bounces@ietf.org Mon Jan 19 08:58:38 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5703A69CE; Mon, 19 Jan 2009 08:58:38 -0800 (PST) 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 75EF63A69CE for ; Mon, 19 Jan 2009 08:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.238 X-Spam-Level: * X-Spam-Status: No, score=1.238 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_50=0.001, HELO_MISMATCH_NET=0.611, HOST_EQ_NL=1.545, HTML_MESSAGE=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 KQFgb6Lc8M78 for ; Mon, 19 Jan 2009 08:58:36 -0800 (PST) Received: from relay.versatel.net (beverwijk.tele2.vuurwerk.nl [62.250.3.53]) by core3.amsl.com (Postfix) with ESMTP id 737FA3A69AC for ; Mon, 19 Jan 2009 08:58:36 -0800 (PST) Received: from [87.215.199.34] (helo=BertLaptop) by relay.versatel.net with smtp (Exim 4.69) (envelope-from ) id 1LOxS7-0006mB-3j for netconf@ietf.org; Mon, 19 Jan 2009 17:58:19 +0100 Message-ID: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <493EA615.8050807@ericsson.com> In-Reply-To: <493EA615.8050807@ericsson.com> Date: Mon, 19 Jan 2009 17:57:54 +0100 Organization: Consultant MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: multipart/mixed; boundary="===============0745080150==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0745080150== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0751_01C97A5F.73F7A0E0" This is a multi-part message in MIME format. ------=_NextPart_000_0751_01C97A5F.73F7A0E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This new version is now available for over a month. I know that the = holiday season was part of that. Nevertheless, by now people should have had = time to check the new version and ensure that - any earlier comments have been addressed or answered - no new concerns have been introduced. All WG members, pls review and make sure we have your input BEFORE Feb 1st. While looking at the diff file at: http://tools.ietf.org/wg/netconf/draft-ietf-netconf-partial-lock/draft-ie= tf-netconf-partial-lock-05-from-04.diff.html I immediately saw these 2 nits: - I notice in section 2.1 (page 4) that you changed=20 =20 into partial-unlock But in the last para of section 2,1 you do talk about Inconsistent? - This sentence (3rd bullet page 7): The NETCONF server implements access control, and the locking = user does not have sufficient access rights. .... Do you mean s/does not/must/ ?? Bert ------=_NextPart_000_0751_01C97A5F.73F7A0E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This new version is now available for over a = month. I=20 know that the holiday
season was part of that. Nevertheless, by now people = should=20 have had time
to check the new version and ensure = that
- any earlier comments have been addressed or=20 answered
- no new concerns have been introduced.
 
All WG members, pls review and make sure we have = your input=20 BEFORE
Feb 1st.
 
While looking at the diff file at:
http://tools.ietf.o= rg/wg/netconf/draft-ietf-netconf-partial-lock/draft-ietf-netconf-partial-= lock-05-from-04.diff.html
 
I immediately saw these 2 nits:
 
-  I notice in section 2.1 (page 4) that you = changed=20
     =  <partial-unlock>=20
   into
     =20  partial-unlock
   But in the last para of section 2,1 you = do talk=20 about <partial-lock>
   Inconsistent?
 
-  This sentence (3rd bullet page = 7):
        The = NETCONF server=20 implements access control, and the locking=20 user
        does not have = sufficient=20 access rights.  ....
   Do you mean s/does not/must/ = ??
 
Bert
------=_NextPart_000_0751_01C97A5F.73F7A0E0-- --===============0745080150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0745080150==-- From netconf-bounces@ietf.org Mon Jan 19 10:09:50 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F59428C178; Mon, 19 Jan 2009 10:09:50 -0800 (PST) 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 92C8028C172 for ; Mon, 19 Jan 2009 10:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLJF9KgTGGRR for ; Mon, 19 Jan 2009 10:09:45 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id AA92728C166 for ; Mon, 19 Jan 2009 10:09:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2D46A4B018F for ; Mon, 19 Jan 2009 10:09:30 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08835-06 for ; Mon, 19 Jan 2009 10:09:30 -0800 (PST) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id E6E3D4B018E for ; Mon, 19 Jan 2009 10:09:29 -0800 (PST) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Mon, 19 Jan 2009 10:09:29 -0800 From: Vladlen Kot To: "netconf@ietf.org" Date: Mon, 19 Jan 2009 10:09:29 -0800 Thread-Topic: Does NetConf require to have an XML declaration in the script? Thread-Index: Acl6YRIQdh183MUkRkCvqkikbpsAIg== Message-ID: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: [Netconf] Does NetConf require to have an XML declaration in the script? 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: , Content-Type: multipart/mixed; boundary="===============0177656152==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============0177656152== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello there, I just want to confirm if XML declaration is a Required (MUST be) part when sending NetConf message OR is it an Optio= nal? I can not find anything that says: "It's a MUST to be" (in the NetConf docs= ) but one of our guys raising it as a High priority Issue. Thanks, Vlad --_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F59428C178; Mon, 19 Jan 2009 10:09:50 -0800 (PST) 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 92C8028C172 for ; Mon, 19 Jan 2009 10:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLJF9KgTGGRR for ; Mon, 19 Jan 2009 10:09:45 -0800 (PST) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id AA92728C166 for ; Mon, 19 Jan 2009 10:09:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 2D46A4B018F for ; Mon, 19 Jan 2009 10:09:30 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08835-06 for ; Mon, 19 Jan 2009 10:09:30 -0800 (PST) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id E6E3D4B018E for ; Mon, 19 Jan 2009 10:09:29 -0800 (PST) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Mon, 19 Jan 2009 10:09:29 -0800 From: Vladlen Kot To: "netconf@ietf.org" Date: Mon, 19 Jan 2009 10:09:29 -0800 Thread-Topic: Does NetConf require to have an XML declaration in the script? Thread-Index: Acl6YRIQdh183MUkRkCvqkikbpsAIg== Message-ID: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Virus-Scanned: by amavisd-new at redback.com Subject: [Netconf] Does NetConf require to have an XML declaration in the script? 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: , Content-Type: multipart/mixed; boundary="===============0177656152==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============0177656152== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello there, I just want to confirm if XML declaration is a Required (MUST be) part when sending NetConf message OR is it an Optio= nal? I can not find anything that says: "It's a MUST to be" (in the NetConf docs= ) but one of our guys raising it as a High priority Issue. Thanks, Vlad --_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello there,

 

I just want to confirm if XML declaration

    = ;    <?xml version=3D"1.0" encoding=3D"UTF-8"?>  

is a Required (MUST be) part when sending NetConf messag= e OR is it an Optional?

 

I can not find anything that says: “It’s a M= UST to be” (in the NetConf docs) but one of our guys raising it as a High priority Issue.

 

Thanks,

Vlad

 

--_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_-- --===============0177656152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0177656152==-- org/TR/REC-html40">

Hello there,

 

I just want to confirm if XML declaration

    = ;    <?xml version=3D"1.0" encoding=3D"UTF-8"?>  

is a Required (MUST be) part when sending NetConf messag= e OR is it an Optional?

 

I can not find anything that says: “It’s a M= UST to be” (in the NetConf docs) but one of our guys raising it as a High priority Issue.

 

Thanks,

Vlad

 

--_000_48C276B536524E478C659685995F6AA5A2B9CB0A56RBSJXadredbac_-- --===============0177656152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0177656152==-- From netconf-bounces@ietf.org Mon Jan 19 15:27:49 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B023A6A4F; Mon, 19 Jan 2009 15:27:49 -0800 (PST) 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 DB6B03A6A45 for ; Mon, 19 Jan 2009 15:27:47 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 gQ2xv2msABqH for ; Mon, 19 Jan 2009 15:27:44 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id DE3E13A67B1 for ; Mon, 19 Jan 2009 15:27:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,291,1231113600"; d="scan'208,217";a="41018658" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 19 Jan 2009 23:27:21 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JNRKTS025035; Tue, 20 Jan 2009 07:27:20 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JNRKa7019235; Mon, 19 Jan 2009 23:27:20 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 07:27:20 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 07:27:19 +0800 Message-ID: In-Reply-To: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Does NetConf require to have an XML declaration in thescript? Thread-Index: Acl6YRIQdh183MUkRkCvqkikbpsAIgAK52dw References: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> From: "James Balestriere (jbalestr)" To: "Vladlen Kot" , X-OriginalArrivalTime: 19 Jan 2009 23:27:20.0369 (UTC) FILETIME=[79788A10:01C97A8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6315; t=1232407641; x=1233271641; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jbalestr@cisco.com; z=From:=20=22James=20Balestriere=20(jbalestr)=22=20 |Subject:=20RE=3A=20[Netconf]=20Does=20NetConf=20require=20 to=20have=20an=20XML=20declaration=20in=20thescript? |Sender:=20; bh=WWlaI/bJFlTko59Neu3jGVYkr1K34zMcgBJYXgCKMIQ=; b=LV0WJ9Py5XICboDduFadvfAGU9JzLyqLVEHenEESIbIi0v2cSilurlkukv G03I67QwRIO7futcuAAse8DEqDNmmzVkiuQ1FKT5rMOsMnixGKdhwlFtxqZX zECIDq5Ot8q9m7Aobxykjx6VHU54ntR5oasNJuOIbgTJcIGHbxzKE=; Authentication-Results: hkg-dkim-1; header.DKIM-Signature=jbalestr@cisco.com; dkim=fail ( DNS lookup for cisco.com/hkgdkim1002 failed; cisco.com/hkgdk im1002 fail; ); header.From=jbalestr@cisco.com; dkim=neutral Subject: Re: [Netconf] Does NetConf require to have an XML declaration in thescript? 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: , Content-Type: multipart/mixed; boundary="===============0522520832==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0522520832== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A8D.794A4921" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A8D.794A4921 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vlad, =20 If I recall the discussion we had on this alias a few months ago correctly, Netconf does not have an explicit requirement, but, hidden in the XML language spec is something which implies it is optional. So I think the implication for NETCONF is that the declaration is optional. =20 James. ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Vladlen Kot Sent: Tuesday, January 20, 2009 5:09 AM To: netconf@ietf.org Subject: [Netconf] Does NetConf require to have an XML declaration in thescript? Hello there, =20 I just want to confirm if XML declaration=20 =20 is a Required (MUST be) part when sending NetConf message OR is it an Optional?=20 =20 I can not find anything that says: "It's a MUST to be" (in the NetConf docs) but one of our guys raising it as a High priority Issue. =20 Thanks, Vlad =20 ------_=_NextPart_001_01C97A8D.794A4921 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Vlad,
 
If I recall the discussion we had on this alias = a few=20 months ago correctly, Netconf does not have an explicit=20 requirement,
but, hidden in the XML language spec is = something=20 which implies it is optional. So I think the implication for NETCONF=20 is
that the declaration is = optional.
 
J X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9B023A6A4F; Mon, 19 Jan 2009 15:27:49 -0800 (PST) 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 DB6B03A6A45 for ; Mon, 19 Jan 2009 15:27:47 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 gQ2xv2msABqH for ; Mon, 19 Jan 2009 15:27:44 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id DE3E13A67B1 for ; Mon, 19 Jan 2009 15:27:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,291,1231113600"; d="scan'208,217";a="41018658" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 19 Jan 2009 23:27:21 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0JNRKTS025035; Tue, 20 Jan 2009 07:27:20 +0800 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0JNRKa7019235; Mon, 19 Jan 2009 23:27:20 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Jan 2009 07:27:20 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 Jan 2009 07:27:19 +0800 Message-ID: In-Reply-To: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] Does NetConf require to have an XML declaration in thescript? Thread-Index: Acl6YRIQdh183MUkRkCvqkikbpsAIgAK52dw References: <48C276B536524E478C659685995F6AA5A2B9CB0A56@RBSJX.ad.redback.com> From: "James Balestriere (jbalestr)" To: "Vladlen Kot" , X-OriginalArrivalTime: 19 Jan 2009 23:27:20.0369 (UTC) FILETIME=[79788A10:01C97A8D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6315; t=1232407641; x=1233271641; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jbalestr@cisco.com; z=From:=20=22James=20Balestriere=20(jbalestr)=22=20 |Subject:=20RE=3A=20[Netconf]=20Does=20NetConf=20require=20 to=20have=20an=20XML=20declaration=20in=20thescript? |Sender:=20; bh=WWlaI/bJFlTko59Neu3jGVYkr1K34zMcgBJYXgCKMIQ=; b=LV0WJ9Py5XICboDduFadvfAGU9JzLyqLVEHenEESIbIi0v2cSilurlkukv G03I67QwRIO7futcuAAse8DEqDNmmzVkiuQ1FKT5rMOsMnixGKdhwlFtxqZX zECIDq5Ot8q9m7Aobxykjx6VHU54ntR5oasNJuOIbgTJcIGHbxzKE=; Authentication-Results: hkg-dkim-1; header.DKIM-Signature=jbalestr@cisco.com; dkim=fail ( DNS lookup for cisco.com/hkgdkim1002 failed; cisco.com/hkgdk im1002 fail; ); header.From=jbalestr@cisco.com; dkim=neutral Subject: Re: [Netconf] Does NetConf require to have an XML declaration in thescript? 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: ames.
From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Vladlen=20 Kot
Sent: Tuesday, January 20, 2009 5:09 AM
To:=20 netconf@ietf.org
Subject: [Netconf] Does NetConf require to = have an=20 XML declaration in thescript?

Hello=20 there,

 

I just want to confirm if = XML=20 declaration

       =20 <?xml version=3D"1.0" encoding=3D"UTF-8"?>  =20

is a Required (MUST be) = part when=20 sending NetConf message OR is it an Optional? =

 

I can not find anything = that says:=20 “It’s a MUST to be” (in the NetConf docs) but one of = our guys raising it as a=20 High priority Issue.

 

Thanks,

Vlad

 

------_=_NextPart_001_01C97A8D.794A4921-- --===============0522520832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0522520832==-- help> List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522520832==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0522520832== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97A8D.794A4921" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97A8D.794A4921 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vlad, =20 If I recall the discussion we had on this alias a few months ago correctly, Netconf does not have an explicit requirement, but, hidden in the XML language spec is something which implies it is optional. So I think the implication for NETCONF is that the declaration is optional. =20 James. ________________________________ From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Vladlen Kot Sent: Tuesday, January 20, 2009 5:09 AM To: netconf@ietf.org Subject: [Netconf] Does NetConf require to have an XML declaration in thescript? Hello there, =20 I just want to confirm if XML declaration=20 =20 is a Required (MUST be) part when sending NetConf message OR is it an Optional?=20 =20 I can not find anything that says: "It's a MUST to be" (in the NetConf docs) but one of our guys raising it as a High priority Issue. =20 Thanks, Vlad =20 ------_=_NextPart_001_01C97A8D.794A4921 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Vlad,
 
If I recall the discussion we had on this alias = a few=20 months ago correctly, Netconf does not have an explicit=20 requirement,
but, hidden in the XML language spec is = something=20 which implies it is optional. So I think the implication for NETCONF=20 is
that the declaration is = optional.
 
James.
From: netconf-bounces@ietf.org=20 [mailto:netconf-bounces@ietf.org] On Behalf Of Vladlen=20 Kot
Sent: Tuesday, January 20, 2009 5:09 AM
To:=20 netconf@ietf.org
Subject: [Netconf] Does NetConf require to = have an=20 XML declaration in thescript?

Hello=20 there,

 

I just want to confirm if = XML=20 declaration

       =20 <?xml version=3D"1.0" encoding=3D"UTF-8"?>  =20

is a Required (MUST be) = part when=20 sending NetConf message OR is it an Optional? =

 

I can not find anything = that says:=20 “It’s a MUST to be” (in the NetConf docs) but one of = our guys raising it as a=20 High priority Issue.

 

Thanks,

Vlad

 

------_=_NextPart_001_01C97A8D.794A4921-- --===============0522520832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --===============0522520832==-- From netconf-bounces@ietf.org Wed Jan 21 01:15:33 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CA63A684C; Wed, 21 Jan 2009 01:15:33 -0800 (PST) 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 18BC63A684C for ; Wed, 21 Jan 2009 01:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 EhopjRgq4LIN for ; Wed, 21 Jan 2009 01:15:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E55DC3A67B3 for ; Wed, 21 Jan 2009 01:15:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 702A1C0010; Wed, 21 Jan 2009 10:15:15 +0100 (CET) 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 GFdUpyH0syDX; Wed, 21 Jan 2009 10:15:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05317C004A; Wed, 21 Jan 2009 10:15:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 444FC8FF4DA; Wed, 21 Jan 2009 10:15:05 +0100 (CET) Date: Wed, 21 Jan 2009 10:15:05 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090121091505.GA28159@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , netconf mailing list References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > All WG members, pls review and make sure we have your input BEFORE > Feb 1st. This is the first time I seriously read the document and here are the comments/questions that popped up: - What happens if one of the select expressions is invalid? - What happens if a target datastore does not exist? - Since new nodes are not added to the set of locked nodes, if I lock a subtree, can I run into race conditions? Suppose I am running a transaction that involves adding some nodes and doing some more work on them. Since there is no atomic way to add the nodes to the datastore and to add them to the lock set, I am concerned that race conditions might exist that can be exploited. Perhaps my problem is that I do not understand 2.4.1.2. What is the "the new section created"? Perhaps an example should be added to help me to understand how things work. If I have 1 2 and I do a partial lock on /top, what is the node set returned? Is /top/a locked now and what does it mean for a non-leaf node to be locked? I think this needs to be clearly spelled out. - I think the document should spell out how a lock affects other NETCONF operations. How does edit-config, copy-config etc fail if a locked node set if affected? This is related to me previous comment. - I have not reviewed the XSD. - The YANG module's organization, contact, description, and revision statements should in spirit follow RFC 4181. - I like to see more consistent indentation, in particular indentation of description statements. For example, I prefer typedef lock-id-type { description "A number identifying a specific partial-lock granted to a session. It is allocated by the system, and SHOULD be used in the partial-unlock operation."; type uint32; } over what is in the current document. - I am wondering whether the yang-types should provide a definition of a common type holding an xpath expression. /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 netconf-bounces@ietf.org Wed Jan 21 01:19:55 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CA63A684C; Wed, 21 Jan 2009 01:15:33 -0800 (PST) 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 18BC63A684C for ; Wed, 21 Jan 2009 01:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 EhopjRgq4LIN for ; Wed, 21 Jan 2009 01:15:32 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E55DC3A67B3 for ; Wed, 21 Jan 2009 01:15:31 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 702A1C0010; Wed, 21 Jan 2009 10:15:15 +0100 (CET) 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 GFdUpyH0syDX; Wed, 21 Jan 2009 10:15:09 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05317C004A; Wed, 21 Jan 2009 10:15:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 444FC8FF4DA; Wed, 21 Jan 2009 10:15:05 +0100 (CET) Date: Wed, 21 Jan 2009 10:15:05 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20090121091505.GA28159@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , netconf mailing list References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > All WG members, pls review and make sure we have your input BEFORE > Feb 1st. This is the first time I seriously read the document and here are the comments/questions that popped up: - What happens if one of the select expressions is invalid? - What happens if a target datastore does not exist? - Since new nodes are not added to the set of locked nodes, if I lock a subtree, can I run into race conditions? Suppose I am running a transaction that involves adding some nodes and doing some more work on them. Since there is no atomic way to add the nodes to the datastore and to add them to the lock set, I am concerned that race conditions might exist that can be exploited. Perhaps my problem is that I do not understand 2.4.1.2. What is the "the new section created"? Perhaps an example should be added to help me to understand how things work. If I have 1 2 and I do a partial lock on /top, what is the node set returned? Is /top/a locked now and what does it mean for a non-leaf node to be locked? I think this needs to be clearly spelled out. - I think the document should spell out how a lock affects other NETCONF operations. How does edit-config, copy-config etc fail if a locked node set if affected? This is related to me previous comment. - I have not reviewed the XSD. - The YANG module's organization, contact, description, and revision statements should in spirit follow RFC 4181. - I like to see more consistent indentation, in particular indentation of description statements. For example, I prefer typedef lock-id-type { description "A number identifying a specific partial-lock granted to a session. It is allocated by the system, and SHOULD be used in the partial-unlock operation."; type uint32; } over what is in the current document. - I am wondering whether the yang-types should provide a definition of a common type holding an xpath expression. /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 netconf-bounces@ietf.org Wed Jan 21 17:34:08 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B0E3A699E; Wed, 21 Jan 2009 17:34:08 -0800 (PST) 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 9A0743A699E for ; Wed, 21 Jan 2009 17:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 exfJxio2HPqy for ; Wed, 21 Jan 2009 17:34:06 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 954523A67C0 for ; Wed, 21 Jan 2009 17:34:06 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDU008LNN0ABU70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 22 Jan 2009 09:33:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDU00AZ8N08QZ10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 22 Jan 2009 09:33:46 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 22 Jan 2009 09:33:44 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 22 Jan 2009 09:33:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090121091505.GA28159@elstar.local> References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > > > All WG members, pls review and make sure we have your input BEFORE > > Feb 1st. > > This is the first time I seriously read the document and here are the > comments/questions that popped up: > > - What happens if one of the select expressions is invalid? I think this select expr would return empty. > - What happens if a target datastore does not exist? I think all select expr evaluated for this datastore would return empty. > - Since new nodes are not added to the set of locked nodes, if I lock > a subtree, can I run into race conditions? Suppose I am running a > transaction that involves adding some nodes and doing some more work > on them. Since there is no atomic way to add the nodes to the > datastore and to add them to the lock set, I am concerned that race > conditions might exist that can be exploited. > > Perhaps my problem is that I do not understand 2.4.1.2. What is the > "the new section created"? Perhaps an example should be added to > help me to understand how things work. If I have > > > > 1 > 2 > > > > and I do a partial lock on /top, what is the node set returned? Is > /top/a locked now and what does it mean for a non-leaf node to be > locked? I think this needs to be clearly spelled out. I'd like try to answer this question, although I am not sure I completely understand what you are asking. If you do a partial lock on /top, the returned node set, which is termed as *scope of lock*, is node, but the *protected area* is node and all nodes underneath it. I'd like explain sec 2.4.1.2 using your example. If I want to create a directly under , I can't lock /top/c, as is non-existent. What I should do is lock first, then create , then, lock /top/c and unlock /top, after that I can operate on /top/c. I hope that helps. washam > - I think the document should spell out how a lock affects other > NETCONF operations. How does edit-config, copy-config etc fail if a > locked node set if affected? This is related to me previous comment. > > - I have not reviewed the XSD. > > - The YANG module's organization, contact, description, and revision > statements should in spirit follow RFC 4181. > > - I like to see more consistent indentation, in particular indentation > of description statements. For example, I prefer > > typedef lock-id-type { > description > "A number identifying a specific partial-lock granted to a > session. It is allocated by the system, and SHOULD be used in > the partial-unlock operation."; > type uint32; > } > > over what is in the current document. > > - I am wondering whether the yang-types should provide a definition of > a common type holding an xpath expression. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 21 17:34:08 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B0E3A699E; Wed, 21 Jan 2009 17:34:08 -0800 (PST) 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 9A0743A699E for ; Wed, 21 Jan 2009 17:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, 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 exfJxio2HPqy for ; Wed, 21 Jan 2009 17:34:06 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 954523A67C0 for ; Wed, 21 Jan 2009 17:34:06 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDU008LNN0ABU70@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Thu, 22 Jan 2009 09:33:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDU00AZ8N08QZ10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Thu, 22 Jan 2009 09:33:46 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Thu, 22 Jan 2009 09:33:44 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Thu, 22 Jan 2009 09:33:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090121091505.GA28159@elstar.local> References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > > > All WG members, pls review and make sure we have your input BEFORE > > Feb 1st. > > This is the first time I seriously read the document and here are the > comments/questions that popped up: > > - What happens if one of the select expressions is invalid? I think this select expr would return empty. > - What happens if a target datastore does not exist? I think all select expr evaluated for this datastore would return empty. > - Since new nodes are not added to the set of locked nodes, if I lock > a subtree, can I run into race conditions? Suppose I am running a > transaction that involves adding some nodes and doing some more work > on them. Since there is no atomic way to add the nodes to the > datastore and to add them to the lock set, I am concerned that race > conditions might exist that can be exploited. > > Perhaps my problem is that I do not understand 2.4.1.2. What is the > "the new section created"? Perhaps an example should be added to > help me to understand how things work. If I have > > > > 1 > 2 > > > > and I do a partial lock on /top, what is the node set returned? Is > /top/a locked now and what does it mean for a non-leaf node to be > locked? I think this needs to be clearly spelled out. I'd like try to answer this question, although I am not sure I completely understand what you are asking. If you do a partial lock on /top, the returned node set, which is termed as *scope of lock*, is node, but the *protected area* is node and all nodes underneath it. I'd like explain sec 2.4.1.2 using your example. If I want to create a directly under , I can't lock /top/c, as is non-existent. What I should do is lock first, then create , then, lock /top/c and unlock /top, after that I can operate on /top/c. I hope that helps. washam > - I think the document should spell out how a lock affects other > NETCONF operations. How does edit-config, copy-config etc fail if a > locked node set if affected? This is related to me previous comment. > > - I have not reviewed the XSD. > > - The YANG module's organization, contact, description, and revision > statements should in spirit follow RFC 4181. > > - I like to see more consistent indentation, in particular indentation > of description statements. For example, I prefer > > typedef lock-id-type { > description > "A number identifying a specific partial-lock granted to a > session. It is allocated by the system, and SHOULD be used in > the partial-unlock operation."; > type uint32; > } > > over what is in the current document. > > - I am wondering whether the yang-types should provide a definition of > a common type holding an xpath expression. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 21 23:05:43 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E4D3A699E; Wed, 21 Jan 2009 23:05:43 -0800 (PST) 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 524D83A685D for ; Wed, 21 Jan 2009 23:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 uryYoy6uhfZ4 for ; Wed, 21 Jan 2009 23:05:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7F35E3A699E for ; Wed, 21 Jan 2009 23:05:41 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B575A76C040; Thu, 22 Jan 2009 08:05:24 +0100 (CET) Date: Thu, 22 Jan 2009 08:05:21 +0100 (CET) Message-Id: <20090122.080521.42945278.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WashamFan wrote: > Hi, > > > On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > > > > > All WG members, pls review and make sure we have your input BEFORE > > > Feb 1st. > > > > This is the first time I seriously read the document and here are the > > comments/questions that popped up: > > > > - What happens if one of the select expressions is invalid? > I think this select expr would return empty. I think Juergen meant what happens if the expression isn't even valid XPath syntax. In this case an rpc-error should be returned with an 'invalid-value' error. > > - What happens if a target datastore does not exist? > I think all select expr evaluated for this datastore would return empty. I think this should also generate an 'invalid-value' error. > > Perhaps my problem is that I do not understand 2.4.1.2. What is the > > "the new section created"? Maybe write "newly created subtree" instead? At least s/section/subtree/. > > - I think the document should spell out how a lock affects other > > NETCONF operations. How does edit-config, copy-config etc fail if a > > locked node set if affected? This is related to me previous comment. This is supposed to be coverd in 2.5. Is more needed? > > - I am wondering whether the yang-types should provide a definition of > > a common type holding an xpath expression. I think that is a good idea. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 21 23:05:43 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E4D3A699E; Wed, 21 Jan 2009 23:05:43 -0800 (PST) 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 524D83A685D for ; Wed, 21 Jan 2009 23:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 uryYoy6uhfZ4 for ; Wed, 21 Jan 2009 23:05:41 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 7F35E3A699E for ; Wed, 21 Jan 2009 23:05:41 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id B575A76C040; Thu, 22 Jan 2009 08:05:24 +0100 (CET) Date: Thu, 22 Jan 2009 08:05:21 +0100 (CET) Message-Id: <20090122.080521.42945278.mbj@tail-f.com> To: Washam.Fan@huaweisymantec.com From: Martin Bjorklund In-Reply-To: References: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org WashamFan wrote: > Hi, > > > On Mon, Jan 19, 2009 at 05:57:54PM +0100, Bert Wijnen (IETF) wrote: > > > > > All WG members, pls review and make sure we have your input BEFORE > > > Feb 1st. > > > > This is the first time I seriously read the document and here are the > > comments/questions that popped up: > > > > - What happens if one of the select expressions is invalid? > I think this select expr would return empty. I think Juergen meant what happens if the expression isn't even valid XPath syntax. In this case an rpc-error should be returned with an 'invalid-value' error. > > - What happens if a target datastore does not exist? > I think all select expr evaluated for this datastore would return empty. I think this should also generate an 'invalid-value' error. > > Perhaps my problem is that I do not understand 2.4.1.2. What is the > > "the new section created"? Maybe write "newly created subtree" instead? At least s/section/subtree/. > > - I think the document should spell out how a lock affects other > > NETCONF operations. How does edit-config, copy-config etc fail if a > > locked node set if affected? This is related to me previous comment. This is supposed to be coverd in 2.5. Is more needed? > > - I am wondering whether the yang-types should provide a definition of > > a common type holding an xpath expression. I think that is a good idea. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 21 23:29:32 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9C03A69EB; Wed, 21 Jan 2009 23:29:32 -0800 (PST) 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 9C3103A685D for ; Wed, 21 Jan 2009 23:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 BFYSs1zaCTA5 for ; Wed, 21 Jan 2009 23:29:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 78D133A699E for ; Wed, 21 Jan 2009 23:29:29 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F772C000D; Thu, 22 Jan 2009 08:29:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hRkXDzJNTzkV; Thu, 22 Jan 2009 08:29:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D7B3C0027; Thu, 22 Jan 2009 08:29:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D33AB900AD3; Thu, 22 Jan 2009 08:29:01 +0100 (CET) Date: Thu, 22 Jan 2009 08:29:01 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090122072901.GA606@elstar.local> Mail-Followup-To: Martin Bjorklund , Washam.Fan@huaweisymantec.com, netconf@ietf.org References: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <20090122.080521.42945278.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090122.080521.42945278.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jan 22, 2009 at 08:05:21AM +0100, Martin Bjorklund wrote: > > > - I think the document should spell out how a lock affects other > > > NETCONF operations. How does edit-config, copy-config etc fail if a > > > locked node set if affected? This is related to me previous comment. > > This is supposed to be coverd in 2.5. Is more needed? For example, how do locking errors relate to the error-option of edit-config? Consider an edit-config modifying a node-set of which a subset is locked. Does the edit-config fail in all cases? Or does lets say continue-on-error still cause those nodes not locked to be changed? I think it is good to have these details documented. /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 netconf-bounces@ietf.org Wed Jan 21 23:29:32 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9C03A69EB; Wed, 21 Jan 2009 23:29:32 -0800 (PST) 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 9C3103A685D for ; Wed, 21 Jan 2009 23:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 BFYSs1zaCTA5 for ; Wed, 21 Jan 2009 23:29:29 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 78D133A699E for ; Wed, 21 Jan 2009 23:29:29 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9F772C000D; Thu, 22 Jan 2009 08:29:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hRkXDzJNTzkV; Thu, 22 Jan 2009 08:29:06 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D7B3C0027; Thu, 22 Jan 2009 08:29:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D33AB900AD3; Thu, 22 Jan 2009 08:29:01 +0100 (CET) Date: Thu, 22 Jan 2009 08:29:01 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090122072901.GA606@elstar.local> Mail-Followup-To: Martin Bjorklund , Washam.Fan@huaweisymantec.com, netconf@ietf.org References: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <20090122.080521.42945278.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090122.080521.42945278.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Thu, Jan 22, 2009 at 08:05:21AM +0100, Martin Bjorklund wrote: > > > - I think the document should spell out how a lock affects other > > > NETCONF operations. How does edit-config, copy-config etc fail if a > > > locked node set if affected? This is related to me previous comment. > > This is supposed to be coverd in 2.5. Is more needed? For example, how do locking errors relate to the error-option of edit-config? Consider an edit-config modifying a node-set of which a subset is locked. Does the edit-config fail in all cases? Or does lets say continue-on-error still cause those nodes not locked to be changed? I think it is good to have these details documented. /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 netconf-bounces@ietf.org Wed Jan 21 23:37:21 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3153A6A6E; Wed, 21 Jan 2009 23:37:21 -0800 (PST) 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 933B13A6A6E for ; Wed, 21 Jan 2009 23:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 01AAv2B8oF0R for ; Wed, 21 Jan 2009 23:37:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4AB0F3A699E for ; Wed, 21 Jan 2009 23:37:15 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7387276C040; Thu, 22 Jan 2009 08:36:58 +0100 (CET) Date: Thu, 22 Jan 2009 08:36:53 +0100 (CET) Message-Id: <20090122.083653.38607212.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090122072901.GA606@elstar.local> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > For example, how do locking errors relate to the error-option of > edit-config? Consider an edit-config modifying a node-set of which a > subset is locked. Does the edit-config fail in all cases? Or does lets > say continue-on-error still cause those nodes not locked to be > changed? I think it is good to have these details documented. Good point! This hasn't been discussed at all in the WG. One problem here is that the meaning of "continue-on-error" is unclear; this has been discussed several times. Specifically, is the "error" part of "continue-on-error" supposed to cover this kind of transient errors? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Jan 21 23:37:21 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3153A6A6E; Wed, 21 Jan 2009 23:37:21 -0800 (PST) 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 933B13A6A6E for ; Wed, 21 Jan 2009 23:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=0.030, 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 01AAv2B8oF0R for ; Wed, 21 Jan 2009 23:37:15 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4AB0F3A699E for ; Wed, 21 Jan 2009 23:37:15 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7387276C040; Thu, 22 Jan 2009 08:36:58 +0100 (CET) Date: Thu, 22 Jan 2009 08:36:53 +0100 (CET) Message-Id: <20090122.083653.38607212.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090122072901.GA606@elstar.local> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > For example, how do locking errors relate to the error-option of > edit-config? Consider an edit-config modifying a node-set of which a > subset is locked. Does the edit-config fail in all cases? Or does lets > say continue-on-error still cause those nodes not locked to be > changed? I think it is good to have these details documented. Good point! This hasn't been discussed at all in the WG. One problem here is that the meaning of "continue-on-error" is unclear; this has been discussed several times. Specifically, is the "error" part of "continue-on-error" supposed to cover this kind of transient errors? /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 22 21:42:02 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF49D3A68C4; Thu, 22 Jan 2009 21:42:01 -0800 (PST) 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 317A03A6838 for ; Thu, 22 Jan 2009 21:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 BqwYwqWlLT7s for ; Thu, 22 Jan 2009 21:41:59 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 348B03A6801 for ; Thu, 22 Jan 2009 21:41:59 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDW00BV8T5CRO00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 23 Jan 2009 13:41:38 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDW004DAT5AVQ00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 23 Jan 2009 13:41:36 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 23 Jan 2009 13:41:34 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Fri, 23 Jan 2009 13:41:34 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090122.083653.38607212.mbj@tail-f.com> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Juergen Schoenwaelder wrote: > > For example, how do locking errors relate to the error-option of > > edit-config? Why should we treat errors caused by lock differently. "continue-on-error" take effect on all errors including those caused by lock. >Consider an edit-config modifying a node-set of which > a > > subset is locked. Does the edit-config fail in all cases? Or does lets > > say continue-on-error still cause those nodes not locked to be > > changed? I think it is good to have these details documented. > > Good point! This hasn't been discussed at all in the WG. One problem > here is that the meaning of "continue-on-error" is unclear; this has > been discussed several times. Specifically, is the "error" part of > "continue-on-error" supposed to cover this kind of transient errors? Yes, the error caused by lock is not the real error, but operator could recognize it in response. The error lead to partial failure at least. IMO, it is covered by "error" part of "continue-on-error". washam > > /martin > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 22 21:42:02 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF49D3A68C4; Thu, 22 Jan 2009 21:42:01 -0800 (PST) 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 317A03A6838 for ; Thu, 22 Jan 2009 21:42:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 BqwYwqWlLT7s for ; Thu, 22 Jan 2009 21:41:59 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 348B03A6801 for ; Thu, 22 Jan 2009 21:41:59 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDW00BV8T5CRO00@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Fri, 23 Jan 2009 13:41:38 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDW004DAT5AVQ00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Fri, 23 Jan 2009 13:41:36 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Fri, 23 Jan 2009 13:41:34 +0800 From: WashamFan To: Martin Bjorklund Message-id: Date: Fri, 23 Jan 2009 13:41:34 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090122.083653.38607212.mbj@tail-f.com> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Juergen Schoenwaelder wrote: > > For example, how do locking errors relate to the error-option of > > edit-config? Why should we treat errors caused by lock differently. "continue-on-error" take effect on all errors including those caused by lock. >Consider an edit-config modifying a node-set of which > a > > subset is locked. Does the edit-config fail in all cases? Or does lets > > say continue-on-error still cause those nodes not locked to be > > changed? I think it is good to have these details documented. > > Good point! This hasn't been discussed at all in the WG. One problem > here is that the meaning of "continue-on-error" is unclear; this has > been discussed several times. Specifically, is the "error" part of > "continue-on-error" supposed to cover this kind of transient errors? Yes, the error caused by lock is not the real error, but operator could recognize it in response. The error lead to partial failure at least. IMO, it is covered by "error" part of "continue-on-error". washam > > /martin > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 05:01:21 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD9828C15B; Fri, 23 Jan 2009 05:01:21 -0800 (PST) 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 3CC7E3A6837 for ; Fri, 23 Jan 2009 05:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, 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 4nEa2Lj3b2L6 for ; Fri, 23 Jan 2009 05:01:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 05A4328C15B for ; Fri, 23 Jan 2009 05:00:59 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABC8FC002B for ; Fri, 23 Jan 2009 14:00:41 +0100 (CET) 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 CL5lQG1fNEkd; Fri, 23 Jan 2009 14:00:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3EE5C000B; Fri, 23 Jan 2009 14:00:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 725399181EB; Fri, 23 Jan 2009 14:00:28 +0100 (CET) Date: Fri, 23 Jan 2009 14:00:28 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20090123130028.GA8291@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Here is my review of : a) The abstract does (a) not summarize all the things covered in the data model and (b) is too long an detailed for the things covered. I propose to compose a new short abstract and to move most of the existing text into section 1 before 1.1, extending it as needed. b) The document assumes that capabilities / schemas can dynamically change and it kind of assumes that applications poll the /netconf/schema tree. I am wondering where there is not a notification defined so that I can subscribe and get notified if the capabilities / schemas change. c) Terminology: Operation: This term is used to refer to NETCONF protocol operations. Specifically within this document, operation refers to NETCONF protocol operations defined in support of NETCONF monitoring. I fail to see value in giving the term operation a more constrainted meaning. I prefer to have the term used with the normal RFC 4741 meaning. d) Terminology: Schema: This term is used to refer to a data model fragment, independent of which data modeling language is used in the data model. What is a "data model fragment"? I suggest to replace this phrase with "a machine readable data model definition". e) I would prefer if section 2. would focus on the XML instance document structure and be more data modeling language agnostic. I believe this improves readability since instance document structure is really the most important to get right. I will detail concrete changes in the following comments. f) Change title of 2.1 to: The /netconf Subtree g) Turn the first two sentence fragements into full sentences: The /netconf subtree is the root of the monitoring data model. It acts as a container for the other monitored data. h) I suggested to rename "configurations" to "datastores" since this seems to be the more appropriate term. So things become: datastores: (type: ConfigurationDatastore) List of NETCONF datastores on the server. Includes all supported datastore types (running, candidate, startup). i) Wording change (use plural). OLD: schemas (type: SchemaEntry) List of schemas supported on the server. Includes all the information required to identify the schema and to support its retrieval. NEW: schemas (type: SchemaEntry) List of schemas supported on the server. Includes all the information required to identify schemas and to support their retrieval. j) Clarification needed: sessions (type: ManagementSession) List of all active sessions on the device including NETCONF and other sessions (eg: CLI). I think this needs clarification. I doubt you want to report a normal user login on a Unix server, or was that the intention? k) Change title of 2.1.1 to: The /netconf/capabilities Subtree l) Can capabilities announced during be dropped without closing the session? If not, then the text should be changed. OLD: The list MUST include all capabilities exchanged during session setup still applicable at the time of the request. NEW: The list MUST include all capabilities exchanged during session setup. m) Change title of 2.1.2 to: The /netconf/datastores Subtree n) Make the first sentence in 2.1.2 a full sentence. o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and such things and this requires to first read the data model in order to understand this text. This might require to introduce a subsection describing the /netconf/datastore/locks subtree. p) Change title of 2.1.3 to: The /netconf/schemas Subtree q) I suggest to rename schema/identifier to schema/name. After all, it contains a name. See also s) below. r) Terminology consistency change: OLD: They are also used in the RPC. NEW: They are also used in the operation. s) The description leaves it open whether the identifier (or name) contains a module name or a file name. This is not good for interoperability. Furthermore, the YANG description tells me again something different. I suggest that it must be the module name for data modeling languages that have a concept of a module name and it may be a filename in other cases. t) Editorial: OLD: Each MUST be reported NEW: Each version MUST be reported u) You make the assumption that a schema can only define one namespace. This might be OK but I wanted to spell this out so that the WG takes this design decision not by accident. v) The location description is not consistent with the schemas and the examples since it is actually a list. Well, the YANG says it is a leaf but the example shows the encoding of a leaf-list. This is screwed up (and probably the example is right). w) The union of a string with the magic value "NETCONF" and a URI looks really ugly. I suggest that a location leaf always contains a URI. If you need a mechanism to indicate retrieval via get-schema, create another empty leaf that is only present if retrieval is possible via NETCONF get-schema. x) Change title of 2.1.4 to: The /netconf/sessions Subtree y) I believe this needs better wording: username (type: xs:string) Session owner. I do not think NETCONF has a notion of session ownership. I think I know what you mean but it needs to be written down properly (and I am not sure to what extend the username is not transport specific). z) I fail to see why sourceHost is included at all. The IP address or a DNS name is not sufficient to identify a client in all cases and the value of this diminishes greatly if you have NATs and so on. But the most important problem I have is that an IP address is not a transport endpoint. A) Change title of 2.1.5 to: The /netconf/subscriptions Subtree B) The description of SesionId is screwed up: sessionId (type: SessionId) Unique identifier for the notifications. MUST return the same value as returned in 'sessions' to allow correlation. This is not an identifier for notifications. You probably want something like this: sessionId (type: SessionId) A unique identifier for a session carrying notifications. The value of sessionId MUST be the same as the value of the corresponding /netconf/sessions/sessionId to allow correlation. C) For me, messagesSent does not belong into /netconf/subscriptions since it is a statistics counter. I know, it is right now the only session specific counter but that is not a good argument to be inconsistent in the organization of the tree. Other session counters might be added in the future. D) Change title of 2.1.6 to: The /netconf/statistics Subtree E) Add a tree layout figure similar to all the other sections. F) The document assumes zero-based counters and no rollovers ever happen: Ie: current time - startTime defines the collection interval for the metrics allowing for calculations such as averages. SNMP people might find this approach broken. G) I tried to draw a case diagram for the counters and I failed. I believe the counters are not well thought out. Perhaps it helps to draw case diagrams and to organize suitable counters along the netconf protocol layers. H) Change title of 3.1 to: The Operation I) Change the first input argument to name (see above) and the description as follows: name (type: xs:string): Name of the schema to be retrieved. Typically the module name or filename of the schema. J) Wording change: OLD: format (type: SchemaFormat): The data modeling language of the file/ module. NEW: format (type: SchemaFormat): The data modeling language of the schema. K) Why is the schema in the example returned in CDATA?? L) Rewording: OLD: A NETCONF client retrieves the list of supported XML Schema from a NETCONF server using the RPC request. The list of available XML Schema is retrieved by requesting the subtree via a operation. NEW: A NETCONF client retrieves the list of supported schema from a NETCONF server using the operation by retrieving the /netconf/schema subtree via a operation. M) Editorial changes: OLD: ie. NEW: i.e., OLD: http.i NEW: http OLD: RPC NEW: operation N) I did not review the XML schema definitions. The pattern in the ipAddress schema differ from the pattern in yang-types, I am not sure at the moment this impacts semantics. Since the sourceHost definition seems not very useful in the first place, my suggestion would be to nuke sourceHost and with it the whole XML Schema definition of an IP address type. O) The security considerations just say "be careful" which I think will not be sufficient to pass the security area. P) Acknowledgements: I think the phrase "earlier draft of Schema" needs to be rewritten and I think it is more appropriate to acknowledge the authors of the earlier schema drafts rather than the whole WG. Q) Appendix A introduction rewrite: OLD The following YANG module is included as a reference only. It is based on YANG definition at the time of publishing and is subject to change as a result of netmod work underway to refine YANG. Further details on YANG and updated non-normative reference to this model are available at: http://www.yang-central.org/twiki/bin/view/Main/YangExamples. NEW The following YANG module is included as a reference only. It is based on YANG specification at the time of publishing and is subject to change as a result of NETMOD work underway to refine YANG. I suggest to remove the online reference since it is hard to guarantee that this is kept updated. R) Yang meta information should in spririt follow RFC 4181. S) I think it is useful to write reference statements in the following format: reference "RFC 4741: NETCONF Configuration Protocol" Not every reader knows RFC numbers by heart. T) I am concerned about the extensibility of some of the type definitions. Some should probably be maintained by IANA. Andy recently published a YANG module for NETCONF and in the ideal world, this document would import some of the needed type from the YANG module for NETCONF. U) SSL should be TLS V) What is WebUI? How does a NETCONF server determine whether a client is a CLI, NETCONF, or WebUI?? W) There are many statements without descriptions and I believe it would be useful to repeat text from section 2 in the data model so that it becomes selfcontained. X) I prefer a naming style where short names that are meaningful in the context of an instance document are used. For example, I like 42 12 42 .. .. .. over what the document actually produces. Y) A description of lockId is needed to make it clear that it is the value returned by and the partial locking draft must be clarified that the lock id is globally unique within a NETCONF server so that it can actually serve as a key here without having to scope it by the sessionId. Z) I see another case where a common xpath data type would make sense. +) In the statistics section, language needs to be more precise. What is a "correctly started session"? What are "sessions started towards the NETCONF peer"? /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 netconf-bounces@ietf.org Fri Jan 23 05:01:21 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD9828C15B; Fri, 23 Jan 2009 05:01:21 -0800 (PST) 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 3CC7E3A6837 for ; Fri, 23 Jan 2009 05:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, 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 4nEa2Lj3b2L6 for ; Fri, 23 Jan 2009 05:01:19 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 05A4328C15B for ; Fri, 23 Jan 2009 05:00:59 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id ABC8FC002B for ; Fri, 23 Jan 2009 14:00:41 +0100 (CET) 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 CL5lQG1fNEkd; Fri, 23 Jan 2009 14:00:33 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A3EE5C000B; Fri, 23 Jan 2009 14:00:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 725399181EB; Fri, 23 Jan 2009 14:00:28 +0100 (CET) Date: Fri, 23 Jan 2009 14:00:28 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20090123130028.GA8291@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Here is my review of : a) The abstract does (a) not summarize all the things covered in the data model and (b) is too long an detailed for the things covered. I propose to compose a new short abstract and to move most of the existing text into section 1 before 1.1, extending it as needed. b) The document assumes that capabilities / schemas can dynamically change and it kind of assumes that applications poll the /netconf/schema tree. I am wondering where there is not a notification defined so that I can subscribe and get notified if the capabilities / schemas change. c) Terminology: Operation: This term is used to refer to NETCONF protocol operations. Specifically within this document, operation refers to NETCONF protocol operations defined in support of NETCONF monitoring. I fail to see value in giving the term operation a more constrainted meaning. I prefer to have the term used with the normal RFC 4741 meaning. d) Terminology: Schema: This term is used to refer to a data model fragment, independent of which data modeling language is used in the data model. What is a "data model fragment"? I suggest to replace this phrase with "a machine readable data model definition". e) I would prefer if section 2. would focus on the XML instance document structure and be more data modeling language agnostic. I believe this improves readability since instance document structure is really the most important to get right. I will detail concrete changes in the following comments. f) Change title of 2.1 to: The /netconf Subtree g) Turn the first two sentence fragements into full sentences: The /netconf subtree is the root of the monitoring data model. It acts as a container for the other monitored data. h) I suggested to rename "configurations" to "datastores" since this seems to be the more appropriate term. So things become: datastores: (type: ConfigurationDatastore) List of NETCONF datastores on the server. Includes all supported datastore types (running, candidate, startup). i) Wording change (use plural). OLD: schemas (type: SchemaEntry) List of schemas supported on the server. Includes all the information required to identify the schema and to support its retrieval. NEW: schemas (type: SchemaEntry) List of schemas supported on the server. Includes all the information required to identify schemas and to support their retrieval. j) Clarification needed: sessions (type: ManagementSession) List of all active sessions on the device including NETCONF and other sessions (eg: CLI). I think this needs clarification. I doubt you want to report a normal user login on a Unix server, or was that the intention? k) Change title of 2.1.1 to: The /netconf/capabilities Subtree l) Can capabilities announced during be dropped without closing the session? If not, then the text should be changed. OLD: The list MUST include all capabilities exchanged during session setup still applicable at the time of the request. NEW: The list MUST include all capabilities exchanged during session setup. m) Change title of 2.1.2 to: The /netconf/datastores Subtree n) Make the first sentence in 2.1.2 a full sentence. o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and such things and this requires to first read the data model in order to understand this text. This might require to introduce a subsection describing the /netconf/datastore/locks subtree. p) Change title of 2.1.3 to: The /netconf/schemas Subtree q) I suggest to rename schema/identifier to schema/name. After all, it contains a name. See also s) below. r) Terminology consistency change: OLD: They are also used in the RPC. NEW: They are also used in the operation. s) The description leaves it open whether the identifier (or name) contains a module name or a file name. This is not good for interoperability. Furthermore, the YANG description tells me again something different. I suggest that it must be the module name for data modeling languages that have a concept of a module name and it may be a filename in other cases. t) Editorial: OLD: Each MUST be reported NEW: Each version MUST be reported u) You make the assumption that a schema can only define one namespace. This might be OK but I wanted to spell this out so that the WG takes this design decision not by accident. v) The location description is not consistent with the schemas and the examples since it is actually a list. Well, the YANG says it is a leaf but the example shows the encoding of a leaf-list. This is screwed up (and probably the example is right). w) The union of a string with the magic value "NETCONF" and a URI looks really ugly. I suggest that a location leaf always contains a URI. If you need a mechanism to indicate retrieval via get-schema, create another empty leaf that is only present if retrieval is possible via NETCONF get-schema. x) Change title of 2.1.4 to: The /netconf/sessions Subtree y) I believe this needs better wording: username (type: xs:string) Session owner. I do not think NETCONF has a notion of session ownership. I think I know what you mean but it needs to be written down properly (and I am not sure to what extend the username is not transport specific). z) I fail to see why sourceHost is included at all. The IP address or a DNS name is not sufficient to identify a client in all cases and the value of this diminishes greatly if you have NATs and so on. But the most important problem I have is that an IP address is not a transport endpoint. A) Change title of 2.1.5 to: The /netconf/subscriptions Subtree B) The description of SesionId is screwed up: sessionId (type: SessionId) Unique identifier for the notifications. MUST return the same value as returned in 'sessions' to allow correlation. This is not an identifier for notifications. You probably want something like this: sessionId (type: SessionId) A unique identifier for a session carrying notifications. The value of sessionId MUST be the same as the value of the corresponding /netconf/sessions/sessionId to allow correlation. C) For me, messagesSent does not belong into /netconf/subscriptions since it is a statistics counter. I know, it is right now the only session specific counter but that is not a good argument to be inconsistent in the organization of the tree. Other session counters might be added in the future. D) Change title of 2.1.6 to: The /netconf/statistics Subtree E) Add a tree layout figure similar to all the other sections. F) The document assumes zero-based counters and no rollovers ever happen: Ie: current time - startTime defines the collection interval for the metrics allowing for calculations such as averages. SNMP people might find this approach broken. G) I tried to draw a case diagram for the counters and I failed. I believe the counters are not well thought out. Perhaps it helps to draw case diagrams and to organize suitable counters along the netconf protocol layers. H) Change title of 3.1 to: The Operation I) Change the first input argument to name (see above) and the description as follows: name (type: xs:string): Name of the schema to be retrieved. Typically the module name or filename of the schema. J) Wording change: OLD: format (type: SchemaFormat): The data modeling language of the file/ module. NEW: format (type: SchemaFormat): The data modeling language of the schema. K) Why is the schema in the example returned in CDATA?? L) Rewording: OLD: A NETCONF client retrieves the list of supported XML Schema from a NETCONF server using the RPC request. The list of available XML Schema is retrieved by requesting the subtree via a operation. NEW: A NETCONF client retrieves the list of supported schema from a NETCONF server using the operation by retrieving the /netconf/schema subtree via a operation. M) Editorial changes: OLD: ie. NEW: i.e., OLD: http.i NEW: http OLD: RPC NEW: operation N) I did not review the XML schema definitions. The pattern in the ipAddress schema differ from the pattern in yang-types, I am not sure at the moment this impacts semantics. Since the sourceHost definition seems not very useful in the first place, my suggestion would be to nuke sourceHost and with it the whole XML Schema definition of an IP address type. O) The security considerations just say "be careful" which I think will not be sufficient to pass the security area. P) Acknowledgements: I think the phrase "earlier draft of Schema" needs to be rewritten and I think it is more appropriate to acknowledge the authors of the earlier schema drafts rather than the whole WG. Q) Appendix A introduction rewrite: OLD The following YANG module is included as a reference only. It is based on YANG definition at the time of publishing and is subject to change as a result of netmod work underway to refine YANG. Further details on YANG and updated non-normative reference to this model are available at: http://www.yang-central.org/twiki/bin/view/Main/YangExamples. NEW The following YANG module is included as a reference only. It is based on YANG specification at the time of publishing and is subject to change as a result of NETMOD work underway to refine YANG. I suggest to remove the online reference since it is hard to guarantee that this is kept updated. R) Yang meta information should in spririt follow RFC 4181. S) I think it is useful to write reference statements in the following format: reference "RFC 4741: NETCONF Configuration Protocol" Not every reader knows RFC numbers by heart. T) I am concerned about the extensibility of some of the type definitions. Some should probably be maintained by IANA. Andy recently published a YANG module for NETCONF and in the ideal world, this document would import some of the needed type from the YANG module for NETCONF. U) SSL should be TLS V) What is WebUI? How does a NETCONF server determine whether a client is a CLI, NETCONF, or WebUI?? W) There are many statements without descriptions and I believe it would be useful to repeat text from section 2 in the data model so that it becomes selfcontained. X) I prefer a naming style where short names that are meaningful in the context of an instance document are used. For example, I like 42 12 42 .. .. .. over what the document actually produces. Y) A description of lockId is needed to make it clear that it is the value returned by and the partial locking draft must be clarified that the lock id is globally unique within a NETCONF server so that it can actually serve as a key here without having to scope it by the sessionId. Z) I see another case where a common xpath data type would make sense. +) In the statistics section, language needs to be more precise. What is a "correctly started session"? What are "sessions started towards the NETCONF peer"? /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 netconf-bounces@ietf.org Fri Jan 23 05:12:30 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA073A6867; Fri, 23 Jan 2009 05:12:30 -0800 (PST) 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 07F0C3A691B for ; Fri, 23 Jan 2009 05:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=-1.955, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 orcUgABuOqxf for ; Fri, 23 Jan 2009 05:12:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8578028C0EE for ; Fri, 23 Jan 2009 05:12:25 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33967203B2; Fri, 23 Jan 2009 14:12:07 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-db-4979c2271093 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 12B18200C8; Fri, 23 Jan 2009 14:12:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:12:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:12:06 +0100 Message-ID: <4979C226.20200@ericsson.com> Date: Fri, 23 Jan 2009 14:12:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> In-Reply-To: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> X-OriginalArrivalTime: 23 Jan 2009 13:12:06.0321 (UTC) FILETIME=[30A2D210:01C97D5C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bert, See below! Balazs Bert Wijnen (IETF) wrote: > > - I notice in section 2.1 (page 4) that you changed > > into > partial-unlock > But in the last para of section 2,1 you do talk about > Inconsistent? BALAZS: Yes inconsistent, changed back to > > - This sentence (3rd bullet page 7): > The NETCONF server implements access control, and the locking user > does not have sufficient access rights. .... > Do you mean s/does not/must/ ?? BALAZS: We meant "does not" as written. This is not a requirement, we just state that if access rights happen to be insufficient, partial-lock fails. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 05:12:30 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA073A6867; Fri, 23 Jan 2009 05:12:30 -0800 (PST) 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 07F0C3A691B for ; Fri, 23 Jan 2009 05:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.204 X-Spam-Level: X-Spam-Status: No, score=-4.204 tagged_above=-999 required=5 tests=[AWL=-1.955, BAYES_00=-2.599, HELO_EQ_SE=0.35] 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 orcUgABuOqxf for ; Fri, 23 Jan 2009 05:12:29 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8578028C0EE for ; Fri, 23 Jan 2009 05:12:25 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 33967203B2; Fri, 23 Jan 2009 14:12:07 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-db-4979c2271093 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 12B18200C8; Fri, 23 Jan 2009 14:12:07 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:12:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:12:06 +0100 Message-ID: <4979C226.20200@ericsson.com> Date: Fri, 23 Jan 2009 14:12:06 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> In-Reply-To: <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> X-OriginalArrivalTime: 23 Jan 2009 13:12:06.0321 (UTC) FILETIME=[30A2D210:01C97D5C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Bert, See below! Balazs Bert Wijnen (IETF) wrote: > > - I notice in section 2.1 (page 4) that you changed > > into > partial-unlock > But in the last para of section 2,1 you do talk about > Inconsistent? BALAZS: Yes inconsistent, changed back to > > - This sentence (3rd bullet page 7): > The NETCONF server implements access control, and the locking user > does not have sufficient access rights. .... > Do you mean s/does not/must/ ?? BALAZS: We meant "does not" as written. This is not a requirement, we just state that if access rights happen to be insufficient, partial-lock fails. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 05:16:37 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6F13A6858; Fri, 23 Jan 2009 05:16:37 -0800 (PST) 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 54CD43A6858 for ; Fri, 23 Jan 2009 05:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ih+X+8ka4JdP for ; Fri, 23 Jan 2009 05:16:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 498EC3A6837 for ; Fri, 23 Jan 2009 05:16:35 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4203920024; Fri, 23 Jan 2009 14:16:17 +0100 (CET) X-AuditID: c1b4fb3c-ac75bbb00000304c-e0-4979c31c7d95 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48DCF206AC; Fri, 23 Jan 2009 14:16:12 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:16:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:16:10 +0100 Message-ID: <4979C319.1040305@ericsson.com> Date: Fri, 23 Jan 2009 14:16:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> In-Reply-To: X-OriginalArrivalTime: 23 Jan 2009 13:16:10.0144 (UTC) FILETIME=[C1F74200:01C97D5C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Washam, Yes you understood it correctly. Thanks. Balazs WashamFan wrote: >> - Since new nodes are not added to the set of locked nodes, if I lock >> a subtree, can I run into race conditions? Suppose I am running a >> transaction that involves adding some nodes and doing some more work >> on them. Since there is no atomic way to add the nodes to the >> datastore and to add them to the lock set, I am concerned that race >> conditions might exist that can be exploited. >> >> Perhaps my problem is that I do not understand 2.4.1.2. What is the >> "the new section created"? Perhaps an example should be added to >> help me to understand how things work. If I have >> >> >> >> 1 >> 2 >> >> >> >> and I do a partial lock on /top, what is the node set returned? Is >> /top/a locked now and what does it mean for a non-leaf node to be >> locked? I think this needs to be clearly spelled out. > I'd like try to answer this question, although I am not sure I completely > understand what you are asking. If you do a partial lock on /top, the > returned node set, which is termed as *scope of lock*, is node, > but the *protected area* is node and all nodes underneath it. > > I'd like explain sec 2.4.1.2 using your example. If I want to create > a directly under , I can't lock /top/c, as is > non-existent. What I should do is lock first, then create , > then, lock /top/c and unlock /top, after that I can operate on /top/c. > > I hope that helps. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 05:16:37 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D6F13A6858; Fri, 23 Jan 2009 05:16:37 -0800 (PST) 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 54CD43A6858 for ; Fri, 23 Jan 2009 05:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ih+X+8ka4JdP for ; Fri, 23 Jan 2009 05:16:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 498EC3A6837 for ; Fri, 23 Jan 2009 05:16:35 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4203920024; Fri, 23 Jan 2009 14:16:17 +0100 (CET) X-AuditID: c1b4fb3c-ac75bbb00000304c-e0-4979c31c7d95 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 48DCF206AC; Fri, 23 Jan 2009 14:16:12 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:16:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 14:16:10 +0100 Message-ID: <4979C319.1040305@ericsson.com> Date: Fri, 23 Jan 2009 14:16:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> In-Reply-To: X-OriginalArrivalTime: 23 Jan 2009 13:16:10.0144 (UTC) FILETIME=[C1F74200:01C97D5C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Washam, Yes you understood it correctly. Thanks. Balazs WashamFan wrote: >> - Since new nodes are not added to the set of locked nodes, if I lock >> a subtree, can I run into race conditions? Suppose I am running a >> transaction that involves adding some nodes and doing some more work >> on them. Since there is no atomic way to add the nodes to the >> datastore and to add them to the lock set, I am concerned that race >> conditions might exist that can be exploited. >> >> Perhaps my problem is that I do not understand 2.4.1.2. What is the >> "the new section created"? Perhaps an example should be added to >> help me to understand how things work. If I have >> >> >> >> 1 >> 2 >> >> >> >> and I do a partial lock on /top, what is the node set returned? Is >> /top/a locked now and what does it mean for a non-leaf node to be >> locked? I think this needs to be clearly spelled out. > I'd like try to answer this question, although I am not sure I completely > understand what you are asking. If you do a partial lock on /top, the > returned node set, which is termed as *scope of lock*, is node, > but the *protected area* is node and all nodes underneath it. > > I'd like explain sec 2.4.1.2 using your example. If I want to create > a directly under , I can't lock /top/c, as is > non-existent. What I should do is lock first, then create , > then, lock /top/c and unlock /top, after that I can operate on /top/c. > > I hope that helps. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 05:47:46 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A9B3A68D7; Fri, 23 Jan 2009 05:47:46 -0800 (PST) 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 B82D13A68D7 for ; Fri, 23 Jan 2009 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 lNITUFcaT8p4 for ; Fri, 23 Jan 2009 05:47:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0AC583A6858 for ; Fri, 23 Jan 2009 05:47:39 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14074C002C; Fri, 23 Jan 2009 14:47:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dNpXARmdJrcX; Fri, 23 Jan 2009 14:47:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B38B7C002B; Fri, 23 Jan 2009 14:47:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6757E9183D2; Fri, 23 Jan 2009 14:47:11 +0100 (CET) Date: Fri, 23 Jan 2009 14:47:11 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090123134711.GA8494@elstar.local> Mail-Followup-To: Balazs Lengyel , WashamFan , netconf mailing list References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <4979C319.1040305@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4979C319.1040305@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 23, 2009 at 02:16:09PM +0100, Balazs Lengyel wrote: > Hello Washam, > Yes you understood it correctly. Thanks. > Balazs But I fail to read this from the document. I think the document needs to better spell out what it means to lock a container vs. locking a leaf. From the example given here, I deduce that locking a container means you can't create child nodes. Thats all fine but I like to have written this down in the specification. /js > WashamFan wrote: >>> - Since new nodes are not added to the set of locked nodes, if I lock >>> a subtree, can I run into race conditions? Suppose I am running a >>> transaction that involves adding some nodes and doing some more work >>> on them. Since there is no atomic way to add the nodes to the >>> datastore and to add them to the lock set, I am concerned that race >>> conditions might exist that can be exploited. >>> Perhaps my problem is that I do not understand 2.4.1.2. What is >>> the >>> "the new section created"? Perhaps an example should be added to >>> help me to understand how things work. If I have >>> >>> >>> 1 >>> 2 >>> >>> and I do a partial lock on /top, what is the node set returned? >>> Is >>> /top/a locked now and what does it mean for a non-leaf node to be >>> locked? I think this needs to be clearly spelled out. >> I'd like try to answer this question, although I am not sure I >> completely understand what you are asking. If you do a partial lock on >> /top, the returned node set, which is termed as *scope of lock*, is >> node, > > but the *protected area* is node and all nodes underneath it. >> >> I'd like explain sec 2.4.1.2 using your example. If I want to create > > a directly under , I can't lock /top/c, as is > > non-existent. What I should do is lock first, then create , > > then, lock /top/c and unlock /top, after that I can operate on /top/c. >> >> I hope that helps. >> -- 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 netconf-bounces@ietf.org Fri Jan 23 05:47:46 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1A9B3A68D7; Fri, 23 Jan 2009 05:47:46 -0800 (PST) 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 B82D13A68D7 for ; Fri, 23 Jan 2009 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 lNITUFcaT8p4 for ; Fri, 23 Jan 2009 05:47:39 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0AC583A6858 for ; Fri, 23 Jan 2009 05:47:39 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14074C002C; Fri, 23 Jan 2009 14:47:22 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dNpXARmdJrcX; Fri, 23 Jan 2009 14:47:16 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B38B7C002B; Fri, 23 Jan 2009 14:47:15 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6757E9183D2; Fri, 23 Jan 2009 14:47:11 +0100 (CET) Date: Fri, 23 Jan 2009 14:47:11 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090123134711.GA8494@elstar.local> Mail-Followup-To: Balazs Lengyel , WashamFan , netconf mailing list References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <4979C319.1040305@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4979C319.1040305@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 23, 2009 at 02:16:09PM +0100, Balazs Lengyel wrote: > Hello Washam, > Yes you understood it correctly. Thanks. > Balazs But I fail to read this from the document. I think the document needs to better spell out what it means to lock a container vs. locking a leaf. From the example given here, I deduce that locking a container means you can't create child nodes. Thats all fine but I like to have written this down in the specification. /js > WashamFan wrote: >>> - Since new nodes are not added to the set of locked nodes, if I lock >>> a subtree, can I run into race conditions? Suppose I am running a >>> transaction that involves adding some nodes and doing some more work >>> on them. Since there is no atomic way to add the nodes to the >>> datastore and to add them to the lock set, I am concerned that race >>> conditions might exist that can be exploited. >>> Perhaps my problem is that I do not understand 2.4.1.2. What is >>> the >>> "the new section created"? Perhaps an example should be added to >>> help me to understand how things work. If I have >>> >>> >>> 1 >>> 2 >>> >>> and I do a partial lock on /top, what is the node set returned? >>> Is >>> /top/a locked now and what does it mean for a non-leaf node to be >>> locked? I think this needs to be clearly spelled out. >> I'd like try to answer this question, although I am not sure I >> completely understand what you are asking. If you do a partial lock on >> /top, the returned node set, which is termed as *scope of lock*, is >> node, > > but the *protected area* is node and all nodes underneath it. >> >> I'd like explain sec 2.4.1.2 using your example. If I want to create > > a directly under , I can't lock /top/c, as is > > non-existent. What I should do is lock first, then create , > > then, lock /top/c and unlock /top, after that I can operate on /top/c. >> >> I hope that helps. >> -- 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 netconf-bounces@ietf.org Fri Jan 23 06:46:45 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239553A69FA; Fri, 23 Jan 2009 06:46:45 -0800 (PST) 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 49DF73A69FA for ; Fri, 23 Jan 2009 06:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 3iWkZu3zHRuq for ; Fri, 23 Jan 2009 06:46:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1CA9F3A687E for ; Fri, 23 Jan 2009 06:46:40 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F1A2221B1; Fri, 23 Jan 2009 15:45:31 +0100 (CET) X-AuditID: c1b4fb3c-aff62bb00000304c-6d-4979d80b7f7c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4841B221AD; Fri, 23 Jan 2009 15:45:31 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 15:45:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 15:45:30 +0100 Message-ID: <4979D80A.7040106@ericsson.com> Date: Fri, 23 Jan 2009 15:45:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> In-Reply-To: X-OriginalArrivalTime: 23 Jan 2009 14:45:30.0891 (UTC) FILETIME=[3D3855B0:01C97D69] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I agree with Washam. It would not be nice to treat the failure due to partial locking as a special case. I think the text in 4741 is clear enough. If there is any need for clarification, I would rather say that the 4741bis effort should write some generic text about all error cases. However we could add to chapter 2.5 something like: If partial lock prevents edit-config from modifying some data, but the operation includes the continue-on-error option, modification of other parts of the datastore, which not protected by partial locking, might still succeed. Opinion? Is there anything else missing from chapter 2.5? Balazs WashamFan wrote: > Hi, >> Juergen Schoenwaelder wrote: >> > For example, how do locking errors relate to the error-option of >> > edit-config? > Why should we treat errors caused by lock differently. "continue-on-error" take effect on all errors including those caused by lock. > >> Consider an edit-config modifying a node-set of which >> a >> > subset is locked. Does the edit-config fail in all cases? Or does lets >> > say continue-on-error still cause those nodes not locked to be >> > changed? I think it is good to have these details documented. >> >> Good point! This hasn't been discussed at all in the WG. One problem >> here is that the meaning of "continue-on-error" is unclear; this has >> been discussed several times. Specifically, is the "error" part of >> "continue-on-error" supposed to cover this kind of transient errors? > Yes, the error caused by lock is not the real error, but operator could recognize it in response. The error lead to partial failure at least. IMO, it is covered by "error" part of "continue-on-error". > > washam >> >> /martin >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 06:46:45 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239553A69FA; Fri, 23 Jan 2009 06:46:45 -0800 (PST) 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 49DF73A69FA for ; Fri, 23 Jan 2009 06:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 3iWkZu3zHRuq for ; Fri, 23 Jan 2009 06:46:42 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1CA9F3A687E for ; Fri, 23 Jan 2009 06:46:40 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6F1A2221B1; Fri, 23 Jan 2009 15:45:31 +0100 (CET) X-AuditID: c1b4fb3c-aff62bb00000304c-6d-4979d80b7f7c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4841B221AD; Fri, 23 Jan 2009 15:45:31 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 15:45:31 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 15:45:30 +0100 Message-ID: <4979D80A.7040106@ericsson.com> Date: Fri, 23 Jan 2009 15:45:30 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: WashamFan References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> In-Reply-To: X-OriginalArrivalTime: 23 Jan 2009 14:45:30.0891 (UTC) FILETIME=[3D3855B0:01C97D69] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, I agree with Washam. It would not be nice to treat the failure due to partial locking as a special case. I think the text in 4741 is clear enough. If there is any need for clarification, I would rather say that the 4741bis effort should write some generic text about all error cases. However we could add to chapter 2.5 something like: If partial lock prevents edit-config from modifying some data, but the operation includes the continue-on-error option, modification of other parts of the datastore, which not protected by partial locking, might still succeed. Opinion? Is there anything else missing from chapter 2.5? Balazs WashamFan wrote: > Hi, >> Juergen Schoenwaelder wrote: >> > For example, how do locking errors relate to the error-option of >> > edit-config? > Why should we treat errors caused by lock differently. "continue-on-error" take effect on all errors including those caused by lock. > >> Consider an edit-config modifying a node-set of which >> a >> > subset is locked. Does the edit-config fail in all cases? Or does lets >> > say continue-on-error still cause those nodes not locked to be >> > changed? I think it is good to have these details documented. >> >> Good point! This hasn't been discussed at all in the WG. One problem >> here is that the meaning of "continue-on-error" is unclear; this has >> been discussed several times. Specifically, is the "error" part of >> "continue-on-error" supposed to cover this kind of transient errors? > Yes, the error caused by lock is not the real error, but operator could recognize it in response. The error lead to partial failure at least. IMO, it is covered by "error" part of "continue-on-error". > > washam >> >> /martin >> >> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 06:55:44 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2143A6ABD; Fri, 23 Jan 2009 06:55:44 -0800 (PST) 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 0FB2228C1A3 for ; Fri, 23 Jan 2009 06:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 fdM7nIAwvi3A for ; Fri, 23 Jan 2009 06:55:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 111E33A69FA for ; Fri, 23 Jan 2009 06:55:42 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16CB4C010E; Fri, 23 Jan 2009 15:55:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3wBuqAjKRMhE; Fri, 23 Jan 2009 15:55:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F556C002B; Fri, 23 Jan 2009 15:55:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E73C691877E; Fri, 23 Jan 2009 15:55:14 +0100 (CET) Date: Fri, 23 Jan 2009 15:55:14 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090123145514.GD8628@elstar.local> Mail-Followup-To: Balazs Lengyel , WashamFan , netconf@ietf.org References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <4979D80A.7040106@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4979D80A.7040106@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 23, 2009 at 03:45:30PM +0100, Balazs Lengyel wrote: > However we could add to chapter 2.5 something like: > If partial lock prevents edit-config from modifying some data, but the > operation includes the continue-on-error option, modification of other > parts of the datastore, which not protected by partial locking, might > still succeed. I think being explicit is important. So I am in favour of adding such a clarification. /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 netconf-bounces@ietf.org Fri Jan 23 06:55:44 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2143A6ABD; Fri, 23 Jan 2009 06:55:44 -0800 (PST) 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 0FB2228C1A3 for ; Fri, 23 Jan 2009 06:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 fdM7nIAwvi3A for ; Fri, 23 Jan 2009 06:55:42 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 111E33A69FA for ; Fri, 23 Jan 2009 06:55:42 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 16CB4C010E; Fri, 23 Jan 2009 15:55:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3wBuqAjKRMhE; Fri, 23 Jan 2009 15:55:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F556C002B; Fri, 23 Jan 2009 15:55:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E73C691877E; Fri, 23 Jan 2009 15:55:14 +0100 (CET) Date: Fri, 23 Jan 2009 15:55:14 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090123145514.GD8628@elstar.local> Mail-Followup-To: Balazs Lengyel , WashamFan , netconf@ietf.org References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <4979D80A.7040106@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4979D80A.7040106@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 23, 2009 at 03:45:30PM +0100, Balazs Lengyel wrote: > However we could add to chapter 2.5 something like: > If partial lock prevents edit-config from modifying some data, but the > operation includes the continue-on-error option, modification of other > parts of the datastore, which not protected by partial locking, might > still succeed. I think being explicit is important. So I am in favour of adding such a clarification. /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 netconf-bounces@ietf.org Fri Jan 23 08:25:44 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8E03A6ACD; Fri, 23 Jan 2009 08:25:44 -0800 (PST) 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 20A5C3A6AD1 for ; Fri, 23 Jan 2009 08:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 A1u8FJJXstUR for ; Fri, 23 Jan 2009 08:25:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 399BD3A6ACD for ; Fri, 23 Jan 2009 08:25:41 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A18F122183; Fri, 23 Jan 2009 17:25:06 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-31-4979ef62370b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86EDA22182; Fri, 23 Jan 2009 17:25:06 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 17:25:06 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 17:25:06 +0100 Message-ID: <4979EF61.20207@ericsson.com> Date: Fri, 23 Jan 2009 17:25:05 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , WashamFan , netconf@ietf.org References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <4979D80A.7040106@ericsson.com> <20090123145514.GD8628@elstar.local> In-Reply-To: <20090123145514.GD8628@elstar.local> X-OriginalArrivalTime: 23 Jan 2009 16:25:06.0163 (UTC) FILETIME=[26C27C30:01C97D77] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org OK, I will do it. Balazs Juergen Schoenwaelder wrote: > On Fri, Jan 23, 2009 at 03:45:30PM +0100, Balazs Lengyel wrote: > >> However we could add to chapter 2.5 something like: >> If partial lock prevents edit-config from modifying some data, but the >> operation includes the continue-on-error option, modification of other >> parts of the datastore, which not protected by partial locking, might >> still succeed. > > I think being explicit is important. So I am in favour of adding such > a clarification. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 08:25:44 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D8E03A6ACD; Fri, 23 Jan 2009 08:25:44 -0800 (PST) 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 20A5C3A6AD1 for ; Fri, 23 Jan 2009 08:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 A1u8FJJXstUR for ; Fri, 23 Jan 2009 08:25:42 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 399BD3A6ACD for ; Fri, 23 Jan 2009 08:25:41 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A18F122183; Fri, 23 Jan 2009 17:25:06 +0100 (CET) X-AuditID: c1b4fb3e-ad06cbb00000429e-31-4979ef62370b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86EDA22182; Fri, 23 Jan 2009 17:25:06 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 17:25:06 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Jan 2009 17:25:06 +0100 Message-ID: <4979EF61.20207@ericsson.com> Date: Fri, 23 Jan 2009 17:25:05 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , WashamFan , netconf@ietf.org References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <4979D80A.7040106@ericsson.com> <20090123145514.GD8628@elstar.local> In-Reply-To: <20090123145514.GD8628@elstar.local> X-OriginalArrivalTime: 23 Jan 2009 16:25:06.0163 (UTC) FILETIME=[26C27C30:01C97D77] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org OK, I will do it. Balazs Juergen Schoenwaelder wrote: > On Fri, Jan 23, 2009 at 03:45:30PM +0100, Balazs Lengyel wrote: > >> However we could add to chapter 2.5 something like: >> If partial lock prevents edit-config from modifying some data, but the >> operation includes the continue-on-error option, modification of other >> parts of the datastore, which not protected by partial locking, might >> still succeed. > > I think being explicit is important. So I am in favour of adding such > a clarification. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 12:18:40 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5703A69E3; Fri, 23 Jan 2009 12:18:40 -0800 (PST) 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 5EB4F3A69E3 for ; Fri, 23 Jan 2009 12:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[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 n9-9uKurDzFU for ; Fri, 23 Jan 2009 12:18:34 -0800 (PST) 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 349373A685F for ; Fri, 23 Jan 2009 12:18:34 -0800 (PST) Received: (qmail 19794 invoked from network); 23 Jan 2009 20:18:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2009 20:18:14 -0000 X-YMail-OSG: eGnzmxcVM1mhu6rqafjyQyvWVR4O9GcqLZWI5hEZucO5jB0LYW.nh5.BwlwczB8B8H0Tizy2.0FYR7nYDDTAdOfki37TyOM6DnlD6.S7U0ec_TmJ5t1sIF4sgw3h0Rre6NnoCKuPDjegt.MXOshiBUsc X-Yahoo-Newman-Property: ymail-3 Message-ID: <497A2605.6040504@netconfcentral.com> Date: Fri, 23 Jan 2009 12:18:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] Full XPath and partial locking 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, If the full XPath is supported, then arbitrary XPath expressions are allowed. However, there are known interoperability issues wrt/ some XPath constructs as applied to NETCONF databases. These are not addressed in the draft. The preceding, preceding-sibling, following, and following-sibling axis are implementation-dependent. All positional expressions are implementation-dependent. Given 2 identical XML representations of a NETCONF database (e.g., via ), no 2 NETCONF implementations are required to produce the same results for positional XPath expressions (e.g., '//name[42]'). NETCONF is not the same sort of application as XSLT, and it uses XPath differently. For example, for XPath filtering selecting a node also selects all the ancestors of that node, but for partial locking it does not. Therefore the ancestor, ancestor-or-self, and parent axis may work differently for different NETCONF operations. It is not clear how the operator finds out exactly what is locked. Given that positional expressions are legal, it seems important. E.g., locking '//name[42]' is evaluated one time, so even if 3 'name' elements are deleted, and the 42nd instance is now the 39th instance, the lock does not change. But the node-set associated with '//name[42]' keeps changing. It seems that implementation of the netconf monitoring data model is going to be required in order to find out what is really locked. I do not see any discussion of this issue in the draft. What happens if config=false nodes are identified by the XPath select expression? Is this documented? Is it an error or NO-OP? Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 12:18:40 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5703A69E3; Fri, 23 Jan 2009 12:18:40 -0800 (PST) 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 5EB4F3A69E3 for ; Fri, 23 Jan 2009 12:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[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 n9-9uKurDzFU for ; Fri, 23 Jan 2009 12:18:34 -0800 (PST) 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 349373A685F for ; Fri, 23 Jan 2009 12:18:34 -0800 (PST) Received: (qmail 19794 invoked from network); 23 Jan 2009 20:18:16 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 23 Jan 2009 20:18:14 -0000 X-YMail-OSG: eGnzmxcVM1mhu6rqafjyQyvWVR4O9GcqLZWI5hEZucO5jB0LYW.nh5.BwlwczB8B8H0Tizy2.0FYR7nYDDTAdOfki37TyOM6DnlD6.S7U0ec_TmJ5t1sIF4sgw3h0Rre6NnoCKuPDjegt.MXOshiBUsc X-Yahoo-Newman-Property: ymail-3 Message-ID: <497A2605.6040504@netconfcentral.com> Date: Fri, 23 Jan 2009 12:18:13 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] Full XPath and partial locking 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, If the full XPath is supported, then arbitrary XPath expressions are allowed. However, there are known interoperability issues wrt/ some XPath constructs as applied to NETCONF databases. These are not addressed in the draft. The preceding, preceding-sibling, following, and following-sibling axis are implementation-dependent. All positional expressions are implementation-dependent. Given 2 identical XML representations of a NETCONF database (e.g., via ), no 2 NETCONF implementations are required to produce the same results for positional XPath expressions (e.g., '//name[42]'). NETCONF is not the same sort of application as XSLT, and it uses XPath differently. For example, for XPath filtering selecting a node also selects all the ancestors of that node, but for partial locking it does not. Therefore the ancestor, ancestor-or-self, and parent axis may work differently for different NETCONF operations. It is not clear how the operator finds out exactly what is locked. Given that positional expressions are legal, it seems important. E.g., locking '//name[42]' is evaluated one time, so even if 3 'name' elements are deleted, and the 42nd instance is now the 39th instance, the lock does not change. But the node-set associated with '//name[42]' keeps changing. It seems that implementation of the netconf monitoring data model is going to be required in order to find out what is really locked. I do not see any discussion of this issue in the draft. What happens if config=false nodes are identified by the XPath select expression? Is this documented? Is it an error or NO-OP? Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 17:32:11 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894CA3A68B4; Fri, 23 Jan 2009 17:32:11 -0800 (PST) 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 43D053A68B4 for ; Fri, 23 Jan 2009 17:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 pDN2NqVqt+Pb for ; Fri, 23 Jan 2009 17:32:09 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 22E5E3A67F3 for ; Fri, 23 Jan 2009 17:32:08 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00B0UC8YRO80@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 09:31:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY0041BC8WVQ20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 09:31:46 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 09:31:44 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 24 Jan 2009 09:31:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090123134711.GA8494@elstar.local> References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <4979C319.1040305@ericsson.com> <20090123134711.GA8494@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Fri, Jan 23, 2009 at 02:16:09PM +0100, Balazs Lengyel wrote: > > Hello Washam, > > Yes you understood it correctly. Thanks. > > Balazs > > But I fail to read this from the document. I think the document needs > to better spell out what it means to lock a container vs. locking a > leaf. From the example given here, I deduce that locking a container > means you can't create child nodes. Thats all fine but I like to have > written this down in the specification. Locking a container *implies* other sessions can't *change* anything included in the container, e.g, you can't create child nodes in the container locked by other session. IMO, sec 2.4.1.2 explictly addressed this concern. washam > /js > > > WashamFan wrote: > >>> - Since new nodes are not added to the set of locked nodes, if I > lock > >>> a subtree, can I run into race conditions? Suppose I am > running a > >>> transaction that involves adding some nodes and doing some > more work > >>> on them. Since there is no atomic way to add the nodes to the > >>> datastore and to add them to the lock set, I am concerned that > race > >>> conditions might exist that can be exploited. > >>> Perhaps my problem is that I do not understand 2.4.1.2. > What is > >>> the > >>> "the new section created"? Perhaps an example should be added > to > >>> help me to understand how things work. If I have > >>> > >>> > >>> 1 > >>> 2 > >>> > >>> and I do a partial lock on /top, what is the node set > returned? > >>> Is > >>> /top/a locked now and what does it mean for a non-leaf node to > be > >>> locked? I think this needs to be clearly spelled out. > >> I'd like try to answer this question, although I am not sure I > >> completely understand what you are asking. If you do a partial > lock on > >> /top, the returned node set, which is termed as *scope of lock*, > is > >> node, > > > but the *protected area* is node and all nodes underneath it. > >> > >> I'd like explain sec 2.4.1.2 using your example. If I want to > create > > > a directly under , I can't lock /top/c, as is > > > non-existent. What I should do is lock first, then create , > > > then, lock /top/c and unlock /top, after that I can operate on /top/c. > >> > >> I hope that helps. > >> > > -- > 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 netconf-bounces@ietf.org Fri Jan 23 17:32:11 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 894CA3A68B4; Fri, 23 Jan 2009 17:32:11 -0800 (PST) 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 43D053A68B4 for ; Fri, 23 Jan 2009 17:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 pDN2NqVqt+Pb for ; Fri, 23 Jan 2009 17:32:09 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 22E5E3A67F3 for ; Fri, 23 Jan 2009 17:32:08 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00B0UC8YRO80@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 09:31:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY0041BC8WVQ20@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 09:31:46 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 09:31:44 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 24 Jan 2009 09:31:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090123134711.GA8494@elstar.local> References: <493EA615.8050807@ericsson.com> <266652AC6E494EB3A2E1FAFC76D47A3A@BertLaptop> <20090121091505.GA28159@elstar.local> <4979C319.1040305@ericsson.com> <20090123134711.GA8494@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] WGLC: draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Fri, Jan 23, 2009 at 02:16:09PM +0100, Balazs Lengyel wrote: > > Hello Washam, > > Yes you understood it correctly. Thanks. > > Balazs > > But I fail to read this from the document. I think the document needs > to better spell out what it means to lock a container vs. locking a > leaf. From the example given here, I deduce that locking a container > means you can't create child nodes. Thats all fine but I like to have > written this down in the specification. Locking a container *implies* other sessions can't *change* anything included in the container, e.g, you can't create child nodes in the container locked by other session. IMO, sec 2.4.1.2 explictly addressed this concern. washam > /js > > > WashamFan wrote: > >>> - Since new nodes are not added to the set of locked nodes, if I > lock > >>> a subtree, can I run into race conditions? Suppose I am > running a > >>> transaction that involves adding some nodes and doing some > more work > >>> on them. Since there is no atomic way to add the nodes to the > >>> datastore and to add them to the lock set, I am concerned that > race > >>> conditions might exist that can be exploited. > >>> Perhaps my problem is that I do not understand 2.4.1.2. > What is > >>> the > >>> "the new section created"? Perhaps an example should be added > to > >>> help me to understand how things work. If I have > >>> > >>> > >>> 1 > >>> 2 > >>> > >>> and I do a partial lock on /top, what is the node set > returned? > >>> Is > >>> /top/a locked now and what does it mean for a non-leaf node to > be > >>> locked? I think this needs to be clearly spelled out. > >> I'd like try to answer this question, although I am not sure I > >> completely understand what you are asking. If you do a partial > lock on > >> /top, the returned node set, which is termed as *scope of lock*, > is > >> node, > > > but the *protected area* is node and all nodes underneath it. > >> > >> I'd like explain sec 2.4.1.2 using your example. If I want to > create > > > a directly under , I can't lock /top/c, as is > > > non-existent. What I should do is lock first, then create , > > > then, lock /top/c and unlock /top, after that I can operate on /top/c. > >> > >> I hope that helps. > >> > > -- > 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 netconf-bounces@ietf.org Fri Jan 23 19:41:54 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426BA3A69FE; Fri, 23 Jan 2009 19:41:54 -0800 (PST) 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 C31153A69FE for ; Fri, 23 Jan 2009 19:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 TRgqg9+0gXsc for ; Fri, 23 Jan 2009 19:41:53 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id D05123A6993 for ; Fri, 23 Jan 2009 19:41:52 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00L69I96H300@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:41:32 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00M44I94GU00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:41:30 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 11:41:28 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 24 Jan 2009 11:41:28 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090123130028.GA8291@elstar.local> References: <20090123130028.GA8291@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > l) Can capabilities announced during be dropped without > closing the session? If not, then the text should be changed. According to para 2 in Abstract, and last sentence in sec 2.1.1, yes, announced capabilities can be dropped. > OLD: > > The list MUST include all capabilities exchanged during session > setup still applicable at the time of the request. > > NEW: > > The list MUST include all capabilities exchanged during session setup. > o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and > such things and this requires to first read the data model in order > to understand this text. This might require to introduce a > subsection describing the /netconf/datastore/locks subtree. Last sentence in sec 2.1.2 says: "The selection is the xpath expression which was used to evaluate the list of nodes to lock." Is subtree expression ignored? > K) Why is the schema in the example returned in CDATA?? I think, returned data is a complete XSD document, so it should be in CDATA in order to avoid parsing error. washam > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 19:41:54 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426BA3A69FE; Fri, 23 Jan 2009 19:41:54 -0800 (PST) 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 C31153A69FE for ; Fri, 23 Jan 2009 19:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 TRgqg9+0gXsc for ; Fri, 23 Jan 2009 19:41:53 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id D05123A6993 for ; Fri, 23 Jan 2009 19:41:52 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00L69I96H300@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:41:32 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00M44I94GU00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:41:30 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 11:41:28 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 24 Jan 2009 11:41:28 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090123130028.GA8291@elstar.local> References: <20090123130028.GA8291@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > l) Can capabilities announced during be dropped without > closing the session? If not, then the text should be changed. According to para 2 in Abstract, and last sentence in sec 2.1.1, yes, announced capabilities can be dropped. > OLD: > > The list MUST include all capabilities exchanged during session > setup still applicable at the time of the request. > > NEW: > > The list MUST include all capabilities exchanged during session setup. > o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and > such things and this requires to first read the data model in order > to understand this text. This might require to introduce a > subsection describing the /netconf/datastore/locks subtree. Last sentence in sec 2.1.2 says: "The selection is the xpath expression which was used to evaluate the list of nodes to lock." Is subtree expression ignored? > K) Why is the schema in the example returned in CDATA?? I think, returned data is a complete XSD document, so it should be in CDATA in order to avoid parsing error. washam > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 19:54:53 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872493A6A7F; Fri, 23 Jan 2009 19:54:53 -0800 (PST) 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 1145B3A6A7F for ; Fri, 23 Jan 2009 19:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, 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 ATBdxiNI4YM7 for ; Fri, 23 Jan 2009 19:54:51 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 37C533A6993 for ; Fri, 23 Jan 2009 19:54:51 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY0025SIUUOQ10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:54:32 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00K4SIUTUA00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:54:30 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 11:54:29 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 24 Jan 2009 11:54:29 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <497A2605.6040504@netconfcentral.com> References: <497A2605.6040504@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I remember I saw the similar topics diccussed in NETMOD thread. A rough consensus seems to be achieved there that positional expression should not be used or may be use with keeping in mind that there would be a risk. washam > Hi, > > If the full XPath is supported, then arbitrary XPath > expressions are allowed. However, there are known > interoperability issues wrt/ some XPath constructs > as applied to NETCONF databases. These are not > addressed in the draft. > > The preceding, preceding-sibling, following, > and following-sibling axis are implementation-dependent. > All positional expressions are implementation-dependent. > Given 2 identical XML representations of a NETCONF > database (e.g., via ), no 2 NETCONF implementations > are required to produce the same results for positional > XPath expressions (e.g., '//name[42]'). > > NETCONF is not the same sort of application > as XSLT, and it uses XPath differently. > For example, for XPath filtering selecting a node > also selects all the ancestors of that node, > but for partial locking it does not. Therefore > the ancestor, ancestor-or-self, and parent axis > may work differently for different NETCONF operations. > > It is not clear how the operator finds out exactly what > is locked. Given that positional expressions are legal, > it seems important. E.g., locking '//name[42]' is evaluated > one time, so even if 3 'name' elements are deleted, and > the 42nd instance is now the 39th instance, the lock > does not change. But the node-set associated with '//name[42]' > keeps changing. > > It seems that implementation of the netconf monitoring data > model is going to be required in order to find out what > is really locked. I do not see any discussion of this issue > in the draft. > > What happens if config=false nodes are identified by the > XPath select expression? Is this documented? Is it an > error or NO-OP? > > > > Andy > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 19:54:53 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872493A6A7F; Fri, 23 Jan 2009 19:54:53 -0800 (PST) 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 1145B3A6A7F for ; Fri, 23 Jan 2009 19:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, 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 ATBdxiNI4YM7 for ; Fri, 23 Jan 2009 19:54:51 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 37C533A6993 for ; Fri, 23 Jan 2009 19:54:51 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY0025SIUUOQ10@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:54:32 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00K4SIUTUA00@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 11:54:30 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 11:54:29 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 24 Jan 2009 11:54:29 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <497A2605.6040504@netconfcentral.com> References: <497A2605.6040504@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I remember I saw the similar topics diccussed in NETMOD thread. A rough consensus seems to be achieved there that positional expression should not be used or may be use with keeping in mind that there would be a risk. washam > Hi, > > If the full XPath is supported, then arbitrary XPath > expressions are allowed. However, there are known > interoperability issues wrt/ some XPath constructs > as applied to NETCONF databases. These are not > addressed in the draft. > > The preceding, preceding-sibling, following, > and following-sibling axis are implementation-dependent. > All positional expressions are implementation-dependent. > Given 2 identical XML representations of a NETCONF > database (e.g., via ), no 2 NETCONF implementations > are required to produce the same results for positional > XPath expressions (e.g., '//name[42]'). > > NETCONF is not the same sort of application > as XSLT, and it uses XPath differently. > For example, for XPath filtering selecting a node > also selects all the ancestors of that node, > but for partial locking it does not. Therefore > the ancestor, ancestor-or-self, and parent axis > may work differently for different NETCONF operations. > > It is not clear how the operator finds out exactly what > is locked. Given that positional expressions are legal, > it seems important. E.g., locking '//name[42]' is evaluated > one time, so even if 3 'name' elements are deleted, and > the 42nd instance is now the 39th instance, the lock > does not change. But the node-set associated with '//name[42]' > keeps changing. > > It seems that implementation of the netconf monitoring data > model is going to be required in order to find out what > is really locked. I do not see any discussion of this issue > in the draft. > > What happens if config=false nodes are identified by the > XPath select expression? Is this documented? Is it an > error or NO-OP? > > > > Andy > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 23 22:20:28 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18F828C1C7; Fri, 23 Jan 2009 22:20:28 -0800 (PST) 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 4E94A28C1C7 for ; Fri, 23 Jan 2009 22:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 WVbzNfk3R978 for ; Fri, 23 Jan 2009 22:20:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 65B6628C0D6 for ; Fri, 23 Jan 2009 22:20:25 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5354C011D; Sat, 24 Jan 2009 07:20:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6O-EtPK12fZ3; Sat, 24 Jan 2009 07:20:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF00C011B; Sat, 24 Jan 2009 07:20:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8A2209197BC; Sat, 24 Jan 2009 07:19:57 +0100 (CET) Date: Sat, 24 Jan 2009 07:19:57 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090124061957.GB10301@elstar.local> Mail-Followup-To: WashamFan , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sat, Jan 24, 2009 at 11:41:28AM +0800, WashamFan wrote: > Hi, > > > l) Can capabilities announced during be dropped without > > closing the session? If not, then the text should be changed. > According to para 2 in Abstract, and last sentence in sec 2.1.1, yes, announced capabilities can be dropped. I question that this document can define the semantics of the message in this way. I believe RFC4741 is not clear enough about the lifetime of capabilities announce in the message and it needs more discussion on finally documentation in RFC4741bis what the lifetime of capabilities announce in the messages is. > > OLD: > > > > The list MUST include all capabilities exchanged during session > > setup still applicable at the time of the request. > > > > NEW: > > > > The list MUST include all capabilities exchanged during session setup. > > > o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and > > such things and this requires to first read the data model in order > > to understand this text. This might require to introduce a > > subsection describing the /netconf/datastore/locks subtree. > Last sentence in sec 2.1.2 says: > > "The selection is the xpath expression which was used to evaluate > the list of nodes to lock." Is subtree expression ignored? I don't understand your question. The select elements carry xpath expressions, or if :xpath is not supported, instance identifier expressions. I am not sure that was your question. > > K) Why is the schema in the example returned in CDATA?? > > I think, returned data is a complete XSD document, so it should be > in CDATA in order to avoid parsing error. I can't judge this but if such wrapping is needed for some data modeling languages, then this needs to be spelled out. Right now, this wrapping only appears in an example. /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 netconf-bounces@ietf.org Fri Jan 23 22:20:28 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18F828C1C7; Fri, 23 Jan 2009 22:20:28 -0800 (PST) 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 4E94A28C1C7 for ; Fri, 23 Jan 2009 22:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 WVbzNfk3R978 for ; Fri, 23 Jan 2009 22:20:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 65B6628C0D6 for ; Fri, 23 Jan 2009 22:20:25 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5354C011D; Sat, 24 Jan 2009 07:20:07 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6O-EtPK12fZ3; Sat, 24 Jan 2009 07:20:02 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF00C011B; Sat, 24 Jan 2009 07:20:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8A2209197BC; Sat, 24 Jan 2009 07:19:57 +0100 (CET) Date: Sat, 24 Jan 2009 07:19:57 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090124061957.GB10301@elstar.local> Mail-Followup-To: WashamFan , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sat, Jan 24, 2009 at 11:41:28AM +0800, WashamFan wrote: > Hi, > > > l) Can capabilities announced during be dropped without > > closing the session? If not, then the text should be changed. > According to para 2 in Abstract, and last sentence in sec 2.1.1, yes, announced capabilities can be dropped. I question that this document can define the semantics of the message in this way. I believe RFC4741 is not clear enough about the lifetime of capabilities announce in the message and it needs more discussion on finally documentation in RFC4741bis what the lifetime of capabilities announce in the messages is. > > OLD: > > > > The list MUST include all capabilities exchanged during session > > setup still applicable at the time of the request. > > > > NEW: > > > > The list MUST include all capabilities exchanged during session setup. > > > o) Section 2.1.2 needs to be expanded. It talks about lockedNodes and > > such things and this requires to first read the data model in order > > to understand this text. This might require to introduce a > > subsection describing the /netconf/datastore/locks subtree. > Last sentence in sec 2.1.2 says: > > "The selection is the xpath expression which was used to evaluate > the list of nodes to lock." Is subtree expression ignored? I don't understand your question. The select elements carry xpath expressions, or if :xpath is not supported, instance identifier expressions. I am not sure that was your question. > > K) Why is the schema in the example returned in CDATA?? > > I think, returned data is a complete XSD document, so it should be > in CDATA in order to avoid parsing error. I can't judge this but if such wrapping is needed for some data modeling languages, then this needs to be spelled out. Right now, this wrapping only appears in an example. /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 netconf-bounces@ietf.org Sat Jan 24 01:56:12 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8107A3A67B6; Sat, 24 Jan 2009 01:56:12 -0800 (PST) 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 C72C428B23E for ; Sat, 24 Jan 2009 01:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 rr9RWDhmBlFz for ; Sat, 24 Jan 2009 01:56:10 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 3E9F33A67B3 for ; Sat, 24 Jan 2009 01:56:08 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY002F7ZKYOQ30@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 17:55:48 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KDY00B0IZKWSU10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 24 Jan 2009 17:55:46 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sat, 24 Jan 2009 17:55:44 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 24 Jan 2009 17:55:44 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090124061957.GB10301@elstar.local> References: <20090123130028.GA8291@elstar.local> <20090124061957.GB10301@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Sat, Jan 24, 2009 at 11:41:28AM +0800, WashamFan wrote: > > Hi, > > > > > l) Can capabilities announced during be dropped without > > > closing the session? If not, then the text should be changed. > > According to para 2 in Abstract, and last sentence in sec 2.1.1, > yes, announced capabilities can be dropped. > > I question that this document can define the semantics of the > message in this way. I believe RFC4741 is not clear enough about the > lifetime of capabilities announce in the message and it needs > more discussion on finally documentation in RFC4741bis what the > lifetime of capabilities announce in the messages is. > > > > OLD: > > > > > > The list MUST include all capabilities exchanged during session > > > setup still applicable at the time of the request. > > > > > > NEW: > > > > > > The list MUST include all capabilities exchanged during > session setup. > > > > > o) Section 2.1.2 needs to be expanded. It talks about > lockedNodes and > > > such things and this requires to first read the data model in > order > > > to understand this text. This might require to introduce a > > > subsection describing the /netconf/datastore/locks subtree. > > Last sentence in sec 2.1.2 says: > > > > "The selection is the xpath expression which was used to evaluate > > the list of nodes to lock." Is subtree expression ignored? > > I don't understand your question. The select elements > carry xpath expressions, or if :xpath is not supported, instance > identifier expressions. I am not sure that was your question. Sorry for ambiguity. I meant if subtree filtering is used, how to deal with elements, instance identifier expressions? > > > K) Why is the schema in the example returned in CDATA?? > > > > I think, returned data is a complete XSD document, so it should be > > in CDATA in order to avoid parsing error. > > I can't judge this but if such wrapping is needed for some data > modeling languages, then this needs to be spelled out. Right now, this > wrapping only appears in an example. > > /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 netconf-bounces@ietf.org Sat Jan 24 03:23:30 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D403A68A2; Sat, 24 Jan 2009 03:23:30 -0800 (PST) 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 AC3D53A68A2 for ; Sat, 24 Jan 2009 03:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.168 X-Spam-Level: X-Spam-Status: No, score=-2.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 o4JnVrynXLm6 for ; Sat, 24 Jan 2009 03:23:28 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 83A5D3A67A5 for ; Sat, 24 Jan 2009 03:23:28 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D0BBC0058; Sat, 24 Jan 2009 12:23:11 +0100 (CET) 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 D+pnMXJXzCry; Sat, 24 Jan 2009 12:23:05 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 387AAC007C; Sat, 24 Jan 2009 12:23:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BBA5E919909; Sat, 24 Jan 2009 12:23:00 +0100 (CET) Date: Sat, 24 Jan 2009 12:23:00 +0100 From: Juergen Schoenwaelder To: WashamFan Message-ID: <20090124112300.GA10423@elstar.local> Mail-Followup-To: WashamFan , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> <20090124061957.GB10301@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sat, Jan 24, 2009 at 05:55:44PM +0800, WashamFan wrote: > > > > o) Section 2.1.2 needs to be expanded. It talks about > > lockedNodes and > > > > such things and this requires to first read the data model in > > order > > > > to understand this text. This might require to introduce a > > > > subsection describing the /netconf/datastore/locks subtree. > > > Last sentence in sec 2.1.2 says: > > > > > > "The selection is the xpath expression which was used to evaluate > > > the list of nodes to lock." Is subtree expression ignored? > > > > I don't understand your question. The select elements > > carry xpath expressions, or if :xpath is not supported, instance > > identifier expressions. I am not sure that was your question. > > Sorry for ambiguity. I meant if subtree filtering is used, how to > deal with elements, instance identifier expressions? Edit-config does not do subtree filtering. I still don't get the question. And even if it would, I fail to see the issue since the locks a set of nodes and once processing is complete, the select / instance identifier expressions do not really matter anymore from the processing point of view. /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 netconf-bounces@ietf.org Sat Jan 24 08:32:21 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB4428C0F1; Sat, 24 Jan 2009 08:32:20 -0800 (PST) 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 1109428C0E5 for ; Sat, 24 Jan 2009 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=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 DJmkyQrTpNAB for ; Sat, 24 Jan 2009 08:32:19 -0800 (PST) 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 655F328C0F1 for ; Sat, 24 Jan 2009 08:32:19 -0800 (PST) Received: (qmail 40856 invoked from network); 24 Jan 2009 16:32:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 24 Jan 2009 16:32:00 -0000 X-YMail-OSG: eB4y_rcVM1lzVa_nWPDeAsAY3zwfgWT3Xs5PdLxqWmwnqOGP3RPyQtgXrCmVvpIeYysVGrOX_jsN.wcbU9rub7Aoe9gxVyflir0dPywL3vGmkZ9Ygvxu9CJNxP1ys93tS1m0vRDuHpvI4vF9OBulnUBbGXZqLMOxu9FdSvGf8rJ1VkBUr7b9kjBk X-Yahoo-Newman-Property: ymail-3 Message-ID: <497B427F.9000908@netconfcentral.com> Date: Sat, 24 Jan 2009 08:31:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Cc: NETCONF Subject: [Netconf] netconf.yang 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I published an I-D containing the netconf.yang module I wrote. I do not know if this would be a NETCONF work item, a NETMOD work item, or just an Informational individual submission. http://www.ietf.org/internet-drafts/draft-bierman-netmod-netconf-module-00.txt I agree with Phil and others that the solution for the 'with-defaults' feature should entail augmenting the appropriate RPC input sections with a leaf of some sort, rather than passing parameters on the side, via the XML attributes. This is a cleaner approach in both design and access control enforcement. In order to augment the NETCONF RPC methods, ever, for any reason, some choices will have to be made: - Should YANG and DSDL be supported, or just XSD? The NETMOD WG has declared XSD dead, long live DSDL, but the NETCONF WG has only XSD specifications. At some point, some convergence would be in order. - The 4741 XSD cannot be augmented, except in some anticipated nodes, such as adding new rpcOperationTypes. Adding new parameters to existing RPC operations is not currently supported by this XSD. If the 'with-defaults' work item in the new charter gets approved, then I would like a short timeslot at IETF #74 to discuss the netconf.yang draft and these issues. thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 24 08:32:21 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB4428C0F1; Sat, 24 Jan 2009 08:32:20 -0800 (PST) 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 1109428C0E5 for ; Sat, 24 Jan 2009 08:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=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 DJmkyQrTpNAB for ; Sat, 24 Jan 2009 08:32:19 -0800 (PST) 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 655F328C0F1 for ; Sat, 24 Jan 2009 08:32:19 -0800 (PST) Received: (qmail 40856 invoked from network); 24 Jan 2009 16:32:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 24 Jan 2009 16:32:00 -0000 X-YMail-OSG: eB4y_rcVM1lzVa_nWPDeAsAY3zwfgWT3Xs5PdLxqWmwnqOGP3RPyQtgXrCmVvpIeYysVGrOX_jsN.wcbU9rub7Aoe9gxVyflir0dPywL3vGmkZ9Ygvxu9CJNxP1ys93tS1m0vRDuHpvI4vF9OBulnUBbGXZqLMOxu9FdSvGf8rJ1VkBUr7b9kjBk X-Yahoo-Newman-Property: ymail-3 Message-ID: <497B427F.9000908@netconfcentral.com> Date: Sat, 24 Jan 2009 08:31:59 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETMOD Working Group Cc: NETCONF Subject: [Netconf] netconf.yang 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I published an I-D containing the netconf.yang module I wrote. I do not know if this would be a NETCONF work item, a NETMOD work item, or just an Informational individual submission. http://www.ietf.org/internet-drafts/draft-bierman-netmod-netconf-module-00.txt I agree with Phil and others that the solution for the 'with-defaults' feature should entail augmenting the appropriate RPC input sections with a leaf of some sort, rather than passing parameters on the side, via the XML attributes. This is a cleaner approach in both design and access control enforcement. In order to augment the NETCONF RPC methods, ever, for any reason, some choices will have to be made: - Should YANG and DSDL be supported, or just XSD? The NETMOD WG has declared XSD dead, long live DSDL, but the NETCONF WG has only XSD specifications. At some point, some convergence would be in order. - The 4741 XSD cannot be augmented, except in some anticipated nodes, such as adding new rpcOperationTypes. Adding new parameters to existing RPC operations is not currently supported by this XSD. If the 'with-defaults' work item in the new charter gets approved, then I would like a short timeslot at IETF #74 to discuss the netconf.yang draft and these issues. thanks, Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 03:23:25 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E593D28C16E; Sun, 25 Jan 2009 03:23:25 -0800 (PST) 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 6657928C16E for ; Sun, 25 Jan 2009 03:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, 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 uIXbRyZmEflF for ; Sun, 25 Jan 2009 03:23:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 43CA628C152 for ; Sun, 25 Jan 2009 03:23:21 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F65B76C229; Sun, 25 Jan 2009 12:23:03 +0100 (CET) Date: Sun, 25 Jan 2009 12:23:02 +0100 (CET) Message-Id: <20090125.122302.10891494.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090123130028.GA8291@elstar.local> References: <20090123130028.GA8291@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Juergen Schoenwaelder wrote: > s) The description leaves it open whether the identifier (or name) > contains a module name or a file name. This is not good for > interoperability. My idea was that each DML must define how it maps to this list. Such a section is included in the latest YANG draft, but maybe it should be included here instead? > Furthermore, the YANG description tells me again > something different. I suggest that it must be the module name for > data modeling languages that have a concept of a module name and it > may be a filename in other cases. This may work as well. > u) You make the assumption that a schema can only define one > namespace. This might be OK but I wanted to spell this out so that > the WG takes this design decision not by accident. We can easily change this to a leaf-list, but OTOH the three current DMLs all define one namespace only per module/file, and since the SchemaFormat is hardcoded in this data model (as an enumeration), this spec needs to be updated if a new DML comes along. And this leaf can be changed to a leaf-list at the same time, if necessary. > v) The location description is not consistent with the schemas and the > examples since it is actually a list. Well, the YANG says it is a > leaf but the example shows the encoding of a leaf-list. This is > screwed up (and probably the example is right). Yes, this should be a leaf-list in the YANG module. > w) The union of a string with the magic value "NETCONF" and a URI > looks really ugly. I suggest that a location leaf always contains a > URI. If you need a mechanism to indicate retrieval via get-schema, > create another empty leaf that is only present if retrieval is > possible via NETCONF get-schema. That works as well. I don't have any strong preference for either of the alternatives. > z) I fail to see why sourceHost is included at all. The IP address or > a DNS name is not sufficient to identify a client in all cases and > the value of this diminishes greatly if you have NATs and so on. Correct, but I think it's quite useful to have this information in many cases (i.e. when the client is not behind a NAT). In the worst case the information is not useful for some sessions. > F) The document assumes zero-based counters and no rollovers ever > happen: > > Ie: current time - startTime defines the collection interval for the > metrics allowing for calculations such as averages. I'm not sure I understand this comment. The YANG module uses the yang:zero-based-counter32 type, which will rollover. Or do you mean that the problem is that the normative text does not define this semantics? > K) Why is the schema in the example returned in CDATA?? To avoid using > in the example. This is just an XML encoding detail. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 03:23:25 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E593D28C16E; Sun, 25 Jan 2009 03:23:25 -0800 (PST) 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 6657928C16E for ; Sun, 25 Jan 2009 03:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.036, 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 uIXbRyZmEflF for ; Sun, 25 Jan 2009 03:23:21 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 43CA628C152 for ; Sun, 25 Jan 2009 03:23:21 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 2F65B76C229; Sun, 25 Jan 2009 12:23:03 +0100 (CET) Date: Sun, 25 Jan 2009 12:23:02 +0100 (CET) Message-Id: <20090125.122302.10891494.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090123130028.GA8291@elstar.local> References: <20090123130028.GA8291@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Juergen Schoenwaelder wrote: > s) The description leaves it open whether the identifier (or name) > contains a module name or a file name. This is not good for > interoperability. My idea was that each DML must define how it maps to this list. Such a section is included in the latest YANG draft, but maybe it should be included here instead? > Furthermore, the YANG description tells me again > something different. I suggest that it must be the module name for > data modeling languages that have a concept of a module name and it > may be a filename in other cases. This may work as well. > u) You make the assumption that a schema can only define one > namespace. This might be OK but I wanted to spell this out so that > the WG takes this design decision not by accident. We can easily change this to a leaf-list, but OTOH the three current DMLs all define one namespace only per module/file, and since the SchemaFormat is hardcoded in this data model (as an enumeration), this spec needs to be updated if a new DML comes along. And this leaf can be changed to a leaf-list at the same time, if necessary. > v) The location description is not consistent with the schemas and the > examples since it is actually a list. Well, the YANG says it is a > leaf but the example shows the encoding of a leaf-list. This is > screwed up (and probably the example is right). Yes, this should be a leaf-list in the YANG module. > w) The union of a string with the magic value "NETCONF" and a URI > looks really ugly. I suggest that a location leaf always contains a > URI. If you need a mechanism to indicate retrieval via get-schema, > create another empty leaf that is only present if retrieval is > possible via NETCONF get-schema. That works as well. I don't have any strong preference for either of the alternatives. > z) I fail to see why sourceHost is included at all. The IP address or > a DNS name is not sufficient to identify a client in all cases and > the value of this diminishes greatly if you have NATs and so on. Correct, but I think it's quite useful to have this information in many cases (i.e. when the client is not behind a NAT). In the worst case the information is not useful for some sessions. > F) The document assumes zero-based counters and no rollovers ever > happen: > > Ie: current time - startTime defines the collection interval for the > metrics allowing for calculations such as averages. I'm not sure I understand this comment. The YANG module uses the yang:zero-based-counter32 type, which will rollover. Or do you mean that the problem is that the normative text does not define this semantics? > K) Why is the schema in the example returned in CDATA?? To avoid using > in the example. This is just an XML encoding detail. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 03:44:01 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4493328C1D9; Sun, 25 Jan 2009 03:44:01 -0800 (PST) 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 042D328C1DC for ; Sun, 25 Jan 2009 03:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EAz3oGsdrExz for ; Sun, 25 Jan 2009 03:43:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 32F6228C1D9 for ; Sun, 25 Jan 2009 03:43:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A93B376C229; Sun, 25 Jan 2009 12:43:41 +0100 (CET) Date: Sun, 25 Jan 2009 12:43:38 +0100 (CET) Message-Id: <20090125.124338.175132894.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497A2605.6040504@netconfcentral.com> References: <497A2605.6040504@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > If the full XPath is supported, then arbitrary XPath > expressions are allowed. However, there are known > interoperability issues wrt/ some XPath constructs > as applied to NETCONF databases. These are not > addressed in the draft. > > The preceding, preceding-sibling, following, > and following-sibling axis are implementation-dependent. This is either NETCONF-specific, and if so, it should be documented in 4741bis; or it is data modeling language-specific, and if so it should be documented in the DML spec. Unless it's NETCONF-specific, I'm not sure it can be documented here? > It is not clear how the operator finds out exactly what > is locked. The operator gets a leaf-list of 'locked-node' elements in the reply. > What happens if config=false nodes are identified by the > XPath select expression? Is this documented? Is it an > error or NO-OP? It is documented that the select expression is evaluated for a data store. So if the expression refers to something that is not part of the data store, that reference will return an empty node set. config=false nodes are YANG-specific, but they are not part of any data store, so the effect is the same as referencing an unknown node. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 03:44:01 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4493328C1D9; Sun, 25 Jan 2009 03:44:01 -0800 (PST) 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 042D328C1DC for ; Sun, 25 Jan 2009 03:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EAz3oGsdrExz for ; Sun, 25 Jan 2009 03:43:59 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 32F6228C1D9 for ; Sun, 25 Jan 2009 03:43:59 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id A93B376C229; Sun, 25 Jan 2009 12:43:41 +0100 (CET) Date: Sun, 25 Jan 2009 12:43:38 +0100 (CET) Message-Id: <20090125.124338.175132894.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497A2605.6040504@netconfcentral.com> References: <497A2605.6040504@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > If the full XPath is supported, then arbitrary XPath > expressions are allowed. However, there are known > interoperability issues wrt/ some XPath constructs > as applied to NETCONF databases. These are not > addressed in the draft. > > The preceding, preceding-sibling, following, > and following-sibling axis are implementation-dependent. This is either NETCONF-specific, and if so, it should be documented in 4741bis; or it is data modeling language-specific, and if so it should be documented in the DML spec. Unless it's NETCONF-specific, I'm not sure it can be documented here? > It is not clear how the operator finds out exactly what > is locked. The operator gets a leaf-list of 'locked-node' elements in the reply. > What happens if config=false nodes are identified by the > XPath select expression? Is this documented? Is it an > error or NO-OP? It is documented that the select expression is evaluated for a data store. So if the expression refers to something that is not part of the data store, that reference will return an empty node set. config=false nodes are YANG-specific, but they are not part of any data store, so the effect is the same as referencing an unknown node. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 04:00:26 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E80728C1C9; Sun, 25 Jan 2009 04:00:26 -0800 (PST) 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 CEBBC28C1C9 for ; Sun, 25 Jan 2009 04:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 l9SWTJ5v3Bb5 for ; Sun, 25 Jan 2009 04:00:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1C2D128C199 for ; Sun, 25 Jan 2009 04:00:24 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8671CC0141; Sun, 25 Jan 2009 13:00:06 +0100 (CET) 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 xhBR5b1qIfPz; Sun, 25 Jan 2009 12:59:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 531FBC00AF; Sun, 25 Jan 2009 12:59:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A408391A1BA; Sun, 25 Jan 2009 12:59:53 +0100 (CET) Date: Sun, 25 Jan 2009 12:59:53 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090125115953.GA11202@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090125.122302.10891494.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sun, Jan 25, 2009 at 12:23:02PM +0100, Martin Bjorklund wrote: > > z) I fail to see why sourceHost is included at all. The IP address or > > a DNS name is not sufficient to identify a client in all cases and > > the value of this diminishes greatly if you have NATs and so on. > > Correct, but I think it's quite useful to have this information in > many cases (i.e. when the client is not behind a NAT). In the worst > case the information is not useful for some sessions. First, I claim reporting an IP address is not sufficient to identify a client. Second, I claim that there are well established ways to find out which clients are connected to a TCP server. Third, I claim it might be not easy to implement this leaf if all the netconf server has is a file description provided by an ssh daemon and which might not even be the socket connected to the client itself. Note that some popular SSH implementations do have mechanisms to mux new "connections" into existing SSH sessions by opening new channels. So even if the argument is that this leaf is needed to find out which client is related to a specific NETCONF server session and if you add a port number, there are still possible cases where it won't work or not provide necessarily meaninful results. Anyway, if the WG feels this leaf is really essential to have, then just ignore my comments. > > K) Why is the schema in the example returned in CDATA?? > > To avoid using > in the example. This is just an XML encoding > detail. It needs to be defined whether all models are supposed to be returned in CDATA or if implementors can choose whatever they like or something else. Right now, I believe this is under specified and this is what I wanted to point out. /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 netconf-bounces@ietf.org Sun Jan 25 04:00:26 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E80728C1C9; Sun, 25 Jan 2009 04:00:26 -0800 (PST) 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 CEBBC28C1C9 for ; Sun, 25 Jan 2009 04:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 l9SWTJ5v3Bb5 for ; Sun, 25 Jan 2009 04:00:24 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 1C2D128C199 for ; Sun, 25 Jan 2009 04:00:24 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8671CC0141; Sun, 25 Jan 2009 13:00:06 +0100 (CET) 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 xhBR5b1qIfPz; Sun, 25 Jan 2009 12:59:58 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 531FBC00AF; Sun, 25 Jan 2009 12:59:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A408391A1BA; Sun, 25 Jan 2009 12:59:53 +0100 (CET) Date: Sun, 25 Jan 2009 12:59:53 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090125115953.GA11202@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090125.122302.10891494.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sun, Jan 25, 2009 at 12:23:02PM +0100, Martin Bjorklund wrote: > > z) I fail to see why sourceHost is included at all. The IP address or > > a DNS name is not sufficient to identify a client in all cases and > > the value of this diminishes greatly if you have NATs and so on. > > Correct, but I think it's quite useful to have this information in > many cases (i.e. when the client is not behind a NAT). In the worst > case the information is not useful for some sessions. First, I claim reporting an IP address is not sufficient to identify a client. Second, I claim that there are well established ways to find out which clients are connected to a TCP server. Third, I claim it might be not easy to implement this leaf if all the netconf server has is a file description provided by an ssh daemon and which might not even be the socket connected to the client itself. Note that some popular SSH implementations do have mechanisms to mux new "connections" into existing SSH sessions by opening new channels. So even if the argument is that this leaf is needed to find out which client is related to a specific NETCONF server session and if you add a port number, there are still possible cases where it won't work or not provide necessarily meaninful results. Anyway, if the WG feels this leaf is really essential to have, then just ignore my comments. > > K) Why is the schema in the example returned in CDATA?? > > To avoid using > in the example. This is just an XML encoding > detail. It needs to be defined whether all models are supposed to be returned in CDATA or if implementors can choose whatever they like or something else. Right now, I believe this is under specified and this is what I wanted to point out. /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 netconf-bounces@ietf.org Sun Jan 25 07:10:34 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588133A6B2A; Sun, 25 Jan 2009 07:10:34 -0800 (PST) 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 6F8403A6B2A for ; Sun, 25 Jan 2009 07:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, 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 KeGGVVCmjxOS for ; Sun, 25 Jan 2009 07:10:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 98BB13A684B for ; Sun, 25 Jan 2009 07:10:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EC4FE616001; Sun, 25 Jan 2009 16:10:13 +0100 (CET) Date: Sun, 25 Jan 2009 16:10:13 +0100 (CET) Message-Id: <20090125.161013.41178797.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090125115953.GA11202@elstar.local> References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> <20090125115953.GA11202@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > > > K) Why is the schema in the example returned in CDATA?? > > > > To avoid using > in the example. This is just an XML encoding > > detail. > > It needs to be defined whether all models are supposed to be returned > in CDATA or if implementors can choose whatever they like or something > else. Right now, I believe this is under specified and this is what I > wanted to point out. IMO we should not specify which encoding servers should use, and it doesn't really matter. It is up to the server to use some legal XML encoding, and clients should be prepared to handle the legal variants. I don't think this object is different from any other object. For example, the element could be encoded as: This is legal XML and should be supported. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 07:10:34 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 588133A6B2A; Sun, 25 Jan 2009 07:10:34 -0800 (PST) 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 6F8403A6B2A for ; Sun, 25 Jan 2009 07:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.039, 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 KeGGVVCmjxOS for ; Sun, 25 Jan 2009 07:10:32 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 98BB13A684B for ; Sun, 25 Jan 2009 07:10:32 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id EC4FE616001; Sun, 25 Jan 2009 16:10:13 +0100 (CET) Date: Sun, 25 Jan 2009 16:10:13 +0100 (CET) Message-Id: <20090125.161013.41178797.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090125115953.GA11202@elstar.local> References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> <20090125115953.GA11202@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > > > K) Why is the schema in the example returned in CDATA?? > > > > To avoid using > in the example. This is just an XML encoding > > detail. > > It needs to be defined whether all models are supposed to be returned > in CDATA or if implementors can choose whatever they like or something > else. Right now, I believe this is under specified and this is what I > wanted to point out. IMO we should not specify which encoding servers should use, and it doesn't really matter. It is up to the server to use some legal XML encoding, and clients should be prepared to handle the legal variants. I don't think this object is different from any other object. For example, the element could be encoded as: This is legal XML and should be supported. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 07:43:38 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBE028C15D; Sun, 25 Jan 2009 07:43:38 -0800 (PST) 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 E79B53A6998 for ; Sun, 25 Jan 2009 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7tpFZ5a6sUOi for ; Sun, 25 Jan 2009 07:43:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2B113A68AE for ; Sun, 25 Jan 2009 07:43:35 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AA1FC014E; Sun, 25 Jan 2009 16:43:18 +0100 (CET) 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 Dn-k8O+47MyS; Sun, 25 Jan 2009 16:43:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5D3AC0154; Sun, 25 Jan 2009 16:43:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3234391A35F; Sun, 25 Jan 2009 16:43:07 +0100 (CET) Date: Sun, 25 Jan 2009 16:43:07 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090125154307.GA11535@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090125.161013.41178797.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sun, Jan 25, 2009 at 04:10:13PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > > K) Why is the schema in the example returned in CDATA?? > > > > > > To avoid using > in the example. This is just an XML encoding > > > detail. > > > > It needs to be defined whether all models are supposed to be returned > > in CDATA or if implementors can choose whatever they like or something > > else. Right now, I believe this is under specified and this is what I > > wanted to point out. > > IMO we should not specify which encoding servers should use, and it > doesn't really matter. It is up to the server to use some legal XML > encoding, and clients should be prepared to handle the legal variants. > I don't think this object is different from any other object. For > example, the element could be encoded as: > > > > This is legal XML and should be supported. I am not sure why different encodings increase interoperability. So you are saying I can wrap any YANG data type values into if I like to do so. Is that spelled out in the YANG draft somewhere? And if CDATA is so beautiful, what happens if a description clause contains the sequence ']]>'? Ah, the XML solution of using multiple CDATA of course: bar]]> So if I follow you, I can write 42 as everywhere in an XML instance document for leaf level { type int8; } since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this is the way to go, fine. But spell it out using scary examples so that people implementing things know about this and get it right. /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 netconf-bounces@ietf.org Sun Jan 25 07:43:38 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FBE028C15D; Sun, 25 Jan 2009 07:43:38 -0800 (PST) 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 E79B53A6998 for ; Sun, 25 Jan 2009 07:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7tpFZ5a6sUOi for ; Sun, 25 Jan 2009 07:43:36 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id A2B113A68AE for ; Sun, 25 Jan 2009 07:43:35 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3AA1FC014E; Sun, 25 Jan 2009 16:43:18 +0100 (CET) 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 Dn-k8O+47MyS; Sun, 25 Jan 2009 16:43:11 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5D3AC0154; Sun, 25 Jan 2009 16:43:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3234391A35F; Sun, 25 Jan 2009 16:43:07 +0100 (CET) Date: Sun, 25 Jan 2009 16:43:07 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090125154307.GA11535@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20090123130028.GA8291@elstar.local> <20090125.122302.10891494.mbj@tail-f.com> <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090125.161013.41178797.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Sun, Jan 25, 2009 at 04:10:13PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > > K) Why is the schema in the example returned in CDATA?? > > > > > > To avoid using > in the example. This is just an XML encoding > > > detail. > > > > It needs to be defined whether all models are supposed to be returned > > in CDATA or if implementors can choose whatever they like or something > > else. Right now, I believe this is under specified and this is what I > > wanted to point out. > > IMO we should not specify which encoding servers should use, and it > doesn't really matter. It is up to the server to use some legal XML > encoding, and clients should be prepared to handle the legal variants. > I don't think this object is different from any other object. For > example, the element could be encoded as: > > > > This is legal XML and should be supported. I am not sure why different encodings increase interoperability. So you are saying I can wrap any YANG data type values into if I like to do so. Is that spelled out in the YANG draft somewhere? And if CDATA is so beautiful, what happens if a description clause contains the sequence ']]>'? Ah, the XML solution of using multiple CDATA of course: bar]]> So if I follow you, I can write 42 as everywhere in an XML instance document for leaf level { type int8; } since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this is the way to go, fine. But spell it out using scary examples so that people implementing things know about this and get it right. /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 netconf-bounces@ietf.org Sun Jan 25 11:53:03 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA62C3A6954; Sun, 25 Jan 2009 11:53:03 -0800 (PST) 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 7CB7B3A6954 for ; Sun, 25 Jan 2009 11:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EymQfZRiKiS4 for ; Sun, 25 Jan 2009 11:53:01 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id AB6DA3A67E9 for ; Sun, 25 Jan 2009 11:53:01 -0800 (PST) Received: (qmail 19562 invoked from network); 25 Jan 2009 19:52:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2009 19:52:43 -0000 X-YMail-OSG: CeKaWFwVM1k3n3Vqj1wdDQ4U9Ca2W1Px10qvbQ_fubsx22nklC._FvjOfIFv6n3XNoNLWaQR1fU1qDzMJSsa.z6qfbC424bYEBXVpO6y7KuX_jgEB9iBy4g9hQSpMfEgJz.F6v9rENnd5_RrLBawtrKrbqy5LcecfLiwwGQFARGauoVEfwAFdcVEiFSv1xreBAEIZyCSXJoSwc12qFr4hQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497CC309.2010900@netconfcentral.com> Date: Sun, 25 Jan 2009 11:52:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497A2605.6040504@netconfcentral.com> <20090125.124338.175132894.mbj@tail-f.com> In-Reply-To: <20090125.124338.175132894.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> If the full XPath is supported, then arbitrary XPath >> expressions are allowed. However, there are known >> interoperability issues wrt/ some XPath constructs >> as applied to NETCONF databases. These are not >> addressed in the draft. >> >> The preceding, preceding-sibling, following, >> and following-sibling axis are implementation-dependent. > > This is either NETCONF-specific, and if so, it should be documented in > 4741bis; or it is data modeling language-specific, and if so it should > be documented in the DML spec. Unless it's NETCONF-specific, I'm not > sure it can be documented here? > Perhaps this should be in the YANG Usage Guidelines spec, which is intended to be BCP and not standards-track. I already put some text in the I-D about XPath. My bias comes from many years working on the embedded side of the fence. IMO, a NETCONF database is not an XML instance document. It is part of a particular implementation of the NETCONF protocol. In order to implement XPath to the letter, an agent implementation would have to maintain an XML representation of the entire configuration and all the state data, in addition to its native data structures. This would be a big problem for implementations which stream the PDU responses, based on the internal data structures (and perhaps sub-agents far away, etc.). There is no XML document inside, in this case. There's only so far I am willing to pretend that a NETCONF database inside an agent implementation is a proper nail for XPath to hammer on. >> It is not clear how the operator finds out exactly what >> is locked. > > The operator gets a leaf-list of 'locked-node' elements in the reply. > OK -- seems verbose, but this is XML, so not a problem then. >> What happens if config=false nodes are identified by the >> XPath select expression? Is this documented? Is it an >> error or NO-OP? > > It is documented that the select expression is evaluated for a data > store. So if the expression refers to something that is not part of > the data store, that reference will return an empty node set. > config=false nodes are YANG-specific, but they are not part of any > data store, so the effect is the same as referencing an unknown node. > IMO, a 'select' parameter with invalid XPath MUST cause an 'invalid-value' error. Everything else is just an empty nodeset. A 'select' parameter does not need to represent a node-set. So stupid XPath like select '7' is just an empty nodeset response and not an error. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 11:53:03 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA62C3A6954; Sun, 25 Jan 2009 11:53:03 -0800 (PST) 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 7CB7B3A6954 for ; Sun, 25 Jan 2009 11:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, GB_I_LETTER=-2, 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 EymQfZRiKiS4 for ; Sun, 25 Jan 2009 11:53:01 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id AB6DA3A67E9 for ; Sun, 25 Jan 2009 11:53:01 -0800 (PST) Received: (qmail 19562 invoked from network); 25 Jan 2009 19:52:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2009 19:52:43 -0000 X-YMail-OSG: CeKaWFwVM1k3n3Vqj1wdDQ4U9Ca2W1Px10qvbQ_fubsx22nklC._FvjOfIFv6n3XNoNLWaQR1fU1qDzMJSsa.z6qfbC424bYEBXVpO6y7KuX_jgEB9iBy4g9hQSpMfEgJz.F6v9rENnd5_RrLBawtrKrbqy5LcecfLiwwGQFARGauoVEfwAFdcVEiFSv1xreBAEIZyCSXJoSwc12qFr4hQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497CC309.2010900@netconfcentral.com> Date: Sun, 25 Jan 2009 11:52:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497A2605.6040504@netconfcentral.com> <20090125.124338.175132894.mbj@tail-f.com> In-Reply-To: <20090125.124338.175132894.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Full XPath and partial locking 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> If the full XPath is supported, then arbitrary XPath >> expressions are allowed. However, there are known >> interoperability issues wrt/ some XPath constructs >> as applied to NETCONF databases. These are not >> addressed in the draft. >> >> The preceding, preceding-sibling, following, >> and following-sibling axis are implementation-dependent. > > This is either NETCONF-specific, and if so, it should be documented in > 4741bis; or it is data modeling language-specific, and if so it should > be documented in the DML spec. Unless it's NETCONF-specific, I'm not > sure it can be documented here? > Perhaps this should be in the YANG Usage Guidelines spec, which is intended to be BCP and not standards-track. I already put some text in the I-D about XPath. My bias comes from many years working on the embedded side of the fence. IMO, a NETCONF database is not an XML instance document. It is part of a particular implementation of the NETCONF protocol. In order to implement XPath to the letter, an agent implementation would have to maintain an XML representation of the entire configuration and all the state data, in addition to its native data structures. This would be a big problem for implementations which stream the PDU responses, based on the internal data structures (and perhaps sub-agents far away, etc.). There is no XML document inside, in this case. There's only so far I am willing to pretend that a NETCONF database inside an agent implementation is a proper nail for XPath to hammer on. >> It is not clear how the operator finds out exactly what >> is locked. > > The operator gets a leaf-list of 'locked-node' elements in the reply. > OK -- seems verbose, but this is XML, so not a problem then. >> What happens if config=false nodes are identified by the >> XPath select expression? Is this documented? Is it an >> error or NO-OP? > > It is documented that the select expression is evaluated for a data > store. So if the expression refers to something that is not part of > the data store, that reference will return an empty node set. > config=false nodes are YANG-specific, but they are not part of any > data store, so the effect is the same as referencing an unknown node. > IMO, a 'select' parameter with invalid XPath MUST cause an 'invalid-value' error. Everything else is just an empty nodeset. A 'select' parameter does not need to represent a node-set. So stupid XPath like select '7' is just an empty nodeset response and not an error. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 12:06:44 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5AD3A68D0; Sun, 25 Jan 2009 12:06:44 -0800 (PST) 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 ACF033A68D0 for ; Sun, 25 Jan 2009 12:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZObINabGiG7U for ; Sun, 25 Jan 2009 12:06:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CE77F3A6857 for ; Sun, 25 Jan 2009 12:06:42 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5211976C229; Sun, 25 Jan 2009 21:06:25 +0100 (CET) Date: Sun, 25 Jan 2009 21:06:22 +0100 (CET) Message-Id: <20090125.210622.72405235.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090125154307.GA11535@elstar.local> References: <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> <20090125154307.GA11535@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I am not sure why different encodings increase interoperability. So > you are saying I can wrap any YANG data type values into > if I like to do so. Is that spelled out in the YANG draft somewhere? > And if CDATA is so beautiful, what happens if a description clause > contains the sequence ']]>'? Ah, the XML solution of using multiple > CDATA of course: > > bar]]> > > So if I follow you, I can write 42 as > > > > everywhere in an XML instance document for > > leaf level { type int8; } > > since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this > is the way to go, fine. But spell it out using scary examples so that > people implementing things know about this and get it right. I never said CDATA was beautiful. But as you noted, this is the way XML works. Maybe scary examples should be added, but if so, the right place is probably in section 3 ("XML Considerations") of 4741bis. I don't think the monitoring draft is the right place for this. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 12:06:44 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5AD3A68D0; Sun, 25 Jan 2009 12:06:44 -0800 (PST) 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 ACF033A68D0 for ; Sun, 25 Jan 2009 12:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.038, 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 ZObINabGiG7U for ; Sun, 25 Jan 2009 12:06:43 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id CE77F3A6857 for ; Sun, 25 Jan 2009 12:06:42 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 5211976C229; Sun, 25 Jan 2009 21:06:25 +0100 (CET) Date: Sun, 25 Jan 2009 21:06:22 +0100 (CET) Message-Id: <20090125.210622.72405235.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090125154307.GA11535@elstar.local> References: <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> <20090125154307.GA11535@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I am not sure why different encodings increase interoperability. So > you are saying I can wrap any YANG data type values into > if I like to do so. Is that spelled out in the YANG draft somewhere? > And if CDATA is so beautiful, what happens if a description clause > contains the sequence ']]>'? Ah, the XML solution of using multiple > CDATA of course: > > bar]]> > > So if I follow you, I can write 42 as > > > > everywhere in an XML instance document for > > leaf level { type int8; } > > since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this > is the way to go, fine. But spell it out using scary examples so that > people implementing things know about this and get it right. I never said CDATA was beautiful. But as you noted, this is the way XML works. Maybe scary examples should be added, but if so, the right place is probably in section 3 ("XML Considerations") of 4741bis. I don't think the monitoring draft is the right place for this. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 12:21:03 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6734F3A6844; Sun, 25 Jan 2009 12:21:03 -0800 (PST) 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 625AD3A6B57 for ; Sun, 25 Jan 2009 12:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 jqInQJUj8ktB for ; Sun, 25 Jan 2009 12:21:01 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id B61BD3A67E2 for ; Sun, 25 Jan 2009 12:21:01 -0800 (PST) Received: (qmail 49124 invoked from network); 25 Jan 2009 20:20:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2009 20:20:43 -0000 X-YMail-OSG: PsFytVQVM1ksjlY2GL1Y9FAIjiogq5RssFvh9q5o9O.P4Y.I94uRvWHFpPAQg6kugJxtN0qtaImUA_QIzaHWA_hQAhhPfuMarxRGp8m53pkD4baMvlBEVSZ9hoalxFr_6s9Bf6hw6pisMhMAWUPnDws5SqEbEBbP_JAktzOrZw.uCO891oyx3BGiAO7dvPdreoPFNC_PXdu9WvdHFd_S8Y3HBlD_vyIcpi9sQc8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497CC999.50807@netconfcentral.com> Date: Sun, 25 Jan 2009 12:20:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> <20090125154307.GA11535@elstar.local> <20090125.210622.72405235.mbj@tail-f.com> In-Reply-To: <20090125.210622.72405235.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> I am not sure why different encodings increase interoperability. So >> you are saying I can wrap any YANG data type values into >> if I like to do so. Is that spelled out in the YANG draft somewhere? >> And if CDATA is so beautiful, what happens if a description clause >> contains the sequence ']]>'? Ah, the XML solution of using multiple >> CDATA of course: >> >> bar]]> >> >> So if I follow you, I can write 42 as >> >> >> >> everywhere in an XML instance document for >> >> leaf level { type int8; } >> >> since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this >> is the way to go, fine. But spell it out using scary examples so that >> people implementing things know about this and get it right. > > I never said CDATA was beautiful. But as you noted, this is the way > XML works. Maybe scary examples should be added, but if so, the right > place is probably in section 3 ("XML Considerations") of 4741bis. I > don't think the monitoring draft is the right place for this. > This is kind of stretching the Postel Principle to the limit. I think the NETCONF/NETMOD documents should be silent on XML like this, and not encourage its use. > > /martin Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Jan 25 12:21:03 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6734F3A6844; Sun, 25 Jan 2009 12:21:03 -0800 (PST) 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 625AD3A6B57 for ; Sun, 25 Jan 2009 12:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 jqInQJUj8ktB for ; Sun, 25 Jan 2009 12:21:01 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id B61BD3A67E2 for ; Sun, 25 Jan 2009 12:21:01 -0800 (PST) Received: (qmail 49124 invoked from network); 25 Jan 2009 20:20:44 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@207.215.244.31 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 25 Jan 2009 20:20:43 -0000 X-YMail-OSG: PsFytVQVM1ksjlY2GL1Y9FAIjiogq5RssFvh9q5o9O.P4Y.I94uRvWHFpPAQg6kugJxtN0qtaImUA_QIzaHWA_hQAhhPfuMarxRGp8m53pkD4baMvlBEVSZ9hoalxFr_6s9Bf6hw6pisMhMAWUPnDws5SqEbEBbP_JAktzOrZw.uCO891oyx3BGiAO7dvPdreoPFNC_PXdu9WvdHFd_S8Y3HBlD_vyIcpi9sQc8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497CC999.50807@netconfcentral.com> Date: Sun, 25 Jan 2009 12:20:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <20090125115953.GA11202@elstar.local> <20090125.161013.41178797.mbj@tail-f.com> <20090125154307.GA11535@elstar.local> <20090125.210622.72405235.mbj@tail-f.com> In-Reply-To: <20090125.210622.72405235.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> I am not sure why different encodings increase interoperability. So >> you are saying I can wrap any YANG data type values into >> if I like to do so. Is that spelled out in the YANG draft somewhere? >> And if CDATA is so beautiful, what happens if a description clause >> contains the sequence ']]>'? Ah, the XML solution of using multiple >> CDATA of course: >> >> bar]]> >> >> So if I follow you, I can write 42 as >> >> >> >> everywhere in an XML instance document for >> >> leaf level { type int8; } >> >> since this is standard XML stuff? If the NETMOD/NETCONF WGs feel this >> is the way to go, fine. But spell it out using scary examples so that >> people implementing things know about this and get it right. > > I never said CDATA was beautiful. But as you noted, this is the way > XML works. Maybe scary examples should be added, but if so, the right > place is probably in section 3 ("XML Considerations") of 4741bis. I > don't think the monitoring draft is the right place for this. > This is kind of stretching the Postel Principle to the limit. I think the NETCONF/NETMOD documents should be silent on XML like this, and not encourage its use. > > /martin Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 07:16:00 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3FF3A6A07; Mon, 26 Jan 2009 07:16:00 -0800 (PST) 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 4BD173A67EC for ; Mon, 26 Jan 2009 07:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 A9rKd6dHyqUZ for ; Mon, 26 Jan 2009 07:15:59 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E7AB93A6A07 for ; Mon, 26 Jan 2009 07:15:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 67E1E207A3; Mon, 26 Jan 2009 16:15:39 +0100 (CET) X-AuditID: c1b4fb3c-ad75dbb00000304c-f9-497dd39b7192 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4ED2E204D4; Mon, 26 Jan 2009 16:15:39 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 16:15:39 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 16:15:38 +0100 Message-ID: <497DD39A.7030507@ericsson.com> Date: Mon, 26 Jan 2009 16:15:38 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> In-Reply-To: X-OriginalArrivalTime: 26 Jan 2009 15:15:38.0935 (UTC) FILETIME=[F2233470:01C97FC8] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Jurgen, If I would put the following example in an appendix and reference it from 2.4.1.2 would that be OK? What do you think of the example below? regards Balazs ================================================= As an example, lets say we have the data model container allUsers { list users { key name { type string; } ... other data ... } } and the datastore currently contains Fred ... other data ... We want to add user Joe and lock him immediately for further editing. The following is the proposed procedure to do it: Use with select=/.../allUsers. (Full RCP) This will return the node at /.../allUsers as the only node in the scope of the lock, but it will protect all nodes under allUsers from modification. Next create Joe. Now the datastore contains: Fred ... other data ... Joe ... other data ... Use with select=/.../allUsers/user[name="Joe"]. (Full RCP) This will return the node at /.../allUsers/user[name="Joe"] as the only node in the scope of the lock. If any nodes exist under this node, they are protected by both partial locks. Remove the first partial lock that locked . (Full RCP) The node at /.../allUsers/user[name="Joe"] and all nodes below it are still protected by the second partial lock. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 07:16:00 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3FF3A6A07; Mon, 26 Jan 2009 07:16:00 -0800 (PST) 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 4BD173A67EC for ; Mon, 26 Jan 2009 07:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 A9rKd6dHyqUZ for ; Mon, 26 Jan 2009 07:15:59 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E7AB93A6A07 for ; Mon, 26 Jan 2009 07:15:57 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 67E1E207A3; Mon, 26 Jan 2009 16:15:39 +0100 (CET) X-AuditID: c1b4fb3c-ad75dbb00000304c-f9-497dd39b7192 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4ED2E204D4; Mon, 26 Jan 2009 16:15:39 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 16:15:39 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Jan 2009 16:15:38 +0100 Message-ID: <497DD39A.7030507@ericsson.com> Date: Mon, 26 Jan 2009 16:15:38 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Juergen Schoenwaelder , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> In-Reply-To: X-OriginalArrivalTime: 26 Jan 2009 15:15:38.0935 (UTC) FILETIME=[F2233470:01C97FC8] X-Brightmail-Tracker: AAAAAA== Subject: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Jurgen, If I would put the following example in an appendix and reference it from 2.4.1.2 would that be OK? What do you think of the example below? regards Balazs ================================================= As an example, lets say we have the data model container allUsers { list users { key name { type string; } ... other data ... } } and the datastore currently contains Fred ... other data ... We want to add user Joe and lock him immediately for further editing. The following is the proposed procedure to do it: Use with select=/.../allUsers. (Full RCP) This will return the node at /.../allUsers as the only node in the scope of the lock, but it will protect all nodes under allUsers from modification. Next create Joe. Now the datastore contains: Fred ... other data ... Joe ... other data ... Use with select=/.../allUsers/user[name="Joe"]. (Full RCP) This will return the node at /.../allUsers/user[name="Joe"] as the only node in the scope of the lock. If any nodes exist under this node, they are protected by both partial locks. Remove the first partial lock that locked . (Full RCP) The node at /.../allUsers/user[name="Joe"] and all nodes below it are still protected by the second partial lock. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 09:01:23 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A6B3A6AF3; Mon, 26 Jan 2009 09:01:23 -0800 (PST) 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 D6A1E28C17C for ; Mon, 26 Jan 2009 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LK2i8DwBkpWB for ; Mon, 26 Jan 2009 09:01:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 86FA03A6807 for ; Mon, 26 Jan 2009 09:01:20 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACECCC0078; Mon, 26 Jan 2009 18:01:02 +0100 (CET) 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 OIpni+fVIObk; Mon, 26 Jan 2009 18:00:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C1FDC0065; Mon, 26 Jan 2009 18:00:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 383B191AE1E; Mon, 26 Jan 2009 18:00:51 +0100 (CET) Date: Mon, 26 Jan 2009 18:00:51 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090126170051.GA12088@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497DD39A.7030507@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: > If I would put the following example in an appendix and reference it > from 2.4.1.2 would that be OK? > What do you think of the example below? > regards Balazs > > ================================================= > > As an example, lets say we have the data model > > container allUsers { > list users { > key name { type string; } > ... other data ... > } > } > > and the datastore currently contains > > > > Fred > ... other data ... > > I would phrase the example by just showing the instance document to avoid any data modelling language issues. And it might be good to be consistent with the examples used in RFC 4741. > We want to add user Joe and lock him immediately for further editing. > The following is the proposed procedure to do it: > > Use with select=/.../allUsers. (Full RCP) You mean you want to show the full RPC message? > This will return the node at /.../allUsers as the only node in the scope of the > lock, but it will protect all nodes under allUsers from modification. > > Next create Joe. Now the datastore contains: > > > > Fred > ... other data ... > > > Joe > ... other data ... > > > > > Use with select=/.../allUsers/user[name="Joe"]. (Full RCP) > This will return the node at /.../allUsers/user[name="Joe"] as the only node in the > scope of the lock. If any nodes exist under this node, they are protected by both partial locks. What I do not understand is that on the one hand the lock on allUsers is claimed to protect everything below allUsers but then you can acquire a lock on Joe even though I thought it is locked. I am missing a clear explanation what a lock on a leaf implies and what a lock on a contained implies. Perhaps the idea is to say that a lock on a container locks the container for additions/removals but you wrote the lock on allUsers "protect all nodes under allUsers from modification" and this is where I am getting confused about the partial lock semantics. > Remove the first partial lock that locked . (Full RCP) > The node at /.../allUsers/user[name="Joe"] and all nodes below it > are still protected by the second partial > lock. If you say so... /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 netconf-bounces@ietf.org Mon Jan 26 09:01:23 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33A6B3A6AF3; Mon, 26 Jan 2009 09:01:23 -0800 (PST) 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 D6A1E28C17C for ; Mon, 26 Jan 2009 09:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 LK2i8DwBkpWB for ; Mon, 26 Jan 2009 09:01:20 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 86FA03A6807 for ; Mon, 26 Jan 2009 09:01:20 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ACECCC0078; Mon, 26 Jan 2009 18:01:02 +0100 (CET) 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 OIpni+fVIObk; Mon, 26 Jan 2009 18:00:56 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C1FDC0065; Mon, 26 Jan 2009 18:00:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 383B191AE1E; Mon, 26 Jan 2009 18:00:51 +0100 (CET) Date: Mon, 26 Jan 2009 18:00:51 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090126170051.GA12088@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497DD39A.7030507@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: > If I would put the following example in an appendix and reference it > from 2.4.1.2 would that be OK? > What do you think of the example below? > regards Balazs > > ================================================= > > As an example, lets say we have the data model > > container allUsers { > list users { > key name { type string; } > ... other data ... > } > } > > and the datastore currently contains > > > > Fred > ... other data ... > > I would phrase the example by just showing the instance document to avoid any data modelling language issues. And it might be good to be consistent with the examples used in RFC 4741. > We want to add user Joe and lock him immediately for further editing. > The following is the proposed procedure to do it: > > Use with select=/.../allUsers. (Full RCP) You mean you want to show the full RPC message? > This will return the node at /.../allUsers as the only node in the scope of the > lock, but it will protect all nodes under allUsers from modification. > > Next create Joe. Now the datastore contains: > > > > Fred > ... other data ... > > > Joe > ... other data ... > > > > > Use with select=/.../allUsers/user[name="Joe"]. (Full RCP) > This will return the node at /.../allUsers/user[name="Joe"] as the only node in the > scope of the lock. If any nodes exist under this node, they are protected by both partial locks. What I do not understand is that on the one hand the lock on allUsers is claimed to protect everything below allUsers but then you can acquire a lock on Joe even though I thought it is locked. I am missing a clear explanation what a lock on a leaf implies and what a lock on a contained implies. Perhaps the idea is to say that a lock on a container locks the container for additions/removals but you wrote the lock on allUsers "protect all nodes under allUsers from modification" and this is where I am getting confused about the partial lock semantics. > Remove the first partial lock that locked . (Full RCP) > The node at /.../allUsers/user[name="Joe"] and all nodes below it > are still protected by the second partial > lock. If you say so... /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 netconf-bounces@ietf.org Mon Jan 26 09:17:45 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AA128C25B; Mon, 26 Jan 2009 09:17:45 -0800 (PST) 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 ED8513A6A55 for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 yPThejvH4tNY for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 5796A3A67AC for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) Received: (qmail 31466 invoked from network); 26 Jan 2009 17:17:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2009 17:17:25 -0000 X-YMail-OSG: BCNSsdoVM1nLd6zIYydHv3Ix8gRi7rIgza58ZJNGbQvjzyk2qHHvtOnCyJRbaaHEbnFvQiaUxqJNCmUB5TTgSsADI1NXXQeNYa5Qu9LLVV_YaXPPc_ojLbCJRBZC8N4I768om.UhhJJRQhCacKBwtRbv X-Yahoo-Newman-Property: ymail-3 Message-ID: <497DF023.1060907@netconfcentral.com> Date: Mon, 26 Jan 2009 09:17:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> In-Reply-To: <20090126170051.GA12088@elstar.local> Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: >.... > What I do not understand is that on the one hand the lock on allUsers > is claimed to protect everything below allUsers but then you can > acquire a lock on Joe even though I thought it is locked. I am missing > a clear explanation what a lock on a leaf implies and what a lock on a > contained implies. Perhaps the idea is to say that a lock on a > container locks the container for additions/removals but you wrote the > lock on allUsers "protect all nodes under allUsers from modification" > and this is where I am getting confused about the partial lock > semantics. > >> Remove the first partial lock that locked . (Full RCP) >> The node at /.../allUsers/user[name="Joe"] and all nodes below it >> are still protected by the second partial >> lock. > > If you say so... > I do not like this 'feature' at all. Obviously only the current lock holder is allowed to take out another partial lock on nodes it already has locked. Otherwise the entire draft is pointless. But since the only one allowed to take out additional locks already knows exactly what nodes are currently locked, that application should simply avoid requesting these nodes. (I've seen projects where they move as much complexity to the agent as possible. It never works out so well. Good luck this time around.) > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 09:17:45 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AA128C25B; Mon, 26 Jan 2009 09:17:45 -0800 (PST) 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 ED8513A6A55 for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 yPThejvH4tNY for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) Received: from smtp123.sbc.mail.sp1.yahoo.com (smtp123.sbc.mail.sp1.yahoo.com [69.147.64.96]) by core3.amsl.com (Postfix) with SMTP id 5796A3A67AC for ; Mon, 26 Jan 2009 09:17:44 -0800 (PST) Received: (qmail 31466 invoked from network); 26 Jan 2009 17:17:27 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2009 17:17:25 -0000 X-YMail-OSG: BCNSsdoVM1nLd6zIYydHv3Ix8gRi7rIgza58ZJNGbQvjzyk2qHHvtOnCyJRbaaHEbnFvQiaUxqJNCmUB5TTgSsADI1NXXQeNYa5Qu9LLVV_YaXPPc_ojLbCJRBZC8N4I768om.UhhJJRQhCacKBwtRbv X-Yahoo-Newman-Property: ymail-3 Message-ID: <497DF023.1060907@netconfcentral.com> Date: Mon, 26 Jan 2009 09:17:23 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> In-Reply-To: <20090126170051.GA12088@elstar.local> Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: >.... > What I do not understand is that on the one hand the lock on allUsers > is claimed to protect everything below allUsers but then you can > acquire a lock on Joe even though I thought it is locked. I am missing > a clear explanation what a lock on a leaf implies and what a lock on a > contained implies. Perhaps the idea is to say that a lock on a > container locks the container for additions/removals but you wrote the > lock on allUsers "protect all nodes under allUsers from modification" > and this is where I am getting confused about the partial lock > semantics. > >> Remove the first partial lock that locked . (Full RCP) >> The node at /.../allUsers/user[name="Joe"] and all nodes below it >> are still protected by the second partial >> lock. > > If you say so... > I do not like this 'feature' at all. Obviously only the current lock holder is allowed to take out another partial lock on nodes it already has locked. Otherwise the entire draft is pointless. But since the only one allowed to take out additional locks already knows exactly what nodes are currently locked, that application should simply avoid requesting these nodes. (I've seen projects where they move as much complexity to the agent as possible. It never works out so well. Good luck this time around.) > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 12:21:33 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464143A6915; Mon, 26 Jan 2009 12:21:33 -0800 (PST) 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 645923A6915 for ; Mon, 26 Jan 2009 12:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Nps66PcSTmS4 for ; Mon, 26 Jan 2009 12:21:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9A86A3A68D7 for ; Mon, 26 Jan 2009 12:21:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00CF876C252; Mon, 26 Jan 2009 21:21:12 +0100 (CET) Date: Mon, 26 Jan 2009 21:21:08 +0100 (CET) Message-Id: <20090126.212108.102560980.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497DF023.1060907@netconfcentral.com> References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > >> Remove the first partial lock that locked . (Full RCP) > >> The node at /.../allUsers/user[name="Joe"] and all nodes below > >> it are still protected by the second partial > >> lock. > > If you say so... > > > > > I do not like this 'feature' at all. > Obviously only the current lock holder is allowed > to take out another partial lock on nodes it already > has locked. Otherwise the entire draft is pointless. Yes you're right. > But since the only one allowed to take out additional > locks already knows exactly what nodes are currently locked, > that application should simply avoid requesting these nodes. I don't understand what you mean. The example does this: lock /top/allUsers --> lock-id=1 edit-config create /top/allUsers/user[name='joe'] --> ok lock /top/allUsers/user[name='joe'] --> lock-id=2 unlock lock-id=1 ... many edit-configs towards new user joe... unlock lock-id=2 > (I've seen projects where they move as much complexity > to the agent as possible. It never works out so well. > Good luck this time around.) We implemented this even before the draft was done. Compared to the other capabilities, this was one of the more trivial to implement efficiently (ok, global lock is even simpler). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 12:21:33 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464143A6915; Mon, 26 Jan 2009 12:21:33 -0800 (PST) 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 645923A6915 for ; Mon, 26 Jan 2009 12:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Nps66PcSTmS4 for ; Mon, 26 Jan 2009 12:21:31 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 9A86A3A68D7 for ; Mon, 26 Jan 2009 12:21:31 -0800 (PST) Received: from localhost (c213-100-167-236.swipnet.se [213.100.167.236]) by mail.tail-f.com (Postfix) with ESMTPSA id 00CF876C252; Mon, 26 Jan 2009 21:21:12 +0100 (CET) Date: Mon, 26 Jan 2009 21:21:08 +0100 (CET) Message-Id: <20090126.212108.102560980.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497DF023.1060907@netconfcentral.com> References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > >> Remove the first partial lock that locked . (Full RCP) > >> The node at /.../allUsers/user[name="Joe"] and all nodes below > >> it are still protected by the second partial > >> lock. > > If you say so... > > > > > I do not like this 'feature' at all. > Obviously only the current lock holder is allowed > to take out another partial lock on nodes it already > has locked. Otherwise the entire draft is pointless. Yes you're right. > But since the only one allowed to take out additional > locks already knows exactly what nodes are currently locked, > that application should simply avoid requesting these nodes. I don't understand what you mean. The example does this: lock /top/allUsers --> lock-id=1 edit-config create /top/allUsers/user[name='joe'] --> ok lock /top/allUsers/user[name='joe'] --> lock-id=2 unlock lock-id=1 ... many edit-configs towards new user joe... unlock lock-id=2 > (I've seen projects where they move as much complexity > to the agent as possible. It never works out so well. > Good luck this time around.) We implemented this even before the draft was done. Compared to the other capabilities, this was one of the more trivial to implement efficiently (ok, global lock is even simpler). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 12:46:54 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE363A6A57; Mon, 26 Jan 2009 12:46:54 -0800 (PST) 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 9A76E3A69F1 for ; Mon, 26 Jan 2009 12:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 5zobXri5QqCt for ; Mon, 26 Jan 2009 12:46:52 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id DB3E83A685E for ; Mon, 26 Jan 2009 12:46:52 -0800 (PST) Received: (qmail 79575 invoked from network); 26 Jan 2009 20:46:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2009 20:46:34 -0000 X-YMail-OSG: HPGlwgIVM1mH4Ax2UuE1QYm1HcLDuxXfvB.qB.jTdqOnIBUt_5yhBxm4wVGapGh86QJKSPGkU98zvUKL_P2nwv0ouRmV2oSkPyyizKj3_fOYZmkF9DX.Nn63Bo6MLjG7w8Ahx.bm321HMdb77EII3Ic7cne0fTXNsRVvmrbhAPDkUX7q3gqrE2Vm6LFYF6ri1gB42qad6mAw.ItKS5CJCA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497E2128.8060408@netconfcentral.com> Date: Mon, 26 Jan 2009 12:46:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> <20090126.212108.102560980.mbj@tail-f.com> In-Reply-To: <20090126.212108.102560980.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>>> Remove the first partial lock that locked . (Full RCP) >>>> The node at /.../allUsers/user[name="Joe"] and all nodes below >>>> it are still protected by the second partial >>>> lock. >>> If you say so... >>> >> >> I do not like this 'feature' at all. >> Obviously only the current lock holder is allowed >> to take out another partial lock on nodes it already >> has locked. Otherwise the entire draft is pointless. > > Yes you're right. > >> But since the only one allowed to take out additional >> locks already knows exactly what nodes are currently locked, >> that application should simply avoid requesting these nodes. > > I don't understand what you mean. The example does this: > > lock /top/allUsers --> lock-id=1 > edit-config create /top/allUsers/user[name='joe'] --> ok > lock /top/allUsers/user[name='joe'] --> lock-id=2 > unlock lock-id=1 > ... many edit-configs towards new user joe... > unlock lock-id=2 > This is a totally different use-case. This is fine (I guess). Granting a lock to a node that is not currently locked is not the same thing as granting a node a lock that is already locked. The new node is not locked by rules of the I-D, but IMO those rules are not intuitive at all. In practice, any other session must access /top/allUsers before it can access /top/allUsers/user, so the fact that user 'joe' is not locked is not relevant. What would be better (IMO) is a 'create-and-lock' operation attribute value for , so /top/allUsers never needs to be locked in the first place. >> (I've seen projects where they move as much complexity >> to the agent as possible. It never works out so well. >> Good luck this time around.) > > We implemented this even before the draft was done. Compared to the > other capabilities, this was one of the more trivial to implement > efficiently (ok, global lock is even simpler). > The draft came from your implementation, so I fail to see how that is relevant. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Jan 26 12:46:54 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EE363A6A57; Mon, 26 Jan 2009 12:46:54 -0800 (PST) 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 9A76E3A69F1 for ; Mon, 26 Jan 2009 12:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.066, 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 5zobXri5QqCt for ; Mon, 26 Jan 2009 12:46:52 -0800 (PST) Received: from smtp119.sbc.mail.sp1.yahoo.com (smtp119.sbc.mail.sp1.yahoo.com [69.147.64.92]) by core3.amsl.com (Postfix) with SMTP id DB3E83A685E for ; Mon, 26 Jan 2009 12:46:52 -0800 (PST) Received: (qmail 79575 invoked from network); 26 Jan 2009 20:46:35 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp119.sbc.mail.sp1.yahoo.com with SMTP; 26 Jan 2009 20:46:34 -0000 X-YMail-OSG: HPGlwgIVM1mH4Ax2UuE1QYm1HcLDuxXfvB.qB.jTdqOnIBUt_5yhBxm4wVGapGh86QJKSPGkU98zvUKL_P2nwv0ouRmV2oSkPyyizKj3_fOYZmkF9DX.Nn63Bo6MLjG7w8Ahx.bm321HMdb77EII3Ic7cne0fTXNsRVvmrbhAPDkUX7q3gqrE2Vm6LFYF6ri1gB42qad6mAw.ItKS5CJCA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <497E2128.8060408@netconfcentral.com> Date: Mon, 26 Jan 2009 12:46:32 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> <20090126.212108.102560980.mbj@tail-f.com> In-Reply-To: <20090126.212108.102560980.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >>>> Remove the first partial lock that locked . (Full RCP) >>>> The node at /.../allUsers/user[name="Joe"] and all nodes below >>>> it are still protected by the second partial >>>> lock. >>> If you say so... >>> >> >> I do not like this 'feature' at all. >> Obviously only the current lock holder is allowed >> to take out another partial lock on nodes it already >> has locked. Otherwise the entire draft is pointless. > > Yes you're right. > >> But since the only one allowed to take out additional >> locks already knows exactly what nodes are currently locked, >> that application should simply avoid requesting these nodes. > > I don't understand what you mean. The example does this: > > lock /top/allUsers --> lock-id=1 > edit-config create /top/allUsers/user[name='joe'] --> ok > lock /top/allUsers/user[name='joe'] --> lock-id=2 > unlock lock-id=1 > ... many edit-configs towards new user joe... > unlock lock-id=2 > This is a totally different use-case. This is fine (I guess). Granting a lock to a node that is not currently locked is not the same thing as granting a node a lock that is already locked. The new node is not locked by rules of the I-D, but IMO those rules are not intuitive at all. In practice, any other session must access /top/allUsers before it can access /top/allUsers/user, so the fact that user 'joe' is not locked is not relevant. What would be better (IMO) is a 'create-and-lock' operation attribute value for , so /top/allUsers never needs to be locked in the first place. >> (I've seen projects where they move as much complexity >> to the agent as possible. It never works out so well. >> Good luck this time around.) > > We implemented this even before the draft was done. Compared to the > other capabilities, this was one of the more trivial to implement > efficiently (ok, global lock is even simpler). > The draft came from your implementation, so I fail to see how that is relevant. > > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 00:37:03 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F4F3A6B0F; Tue, 27 Jan 2009 00:37:03 -0800 (PST) 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 B79693A6B0F for ; Tue, 27 Jan 2009 00:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 eFhAZzTEM4qe for ; Tue, 27 Jan 2009 00:37:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 95F8E3A6A53 for ; Tue, 27 Jan 2009 00:37:00 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1128CC0007; Tue, 27 Jan 2009 09:36:42 +0100 (CET) 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 B+nXfyDieSw7; Tue, 27 Jan 2009 09:36:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7B50C000C; Tue, 27 Jan 2009 09:36:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC71D91B1FD; Tue, 27 Jan 2009 09:36:30 +0100 (CET) Date: Tue, 27 Jan 2009 09:36:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090127083630.GA12355@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netconf@ietf.org References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497E2128.8060408@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 26, 2009 at 12:46:32PM -0800, Andy Bierman wrote: > This is a totally different use-case. > This is fine (I guess). Granting a lock to a node that > is not currently locked is not the same thing > as granting a node a lock that is already locked. > > The new node is not locked by rules of the I-D, > but IMO those rules are not intuitive at all. > In practice, any other session must access > /top/allUsers before it can access /top/allUsers/user, > so the fact that user 'joe' is not locked is not relevant. I do not understand the semantics. In the example, it was said that the lock on allUsers locks everything below allUsers. If that were true, I would assume that the new user would automatically be locked as well. This might have all been easy to implement but the written down words make it hard for me to understand what a lock on a container really means. /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 netconf-bounces@ietf.org Tue Jan 27 00:37:03 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68F4F3A6B0F; Tue, 27 Jan 2009 00:37:03 -0800 (PST) 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 B79693A6B0F for ; Tue, 27 Jan 2009 00:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 eFhAZzTEM4qe for ; Tue, 27 Jan 2009 00:37:01 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 95F8E3A6A53 for ; Tue, 27 Jan 2009 00:37:00 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1128CC0007; Tue, 27 Jan 2009 09:36:42 +0100 (CET) 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 B+nXfyDieSw7; Tue, 27 Jan 2009 09:36:35 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7B50C000C; Tue, 27 Jan 2009 09:36:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AC71D91B1FD; Tue, 27 Jan 2009 09:36:30 +0100 (CET) Date: Tue, 27 Jan 2009 09:36:30 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20090127083630.GA12355@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , netconf@ietf.org References: <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <497DF023.1060907@netconfcentral.com> <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <497E2128.8060408@netconfcentral.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Mon, Jan 26, 2009 at 12:46:32PM -0800, Andy Bierman wrote: > This is a totally different use-case. > This is fine (I guess). Granting a lock to a node that > is not currently locked is not the same thing > as granting a node a lock that is already locked. > > The new node is not locked by rules of the I-D, > but IMO those rules are not intuitive at all. > In practice, any other session must access > /top/allUsers before it can access /top/allUsers/user, > so the fact that user 'joe' is not locked is not relevant. I do not understand the semantics. In the example, it was said that the lock on allUsers locks everything below allUsers. If that were true, I would assume that the new user would automatically be locked as well. This might have all been easy to implement but the written down words make it hard for me to understand what a lock on a container really means. /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 netconf-bounces@ietf.org Tue Jan 27 01:42:21 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8D03A692A; Tue, 27 Jan 2009 01:42:21 -0800 (PST) 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 916D43A692A for ; Tue, 27 Jan 2009 01:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 rikk5Mq1gU5C for ; Tue, 27 Jan 2009 01:42:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C54623A685F for ; Tue, 27 Jan 2009 01:42:19 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1090E76C229; Tue, 27 Jan 2009 10:42:01 +0100 (CET) Date: Tue, 27 Jan 2009 10:42:00 +0100 (CET) Message-Id: <20090127.104200.164214226.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090127083630.GA12355@elstar.local> References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I do not understand the semantics. In the example, it was said that > the lock on allUsers locks everything below allUsers. If that were > true, I would assume that the new user would automatically be locked > as well. Sure. I think we need to backtrack a bit. The original question was that given that non-existing nodes cannot be locked, how can we create a new user 'joe' w/o risking someone else modifying him. The simple approach of: create joe --> ok lock joe --> ok unlock joe --> ok is not safe, since someone else might edit joe before the lock is granted. So what you can do is simply: lock users --> ok create joe --> ok unlock users --> ok this is safe, but has the drawback of locking *all* users. To minimize the time all users are locked, you can do: lock users --> ok create joe --> ok lock joe --> ok unlock users --> ok unlock joe --> ok This is what Balazs' example shows. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 01:42:21 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8D03A692A; Tue, 27 Jan 2009 01:42:21 -0800 (PST) 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 916D43A692A for ; Tue, 27 Jan 2009 01:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 rikk5Mq1gU5C for ; Tue, 27 Jan 2009 01:42:19 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id C54623A685F for ; Tue, 27 Jan 2009 01:42:19 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1090E76C229; Tue, 27 Jan 2009 10:42:01 +0100 (CET) Date: Tue, 27 Jan 2009 10:42:00 +0100 (CET) Message-Id: <20090127.104200.164214226.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20090127083630.GA12355@elstar.local> References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > I do not understand the semantics. In the example, it was said that > the lock on allUsers locks everything below allUsers. If that were > true, I would assume that the new user would automatically be locked > as well. Sure. I think we need to backtrack a bit. The original question was that given that non-existing nodes cannot be locked, how can we create a new user 'joe' w/o risking someone else modifying him. The simple approach of: create joe --> ok lock joe --> ok unlock joe --> ok is not safe, since someone else might edit joe before the lock is granted. So what you can do is simply: lock users --> ok create joe --> ok unlock users --> ok this is safe, but has the drawback of locking *all* users. To minimize the time all users are locked, you can do: lock users --> ok create joe --> ok lock joe --> ok unlock users --> ok unlock joe --> ok This is what Balazs' example shows. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 02:52:56 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DB93A67B3; Tue, 27 Jan 2009 02:52:56 -0800 (PST) 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 1E0E428C0EE for ; Tue, 27 Jan 2009 02:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 bA6YWttq5xJk for ; Tue, 27 Jan 2009 02:52:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0CAF628C13B for ; Tue, 27 Jan 2009 02:52:54 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34A40C00A5; Tue, 27 Jan 2009 11:52:36 +0100 (CET) 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 i4KB+bBJpfrp; Tue, 27 Jan 2009 11:52:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F0DBC005C; Tue, 27 Jan 2009 11:52:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8125491B639; Tue, 27 Jan 2009 11:52:23 +0100 (CET) Date: Tue, 27 Jan 2009 11:52:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090127105223.GB12610@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netconf@ietf.org References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090127.104200.164214226.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: > To minimize the time all users are locked, you can do: > > lock users --> ok > create joe --> ok > lock joe --> ok > unlock users --> ok > > unlock joe --> ok > > This is what Balazs' example shows. But this requires to spell out in detail under which conditions you can lock something that is already locked. /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 netconf-bounces@ietf.org Tue Jan 27 02:52:56 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80DB93A67B3; Tue, 27 Jan 2009 02:52:56 -0800 (PST) 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 1E0E428C0EE for ; Tue, 27 Jan 2009 02:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 bA6YWttq5xJk for ; Tue, 27 Jan 2009 02:52:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0CAF628C13B for ; Tue, 27 Jan 2009 02:52:54 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 34A40C00A5; Tue, 27 Jan 2009 11:52:36 +0100 (CET) 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 i4KB+bBJpfrp; Tue, 27 Jan 2009 11:52:28 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F0DBC005C; Tue, 27 Jan 2009 11:52:28 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8125491B639; Tue, 27 Jan 2009 11:52:23 +0100 (CET) Date: Tue, 27 Jan 2009 11:52:23 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20090127105223.GB12610@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@netconfcentral.com, netconf@ietf.org References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090127.104200.164214226.mbj@tail-f.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: > To minimize the time all users are locked, you can do: > > lock users --> ok > create joe --> ok > lock joe --> ok > unlock users --> ok > > unlock joe --> ok > > This is what Balazs' example shows. But this requires to spell out in detail under which conditions you can lock something that is already locked. /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 netconf-bounces@ietf.org Tue Jan 27 04:46:28 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5E93A6A4B; Tue, 27 Jan 2009 04:46:28 -0800 (PST) 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 8EEE83A68CC for ; Tue, 27 Jan 2009 04:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, 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 tUrJNsRPYmTn for ; Tue, 27 Jan 2009 04:46:26 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 67EC13A6A8B for ; Tue, 27 Jan 2009 04:46:20 -0800 (PST) Received: (qmail 29529 invoked from network); 27 Jan 2009 12:46:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 12:45:59 -0000 X-YMail-OSG: yu9nFYkVM1lfRgYS8g34CVi_rwP2q3dO.6xkFssSo0fPv7J6xwLfxN3AickE4Zvphpj0jI0HzvaUCuMBK3kUAYmq10VCGYOeqXXxeTLLFMjfLTSPMP7ZGi5pA73FcnGST9HvcJF0.Quz6p3dI9xO7iku X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F0205.5020108@netconfcentral.com> Date: Tue, 27 Jan 2009 04:45:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund , andy@netconfcentral.com, netconf@ietf.org References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> <20090127105223.GB12610@elstar.local> In-Reply-To: <20090127105223.GB12610@elstar.local> Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: > >> To minimize the time all users are locked, you can do: >> >> lock users --> ok >> create joe --> ok >> lock joe --> ok >> unlock users --> ok >> >> unlock joe --> ok >> >> This is what Balazs' example shows. > > But this requires to spell out in detail under which conditions you > can lock something that is already locked. > I agree the details must be in normative text. I really do not like this precedent, especially since the eventual access control model might attempt to be compatible with partial locking. IMO, the main idea is broken -- that a lock on '/top/users' does not mean all the nodes under /top/users are locked. Instead it means that the lock holder can keep locking nodes under /top/users. This is different than a global lock. A 2nd call to lock, even by the lock-holder, is considered an application error, and the lock request is rejected. Changing this behavior for partial-lock is inconsistent. It would be better to treat this an an application error as well. If any node in the path from root to the selected node is already locked, then the new lock request MUST fail. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 04:46:28 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5E93A6A4B; Tue, 27 Jan 2009 04:46:28 -0800 (PST) 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 8EEE83A68CC for ; Tue, 27 Jan 2009 04:46:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=0.065, 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 tUrJNsRPYmTn for ; Tue, 27 Jan 2009 04:46:26 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 67EC13A6A8B for ; Tue, 27 Jan 2009 04:46:20 -0800 (PST) Received: (qmail 29529 invoked from network); 27 Jan 2009 12:46:02 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 12:45:59 -0000 X-YMail-OSG: yu9nFYkVM1lfRgYS8g34CVi_rwP2q3dO.6xkFssSo0fPv7J6xwLfxN3AickE4Zvphpj0jI0HzvaUCuMBK3kUAYmq10VCGYOeqXXxeTLLFMjfLTSPMP7ZGi5pA73FcnGST9HvcJF0.Quz6p3dI9xO7iku X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F0205.5020108@netconfcentral.com> Date: Tue, 27 Jan 2009 04:45:57 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund , andy@netconfcentral.com, netconf@ietf.org References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> <20090127105223.GB12610@elstar.local> In-Reply-To: <20090127105223.GB12610@elstar.local> Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: > >> To minimize the time all users are locked, you can do: >> >> lock users --> ok >> create joe --> ok >> lock joe --> ok >> unlock users --> ok >> >> unlock joe --> ok >> >> This is what Balazs' example shows. > > But this requires to spell out in detail under which conditions you > can lock something that is already locked. > I agree the details must be in normative text. I really do not like this precedent, especially since the eventual access control model might attempt to be compatible with partial locking. IMO, the main idea is broken -- that a lock on '/top/users' does not mean all the nodes under /top/users are locked. Instead it means that the lock holder can keep locking nodes under /top/users. This is different than a global lock. A 2nd call to lock, even by the lock-holder, is considered an application error, and the lock request is rejected. Changing this behavior for partial-lock is inconsistent. It would be better to treat this an an application error as well. If any node in the path from root to the selected node is already locked, then the new lock request MUST fail. > /js > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 05:08:39 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4BF3A6A32; Tue, 27 Jan 2009 05:08:39 -0800 (PST) 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 90D643A6AB7 for ; Tue, 27 Jan 2009 05:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, 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 V3ysDrTDwkmU for ; Tue, 27 Jan 2009 05:08:37 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id F0C793A69C1 for ; Tue, 27 Jan 2009 05:08:36 -0800 (PST) Received: (qmail 29016 invoked from network); 27 Jan 2009 13:08:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 13:08:17 -0000 X-YMail-OSG: bpmaR2cVM1lSJYGFi0F0GBTcIcYet5E6upagJ62QUe3NFzy90ww7AcNeakJE7xynK6U1y2W2.QvgRKnnt1uVm8m_k0fwxZ.3vVymDZ91oI1h6cg1M4Nf2.KdhDKO6UlQOVbdyzPuemoLXjRMJSGQv65p X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F073F.7070704@netconfcentral.com> Date: Tue, 27 Jan 2009 05:08:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, the draft says that an error will be returned if any select parameter is not a node-set. This is good. It also says that it is an error if a select parameter is an empty node set. IMO, it should only be an error if the entire request yields an empty node-set. (A) (B) Assuming that /a exists and /bogus does not, it would be nice if both requests (A) and (B) succeeded, instead of just (A). Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 05:08:39 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4BF3A6A32; Tue, 27 Jan 2009 05:08:39 -0800 (PST) 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 90D643A6AB7 for ; Tue, 27 Jan 2009 05:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.064, 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 V3ysDrTDwkmU for ; Tue, 27 Jan 2009 05:08:37 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id F0C793A69C1 for ; Tue, 27 Jan 2009 05:08:36 -0800 (PST) Received: (qmail 29016 invoked from network); 27 Jan 2009 13:08:18 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.68.233 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 13:08:17 -0000 X-YMail-OSG: bpmaR2cVM1lSJYGFi0F0GBTcIcYet5E6upagJ62QUe3NFzy90ww7AcNeakJE7xynK6U1y2W2.QvgRKnnt1uVm8m_k0fwxZ.3vVymDZ91oI1h6cg1M4Nf2.KdhDKO6UlQOVbdyzPuemoLXjRMJSGQv65p X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F073F.7070704@netconfcentral.com> Date: Tue, 27 Jan 2009 05:08:15 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, the draft says that an error will be returned if any select parameter is not a node-set. This is good. It also says that it is an error if a select parameter is an empty node set. IMO, it should only be an error if the entire request yields an empty node-set. (A) (B) Assuming that /a exists and /bogus does not, it would be nice if both requests (A) and (B) succeeded, instead of just (A). Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 06:02:08 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8064D3A6B3E; Tue, 27 Jan 2009 06:02:08 -0800 (PST) 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 AEDE93A6AA3 for ; Tue, 27 Jan 2009 06:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Qz+OdOEsb2Wl for ; Tue, 27 Jan 2009 06:02:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4FC7128C198 for ; Tue, 27 Jan 2009 06:01:12 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E098076C229; Tue, 27 Jan 2009 15:00:52 +0100 (CET) Date: Tue, 27 Jan 2009 15:00:52 +0100 (CET) Message-Id: <20090127.150052.30926042.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497F073F.7070704@netconfcentral.com> References: <497F073F.7070704@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > the draft says that an error will be returned > if any select parameter is not a node-set. > This is good. It also says that it is an error > if a select parameter is an empty node set. > > IMO, it should only be an error if the entire request > yields an empty node-set. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 06:02:08 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8064D3A6B3E; Tue, 27 Jan 2009 06:02:08 -0800 (PST) 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 AEDE93A6AA3 for ; Tue, 27 Jan 2009 06:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Qz+OdOEsb2Wl for ; Tue, 27 Jan 2009 06:02:07 -0800 (PST) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4FC7128C198 for ; Tue, 27 Jan 2009 06:01:12 -0800 (PST) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id E098076C229; Tue, 27 Jan 2009 15:00:52 +0100 (CET) Date: Tue, 27 Jan 2009 15:00:52 +0100 (CET) Message-Id: <20090127.150052.30926042.mbj@tail-f.com> To: andy@netconfcentral.com From: Martin Bjorklund In-Reply-To: <497F073F.7070704@netconfcentral.com> References: <497F073F.7070704@netconfcentral.com> X-Mailer: Mew version 6.0.51 on Emacs 22.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > the draft says that an error will be returned > if any select parameter is not a node-set. > This is good. It also says that it is an error > if a select parameter is an empty node set. > > IMO, it should only be an error if the entire request > yields an empty node-set. I agree. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 15:54:24 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C3E3A6AB4; Tue, 27 Jan 2009 15:54:24 -0800 (PST) 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 D4B4E3A6AB4 for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 Bm-7Ka9NVlgU for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) 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 3FD833A69EF for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) Received: (qmail 37337 invoked from network); 27 Jan 2009 23:54:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.231 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 23:54:03 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F9E9A.5040906@netconfcentral.com> Date: Tue, 27 Jan 2009 15:54:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> In-Reply-To: <20090127.150052.30926042.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> the draft says that an error will be returned >> if any select parameter is not a node-set. >> This is good. It also says that it is an error >> if a select parameter is an empty node set. >> >> IMO, it should only be an error if the entire request >> yields an empty node-set. > > I agree. > OK. Can you also add a comment to stress that config=false nodes are not part of the database. I know 1 sentence says it, but maybe an example that shows select(/a | /counter | /bogus) or something like it to stress that read-only and non-existent nodes are not errors. They just don't contribute to the result node-set. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Jan 27 15:54:24 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C3E3A6AB4; Tue, 27 Jan 2009 15:54:24 -0800 (PST) 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 D4B4E3A6AB4 for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.260, 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 Bm-7Ka9NVlgU for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) 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 3FD833A69EF for ; Tue, 27 Jan 2009 15:54:23 -0800 (PST) Received: (qmail 37337 invoked from network); 27 Jan 2009 23:54:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.126.140.231 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 27 Jan 2009 23:54:03 -0000 X-Yahoo-Newman-Property: ymail-3 Message-ID: <497F9E9A.5040906@netconfcentral.com> Date: Tue, 27 Jan 2009 15:54:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Martin Bjorklund References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> In-Reply-To: <20090127.150052.30926042.mbj@tail-f.com> Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Hi, >> >> the draft says that an error will be returned >> if any select parameter is not a node-set. >> This is good. It also says that it is an error >> if a select parameter is an empty node set. >> >> IMO, it should only be an error if the entire request >> yields an empty node-set. > > I agree. > OK. Can you also add a comment to stress that config=false nodes are not part of the database. I know 1 sentence says it, but maybe an example that shows select(/a | /counter | /bogus) or something like it to stress that read-only and non-existent nodes are not errors. They just don't contribute to the result node-set. > > /martin > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 29 10:19:48 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D7528C230; Thu, 29 Jan 2009 10:19:48 -0800 (PST) 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 8B06628C21A for ; Thu, 29 Jan 2009 10:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 dxjH9BR4l1A9 for ; Thu, 29 Jan 2009 10:19:46 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C43B328C185 for ; Thu, 29 Jan 2009 10:19:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,345,1231131600"; d="scan'208";a="159462668" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 29 Jan 2009 13:19:28 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jan 2009 13:19:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jan 2009 19:19:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering approved thread-index: AcmCPhIklLuBaurSTZC/bMZo8ue0+w== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] Rechartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org The IESG approved in the telechat today the rechartering of NETCONF. Thanks for working on this and good luck on executing it. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Jan 29 10:19:48 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D7528C230; Thu, 29 Jan 2009 10:19:48 -0800 (PST) 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 8B06628C21A for ; Thu, 29 Jan 2009 10:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 dxjH9BR4l1A9 for ; Thu, 29 Jan 2009 10:19:46 -0800 (PST) Received: from co300216-co-outbound.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C43B328C185 for ; Thu, 29 Jan 2009 10:19:46 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,345,1231131600"; d="scan'208";a="159462668" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 29 Jan 2009 13:19:28 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 Jan 2009 13:19:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 29 Jan 2009 19:19:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rechartering approved thread-index: AcmCPhIklLuBaurSTZC/bMZo8ue0+w== From: "Romascanu, Dan (Dan)" To: Subject: [Netconf] Rechartering 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org The IESG approved in the telechat today the rechartering of NETCONF. Thanks for working on this and good luck on executing it. Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 05:29:14 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949333A6B70; Fri, 30 Jan 2009 05:29:14 -0800 (PST) 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 896C73A6B79 for ; Fri, 30 Jan 2009 05:29:12 -0800 (PST) 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 Nl8EaLy5qbe7 for ; Fri, 30 Jan 2009 05:29:11 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id C04523A6B68 for ; Fri, 30 Jan 2009 05:29:10 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id 2FBCF51B6092 for ; Fri, 30 Jan 2009 14:28:51 +0100 (CET) Message-ID: <49830095.9030804@edgeware.tv> Date: Fri, 30 Jan 2009 14:28:53 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: netconf@ietf.org Subject: [Netconf] access control: current implementations 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Could you out there who have your own agent implementations describe your access control mechanism, and how it maps to different NETCONF operations? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 05:29:14 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949333A6B70; Fri, 30 Jan 2009 05:29:14 -0800 (PST) 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 896C73A6B79 for ; Fri, 30 Jan 2009 05:29:12 -0800 (PST) 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 Nl8EaLy5qbe7 for ; Fri, 30 Jan 2009 05:29:11 -0800 (PST) Received: from mail.edgeware.tv (mail.edgeware.tv [82.99.7.138]) by core3.amsl.com (Postfix) with ESMTP id C04523A6B68 for ; Fri, 30 Jan 2009 05:29:10 -0800 (PST) Received: from [192.168.99.223] (unknown [192.168.99.223]) by mail.edgeware.tv (Postfix) with ESMTPSA id 2FBCF51B6092 for ; Fri, 30 Jan 2009 14:28:51 +0100 (CET) Message-ID: <49830095.9030804@edgeware.tv> Date: Fri, 30 Jan 2009 14:28:53 +0100 From: Johan Rydberg User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: netconf@ietf.org Subject: [Netconf] access control: current implementations 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Could you out there who have your own agent implementations describe your access control mechanism, and how it maps to different NETCONF operations? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:28:37 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027A83A6B41; Fri, 30 Jan 2009 08:28:37 -0800 (PST) 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 0DFC03A6B41 for ; Fri, 30 Jan 2009 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, 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 fbiWJ1EW3FO4 for ; Fri, 30 Jan 2009 08:28:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EBA393A6ABB for ; Fri, 30 Jan 2009 08:28:34 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84BD820429; Fri, 30 Jan 2009 17:28:15 +0100 (CET) X-AuditID: c1b4fb3c-aa757bb00000304c-4f-49832a9f9415 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 656702041B; Fri, 30 Jan 2009 17:28:15 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:13 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:13 +0100 Message-ID: <49832A9C.7080001@ericsson.com> Date: Fri, 30 Jan 2009 17:28:12 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> <497F9E9A.5040906@netconfcentral.com> In-Reply-To: <497F9E9A.5040906@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:28:13.0418 (UTC) FILETIME=[BF4394A0:01C982F7] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> the draft says that an error will be returned >>> if any select parameter is not a node-set. >>> This is good. It also says that it is an error >>> if a select parameter is an empty node set. >>> >>> IMO, it should only be an error if the entire request >>> yields an empty node-set. >> >> I agree. >> > > OK. Can you also add a comment to stress that config=false > nodes are not part of the database. BALAZS: OK, will do _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:28:37 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027A83A6B41; Fri, 30 Jan 2009 08:28:37 -0800 (PST) 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 0DFC03A6B41 for ; Fri, 30 Jan 2009 08:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.833 X-Spam-Level: X-Spam-Status: No, score=-5.833 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, 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 fbiWJ1EW3FO4 for ; Fri, 30 Jan 2009 08:28:35 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id EBA393A6ABB for ; Fri, 30 Jan 2009 08:28:34 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 84BD820429; Fri, 30 Jan 2009 17:28:15 +0100 (CET) X-AuditID: c1b4fb3c-aa757bb00000304c-4f-49832a9f9415 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 656702041B; Fri, 30 Jan 2009 17:28:15 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:13 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:13 +0100 Message-ID: <49832A9C.7080001@ericsson.com> Date: Fri, 30 Jan 2009 17:28:12 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> <497F9E9A.5040906@netconfcentral.com> In-Reply-To: <497F9E9A.5040906@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:28:13.0418 (UTC) FILETIME=[BF4394A0:01C982F7] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Martin Bjorklund wrote: >> Andy Bierman wrote: >>> Hi, >>> >>> the draft says that an error will be returned >>> if any select parameter is not a node-set. >>> This is good. It also says that it is an error >>> if a select parameter is an empty node set. >>> >>> IMO, it should only be an error if the entire request >>> yields an empty node-set. >> >> I agree. >> > > OK. Can you also add a comment to stress that config=false > nodes are not part of the database. BALAZS: OK, will do _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:29:16 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED673A6B41; Fri, 30 Jan 2009 08:29:16 -0800 (PST) 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 F175F3A6B41 for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 xJJefibFk8GB for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2E9B73A6B3E for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE8752041B; Fri, 30 Jan 2009 17:28:54 +0100 (CET) X-AuditID: c1b4fb3c-ab759bb00000304c-96-49832ac6795d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CA1CF2024D; Fri, 30 Jan 2009 17:28:54 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:54 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:53 +0100 Message-ID: <49832AC5.2060301@ericsson.com> Date: Fri, 30 Jan 2009 17:28:53 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <497F073F.7070704@netconfcentral.com> In-Reply-To: <497F073F.7070704@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:28:53.0835 (UTC) FILETIME=[D75AB9B0:01C982F7] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Andy Bierman wrote: > Hi, > > the draft says that an error will be returned > if any select parameter is not a node-set. > This is good. It also says that it is an error > if a select parameter is an empty node set. > > IMO, it should only be an error if the entire request > yields an empty node-set. BALAZS: The drafts already says what you are asking for: "If all the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'." The word "all" is included. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:29:16 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED673A6B41; Fri, 30 Jan 2009 08:29:16 -0800 (PST) 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 F175F3A6B41 for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 xJJefibFk8GB for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 2E9B73A6B3E for ; Fri, 30 Jan 2009 08:29:14 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DE8752041B; Fri, 30 Jan 2009 17:28:54 +0100 (CET) X-AuditID: c1b4fb3c-ab759bb00000304c-96-49832ac6795d Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CA1CF2024D; Fri, 30 Jan 2009 17:28:54 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:54 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:28:53 +0100 Message-ID: <49832AC5.2060301@ericsson.com> Date: Fri, 30 Jan 2009 17:28:53 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <497F073F.7070704@netconfcentral.com> In-Reply-To: <497F073F.7070704@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:28:53.0835 (UTC) FILETIME=[D75AB9B0:01C982F7] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello, Andy Bierman wrote: > Hi, > > the draft says that an error will be returned > if any select parameter is not a node-set. > This is good. It also says that it is an error > if a select parameter is an empty node set. > > IMO, it should only be an error if the entire request > yields an empty node-set. BALAZS: The drafts already says what you are asking for: "If all the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'." The word "all" is included. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:32:26 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793C828C10B; Fri, 30 Jan 2009 08:32:26 -0800 (PST) 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 AB26428C0E7 for ; Fri, 30 Jan 2009 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0py5gdOvGAKy for ; Fri, 30 Jan 2009 08:32:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 25F093A6B93 for ; Fri, 30 Jan 2009 08:32:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA15920FCB; Fri, 30 Jan 2009 17:32:03 +0100 (CET) X-AuditID: c1b4fb3e-ae86fbb00000429e-79-49832b836364 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 89F87210AA; Fri, 30 Jan 2009 17:32:03 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:32:03 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:32:03 +0100 Message-ID: <49832B82.2030002@ericsson.com> Date: Fri, 30 Jan 2009 17:32:02 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> <20090127105223.GB12610@elstar.local> <497F0205.5020108@netconfcentral.com> In-Reply-To: <497F0205.5020108@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:32:03.0098 (UTC) FILETIME=[4829F7A0:01C982F8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Andy, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: >> >>> To minimize the time all users are locked, you can do: >>> >>> lock users --> ok >>> create joe --> ok >>> lock joe --> ok >>> unlock users --> ok >>> >>> unlock joe --> ok >>> >>> This is what Balazs' example shows. >> >> But this requires to spell out in detail under which conditions you >> can lock something that is already locked. >> > > I agree the details must be in normative text. > BALAZS: I also agree, but IMO all this is covered in the normative text. What I propose is just an example not more. What is missing from the text? > I really do not like this precedent, especially > since the eventual access control model might attempt > to be compatible with partial locking. > > IMO, the main idea is broken -- that a lock on '/top/users' > does not mean all the nodes under /top/users are locked. > Instead it means that the lock holder can keep > locking nodes under /top/users. > > This is different than a global lock. A 2nd call to lock, > even by the lock-holder, is considered an application error, > and the lock request is rejected. BALAZS: Other people had earlier explicitly requested to allow the 2nd lock (and the way global locking works is actually not changed.) - It gives you a way to safely reduce the scope of your lock - it also allows a management application to lock user-joe without considering whether allUsers is already locked. Changing this behavior > for partial-lock is inconsistent. It would be better > to treat this an an application error as well. > If any node in the path from root to the selected node > is already locked, then the new lock request MUST fail. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:32:26 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793C828C10B; Fri, 30 Jan 2009 08:32:26 -0800 (PST) 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 AB26428C0E7 for ; Fri, 30 Jan 2009 08:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.13 X-Spam-Level: X-Spam-Status: No, score=-6.13 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 0py5gdOvGAKy for ; Fri, 30 Jan 2009 08:32:24 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 25F093A6B93 for ; Fri, 30 Jan 2009 08:32:23 -0800 (PST) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AA15920FCB; Fri, 30 Jan 2009 17:32:03 +0100 (CET) X-AuditID: c1b4fb3e-ae86fbb00000429e-79-49832b836364 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 89F87210AA; Fri, 30 Jan 2009 17:32:03 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:32:03 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:32:03 +0100 Message-ID: <49832B82.2030002@ericsson.com> Date: Fri, 30 Jan 2009 17:32:02 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <20090126.212108.102560980.mbj@tail-f.com> <497E2128.8060408@netconfcentral.com> <20090127083630.GA12355@elstar.local> <20090127.104200.164214226.mbj@tail-f.com> <20090127105223.GB12610@elstar.local> <497F0205.5020108@netconfcentral.com> In-Reply-To: <497F0205.5020108@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 16:32:03.0098 (UTC) FILETIME=[4829F7A0:01C982F8] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hello Andy, Andy Bierman wrote: > Juergen Schoenwaelder wrote: >> On Tue, Jan 27, 2009 at 10:42:00AM +0100, Martin Bjorklund wrote: >> >>> To minimize the time all users are locked, you can do: >>> >>> lock users --> ok >>> create joe --> ok >>> lock joe --> ok >>> unlock users --> ok >>> >>> unlock joe --> ok >>> >>> This is what Balazs' example shows. >> >> But this requires to spell out in detail under which conditions you >> can lock something that is already locked. >> > > I agree the details must be in normative text. > BALAZS: I also agree, but IMO all this is covered in the normative text. What I propose is just an example not more. What is missing from the text? > I really do not like this precedent, especially > since the eventual access control model might attempt > to be compatible with partial locking. > > IMO, the main idea is broken -- that a lock on '/top/users' > does not mean all the nodes under /top/users are locked. > Instead it means that the lock holder can keep > locking nodes under /top/users. > > This is different than a global lock. A 2nd call to lock, > even by the lock-holder, is considered an application error, > and the lock request is rejected. BALAZS: Other people had earlier explicitly requested to allow the 2nd lock (and the way global locking works is actually not changed.) - It gives you a way to safely reduce the scope of your lock - it also allows a management application to lock user-joe without considering whether allUsers is already locked. Changing this behavior > for partial-lock is inconsistent. It would be better > to treat this an an application error as well. > If any node in the path from root to the selected node > is already locked, then the new lock request MUST fail. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:41:35 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB3C3A6B21; Fri, 30 Jan 2009 08:41:35 -0800 (PST) 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 D06AC28C2AF for ; Fri, 30 Jan 2009 08:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 H0JdvjKnMNcR for ; Fri, 30 Jan 2009 08:41:30 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9EEE53A68B9 for ; Fri, 30 Jan 2009 08:41:30 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4048520006; Fri, 30 Jan 2009 17:41:11 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-2c-49832da6e8d7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3FF02046F; Fri, 30 Jan 2009 17:41:10 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:41:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:41:10 +0100 Message-ID: <49832DA5.5070101@ericsson.com> Date: Fri, 30 Jan 2009 17:41:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> In-Reply-To: <20090126170051.GA12088@elstar.local> X-OriginalArrivalTime: 30 Jan 2009 16:41:10.0240 (UTC) FILETIME=[8E493600:01C982F9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: > >> If I would put the following example in an appendix and reference it >> from 2.4.1.2 would that be OK? > >> What do you think of the example below? >> regards Balazs >> >> ================================================= >> >> As an example, lets say we have the data model >> >> container allUsers { >> list users { >> key name { type string; } >> ... other data ... >> } >> } >> > > I would phrase the example by just showing the instance document to > avoid any data modelling language issues. And it might be good to be > consistent with the examples used in RFC 4741. BALAZS: OK > > > What I do not understand is that on the one hand the lock on allUsers > is claimed to protect everything below allUsers but then you can > acquire a lock on Joe even though I thought it is locked. BALAZS: from the draft: "When a NETCONF session holds a lock on a node, no other session or non-NETCONF mechanism of the system can change that node or any node in the hierarchy of nodes beneath it." By locking a node you don't actually change it, so this feature does not block that. later from the draft: "A partial lock operation MUST fail if: o Any part of the area to be protected is already locked (or protected by partial locking) by another management session, including other NETCONF sessions using or any other non-NETCONF management method." It states that a partial lock only blocks another partial lock if it executed "by another management session". > I am missing > a clear explanation what a lock on a leaf implies and what a lock on a > contained implies. Perhaps the idea is to say that a lock on a > container locks the container for additions/removals but you wrote the > lock on allUsers "protect all nodes under allUsers from modification" > and this is where I am getting confused about the partial lock > semantics. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:41:35 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB3C3A6B21; Fri, 30 Jan 2009 08:41:35 -0800 (PST) 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 D06AC28C2AF for ; Fri, 30 Jan 2009 08:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 H0JdvjKnMNcR for ; Fri, 30 Jan 2009 08:41:30 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9EEE53A68B9 for ; Fri, 30 Jan 2009 08:41:30 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4048520006; Fri, 30 Jan 2009 17:41:11 +0100 (CET) X-AuditID: c1b4fb3c-ae75fbb00000304c-2c-49832da6e8d7 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E3FF02046F; Fri, 30 Jan 2009 17:41:10 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:41:10 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 17:41:10 +0100 Message-ID: <49832DA5.5070101@ericsson.com> Date: Fri, 30 Jan 2009 17:41:09 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> In-Reply-To: <20090126170051.GA12088@elstar.local> X-OriginalArrivalTime: 30 Jan 2009 16:41:10.0240 (UTC) FILETIME=[8E493600:01C982F9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder wrote: > On Mon, Jan 26, 2009 at 04:15:38PM +0100, Balazs Lengyel wrote: > >> If I would put the following example in an appendix and reference it >> from 2.4.1.2 would that be OK? > >> What do you think of the example below? >> regards Balazs >> >> ================================================= >> >> As an example, lets say we have the data model >> >> container allUsers { >> list users { >> key name { type string; } >> ... other data ... >> } >> } >> > > I would phrase the example by just showing the instance document to > avoid any data modelling language issues. And it might be good to be > consistent with the examples used in RFC 4741. BALAZS: OK > > > What I do not understand is that on the one hand the lock on allUsers > is claimed to protect everything below allUsers but then you can > acquire a lock on Joe even though I thought it is locked. BALAZS: from the draft: "When a NETCONF session holds a lock on a node, no other session or non-NETCONF mechanism of the system can change that node or any node in the hierarchy of nodes beneath it." By locking a node you don't actually change it, so this feature does not block that. later from the draft: "A partial lock operation MUST fail if: o Any part of the area to be protected is already locked (or protected by partial locking) by another management session, including other NETCONF sessions using or any other non-NETCONF management method." It states that a partial lock only blocks another partial lock if it executed "by another management session". > I am missing > a clear explanation what a lock on a leaf implies and what a lock on a > contained implies. Perhaps the idea is to say that a lock on a > container locks the container for additions/removals but you wrote the > lock on allUsers "protect all nodes under allUsers from modification" > and this is where I am getting confused about the partial lock > semantics. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:44:48 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E64E28C2BB; Fri, 30 Jan 2009 08:44:48 -0800 (PST) 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 863A228C10B for ; Fri, 30 Jan 2009 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, 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 8zoH2eqzfW02 for ; Fri, 30 Jan 2009 08:44:46 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id DC46328C2BA for ; Fri, 30 Jan 2009 08:44:46 -0800 (PST) Received: (qmail 31170 invoked from network); 30 Jan 2009 16:44:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 16:44:27 -0000 X-YMail-OSG: dLzyt1sVM1ndVMoijMmXmI1NIp5eDCdeIwHwTONdJkNpGDLZtu5R3lfQ0kSPChaE.I83C0__kX_vBamXkzcTm68ApSEYk6IfsiQ9rTe1PC38.qnZJCkTK3WKlij8titIXp3yadRZDgdnDQk.kP_ufLsj X-Yahoo-Newman-Property: ymail-3 Message-ID: <49832E6A.30604@netconfcentral.com> Date: Fri, 30 Jan 2009 08:44:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, from 2.4.1.1 Note that if some of the requested nodes exist only in some of the targeted datastores, the lock is granted on different nodes in different datastores. This does not seem right to me. 1) do the locked nodes returned in the reply indicate which database the node is from? How does the manager know what was locked in each database? 2) At a minimum, the partial-lock should completely fail if the exact same lock cannot be issued across all requested databases. 3) Since the WG is unwilling to discuss any ill effects from full XPath due to implementation-specific results, IMO, locking multiple databases at-once seems too error-prone, and should be removed. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 08:44:48 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E64E28C2BB; Fri, 30 Jan 2009 08:44:48 -0800 (PST) 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 863A228C10B for ; Fri, 30 Jan 2009 08:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.063, 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 8zoH2eqzfW02 for ; Fri, 30 Jan 2009 08:44:46 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id DC46328C2BA for ; Fri, 30 Jan 2009 08:44:46 -0800 (PST) Received: (qmail 31170 invoked from network); 30 Jan 2009 16:44:28 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 16:44:27 -0000 X-YMail-OSG: dLzyt1sVM1ndVMoijMmXmI1NIp5eDCdeIwHwTONdJkNpGDLZtu5R3lfQ0kSPChaE.I83C0__kX_vBamXkzcTm68ApSEYk6IfsiQ9rTe1PC38.qnZJCkTK3WKlij8titIXp3yadRZDgdnDQk.kP_ufLsj X-Yahoo-Newman-Property: ymail-3 Message-ID: <49832E6A.30604@netconfcentral.com> Date: Fri, 30 Jan 2009 08:44:26 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF Subject: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, from 2.4.1.1 Note that if some of the requested nodes exist only in some of the targeted datastores, the lock is granted on different nodes in different datastores. This does not seem right to me. 1) do the locked nodes returned in the reply indicate which database the node is from? How does the manager know what was locked in each database? 2) At a minimum, the partial-lock should completely fail if the exact same lock cannot be issued across all requested databases. 3) Since the WG is unwilling to discuss any ill effects from full XPath due to implementation-specific results, IMO, locking multiple databases at-once seems too error-prone, and should be removed. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:13:04 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B423A6A53; Fri, 30 Jan 2009 09:13:04 -0800 (PST) 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 E0FC73A6AB5 for ; Fri, 30 Jan 2009 09:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, 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 NSOyKmIf1vSx for ; Fri, 30 Jan 2009 09:13:02 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 349E83A6965 for ; Fri, 30 Jan 2009 09:13:02 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0597C20CE6; Fri, 30 Jan 2009 18:12:08 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-6b-498334e7f08b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E119320895; Fri, 30 Jan 2009 18:12:07 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:12:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:12:07 +0100 Message-ID: <498334E7.1000604@ericsson.com> Date: Fri, 30 Jan 2009 18:12:07 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> <497F9E9A.5040906@netconfcentral.com> <49832A9C.7080001@ericsson.com> In-Reply-To: <49832A9C.7080001@ericsson.com> X-OriginalArrivalTime: 30 Jan 2009 17:12:07.0780 (UTC) FILETIME=[E1775240:01C982FD] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> the draft says that an error will be returned >>>> if any select parameter is not a node-set. >>>> This is good. It also says that it is an error >>>> if a select parameter is an empty node set. >>>> >>>> IMO, it should only be an error if the entire request >>>> yields an empty node-set. >>> >>> I agree. >>> >> >> OK. Can you also add a comment to stress that config=false >> nodes are not part of the database. > > BALAZS: OK, will do > On second reading I found this sentence in the draft: "Partial locking only affects configuration data." So I assume that addresses your concern. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:13:04 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63B423A6A53; Fri, 30 Jan 2009 09:13:04 -0800 (PST) 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 E0FC73A6AB5 for ; Fri, 30 Jan 2009 09:13:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_65=0.6, 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 NSOyKmIf1vSx for ; Fri, 30 Jan 2009 09:13:02 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 349E83A6965 for ; Fri, 30 Jan 2009 09:13:02 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 0597C20CE6; Fri, 30 Jan 2009 18:12:08 +0100 (CET) X-AuditID: c1b4fb3c-aef60bb00000304c-6b-498334e7f08b Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E119320895; Fri, 30 Jan 2009 18:12:07 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:12:07 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:12:07 +0100 Message-ID: <498334E7.1000604@ericsson.com> Date: Fri, 30 Jan 2009 18:12:07 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Balazs Lengyel References: <497F073F.7070704@netconfcentral.com> <20090127.150052.30926042.mbj@tail-f.com> <497F9E9A.5040906@netconfcentral.com> <49832A9C.7080001@ericsson.com> In-Reply-To: <49832A9C.7080001@ericsson.com> X-OriginalArrivalTime: 30 Jan 2009 17:12:07.0780 (UTC) FILETIME=[E1775240:01C982FD] X-Brightmail-Tracker: AAAAAA== Cc: netconf@ietf.org Subject: Re: [Netconf] partial lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Martin Bjorklund wrote: >>> Andy Bierman wrote: >>>> Hi, >>>> >>>> the draft says that an error will be returned >>>> if any select parameter is not a node-set. >>>> This is good. It also says that it is an error >>>> if a select parameter is an empty node set. >>>> >>>> IMO, it should only be an error if the entire request >>>> yields an empty node-set. >>> >>> I agree. >>> >> >> OK. Can you also add a comment to stress that config=false >> nodes are not part of the database. > > BALAZS: OK, will do > On second reading I found this sentence in the draft: "Partial locking only affects configuration data." So I assume that addresses your concern. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:23:07 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E213A3A6A09; Fri, 30 Jan 2009 09:23:07 -0800 (PST) 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 5B3873A6A09 for ; Fri, 30 Jan 2009 09:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 WlWBBzhqdApV for ; Fri, 30 Jan 2009 09:23:06 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 438B43A6965 for ; Fri, 30 Jan 2009 09:23:06 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B232E20D14; Fri, 30 Jan 2009 18:22:46 +0100 (CET) X-AuditID: c1b4fb3c-aaf58bb00000304c-ee-49833766c0ec Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8AA7320C69; Fri, 30 Jan 2009 18:22:46 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:22:43 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:22:43 +0100 Message-ID: <49833762.7030708@ericsson.com> Date: Fri, 30 Jan 2009 18:22:42 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49832E6A.30604@netconfcentral.com> In-Reply-To: <49832E6A.30604@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 17:22:43.0522 (UTC) FILETIME=[5C65DA20:01C982FF] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > from 2.4.1.1 > > > Note that if some of the requested nodes exist only in some of > the targeted datastores, the lock is granted on different nodes > in different datastores. > > > This does not seem right to me. > > 1) do the locked nodes returned in the reply indicate > which database the node is from? How does the > manager know what was locked in each database? BALAZS: from the draft: "A list of locked nodes per datastore is also returned in Instance Identifier format." So the answer is yes it is indicated, and the returned list tells the manager exactly what is locked. This is also indicated in the relevant YANG model. > > 3) Since the WG is unwilling to discuss any ill effects > from full XPath due to implementation-specific results, > IMO, locking multiple databases at-once seems too error-prone, > and should be removed. BALAZS: If you lock multiple datastores in separate requests, you increase the possibility of dead-locks. What specific dangers do you see? Multiple people have explicitly requested locking multiple datastores. The relevant encoding was discussed on the last IETF and no one objected there. Also I would like to avoid solving all Netconf-XPath related issues in the partial-lock draft, I would prefer to deal only with locking related stuff. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:23:07 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E213A3A6A09; Fri, 30 Jan 2009 09:23:07 -0800 (PST) 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 5B3873A6A09 for ; Fri, 30 Jan 2009 09:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 WlWBBzhqdApV for ; Fri, 30 Jan 2009 09:23:06 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 438B43A6965 for ; Fri, 30 Jan 2009 09:23:06 -0800 (PST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B232E20D14; Fri, 30 Jan 2009 18:22:46 +0100 (CET) X-AuditID: c1b4fb3c-aaf58bb00000304c-ee-49833766c0ec Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 8AA7320C69; Fri, 30 Jan 2009 18:22:46 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:22:43 +0100 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jan 2009 18:22:43 +0100 Message-ID: <49833762.7030708@ericsson.com> Date: Fri, 30 Jan 2009 18:22:42 +0100 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Andy Bierman References: <49832E6A.30604@netconfcentral.com> In-Reply-To: <49832E6A.30604@netconfcentral.com> X-OriginalArrivalTime: 30 Jan 2009 17:22:43.0522 (UTC) FILETIME=[5C65DA20:01C982FF] X-Brightmail-Tracker: AAAAAA== Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Andy Bierman wrote: > Hi, > > from 2.4.1.1 > > > Note that if some of the requested nodes exist only in some of > the targeted datastores, the lock is granted on different nodes > in different datastores. > > > This does not seem right to me. > > 1) do the locked nodes returned in the reply indicate > which database the node is from? How does the > manager know what was locked in each database? BALAZS: from the draft: "A list of locked nodes per datastore is also returned in Instance Identifier format." So the answer is yes it is indicated, and the returned list tells the manager exactly what is locked. This is also indicated in the relevant YANG model. > > 3) Since the WG is unwilling to discuss any ill effects > from full XPath due to implementation-specific results, > IMO, locking multiple databases at-once seems too error-prone, > and should be removed. BALAZS: If you lock multiple datastores in separate requests, you increase the possibility of dead-locks. What specific dangers do you see? Multiple people have explicitly requested locking multiple datastores. The relevant encoding was discussed on the last IETF and no one objected there. Also I would like to avoid solving all Netconf-XPath related issues in the partial-lock draft, I would prefer to deal only with locking related stuff. Balazs _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:54:26 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9256128C2CE; Fri, 30 Jan 2009 09:54:26 -0800 (PST) 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 6709E28C2CE for ; Fri, 30 Jan 2009 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, 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 suOXXi5PVNMm for ; Fri, 30 Jan 2009 09:54:24 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 929F428C2C9 for ; Fri, 30 Jan 2009 09:54:24 -0800 (PST) Received: (qmail 9055 invoked from network); 30 Jan 2009 17:54:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 17:54:04 -0000 X-YMail-OSG: 18rNskUVM1n989Yls5s2knVppjJgGsHdtjUkQ9WVgm9jDk2EnN4hnEocbVA78V2Ud2QBhHcJ6mU3OpZjxuxKEL6f4kTT65I7RS0P9gWkhvkvZ2He4b8YPxM2iTne613.7CsdHHXPRTxBjsO6ryWkAp8uenVfnaCNdab7ne1Oe.fvSWW5cJWYmMi4DSoO X-Yahoo-Newman-Property: ymail-3 Message-ID: <49833EBB.2070107@netconfcentral.com> Date: Fri, 30 Jan 2009 09:54:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <49832E6A.30604@netconfcentral.com> <49833762.7030708@ericsson.com> In-Reply-To: <49833762.7030708@ericsson.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Hi, >> >> from 2.4.1.1 >> >> >> Note that if some of the requested nodes exist only in some of >> the targeted datastores, the lock is granted on different nodes >> in different datastores. >> >> >> This does not seem right to me. >> >> 1) do the locked nodes returned in the reply indicate >> which database the node is from? How does the >> manager know what was locked in each database? > > BALAZS: from the draft: > "A list of locked nodes per datastore is also returned in Instance > Identifier format." > > So the answer is yes it is indicated, and the returned list tells the > manager exactly what is locked. This is also indicated in the relevant > YANG model. > OK, but... My first concern is that full XPath relies heavily on the 'XML document order' concept and related mechanisms. IMO, a NETCONF database has no set document order. It is implementation-specific. It is not even useful, since every node in the database has a unique identifier. The order the user picks in the config may not stay in that order internally. So any expression involving XML document order is problematic. What if the last entry in is not the same as in ? This is not even implementation-dependent. What if the user adds new stuff to , so the 2 databases are out of sync? 127 /rte:routing/rte:virtualRouter[rte:routerName='router2'] /rte:routing/rte:virtualRouter[rte:routerName='router1'] Even though the reply indicates that different entries were locked, I do not think the draft does a good job documenting the issues with XPath and NETCONF. I don't really care where the problem gets punted, but just ignoring it seems like poor standards practice. >> >> 3) Since the WG is unwilling to discuss any ill effects >> from full XPath due to implementation-specific results, >> IMO, locking multiple databases at-once seems too error-prone, >> and should be removed. > > BALAZS: If you lock multiple datastores in separate requests, you > increase the possibility of dead-locks. What specific dangers do you see? > > Multiple people have explicitly requested locking multiple datastores. > The relevant encoding was discussed on the last IETF and no one objected > there. > > Also I would like to avoid solving all Netconf-XPath related issues in > the partial-lock draft, I would prefer to deal only with locking related > stuff. > Yet the draft allows full XPath, without really providing any guidance on what that means. Such under-specification cannot adequately promote multi-vendor interoperability. > Balazs > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 09:54:26 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9256128C2CE; Fri, 30 Jan 2009 09:54:26 -0800 (PST) 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 6709E28C2CE for ; Fri, 30 Jan 2009 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.062, 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 suOXXi5PVNMm for ; Fri, 30 Jan 2009 09:54:24 -0800 (PST) Received: from smtp115.sbc.mail.sp1.yahoo.com (smtp115.sbc.mail.sp1.yahoo.com [69.147.64.88]) by core3.amsl.com (Postfix) with SMTP id 929F428C2C9 for ; Fri, 30 Jan 2009 09:54:24 -0800 (PST) Received: (qmail 9055 invoked from network); 30 Jan 2009 17:54:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 17:54:04 -0000 X-YMail-OSG: 18rNskUVM1n989Yls5s2knVppjJgGsHdtjUkQ9WVgm9jDk2EnN4hnEocbVA78V2Ud2QBhHcJ6mU3OpZjxuxKEL6f4kTT65I7RS0P9gWkhvkvZ2He4b8YPxM2iTne613.7CsdHHXPRTxBjsO6ryWkAp8uenVfnaCNdab7ne1Oe.fvSWW5cJWYmMi4DSoO X-Yahoo-Newman-Property: ymail-3 Message-ID: <49833EBB.2070107@netconfcentral.com> Date: Fri, 30 Jan 2009 09:54:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <49832E6A.30604@netconfcentral.com> <49833762.7030708@ericsson.com> In-Reply-To: <49833762.7030708@ericsson.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > > Andy Bierman wrote: >> Hi, >> >> from 2.4.1.1 >> >> >> Note that if some of the requested nodes exist only in some of >> the targeted datastores, the lock is granted on different nodes >> in different datastores. >> >> >> This does not seem right to me. >> >> 1) do the locked nodes returned in the reply indicate >> which database the node is from? How does the >> manager know what was locked in each database? > > BALAZS: from the draft: > "A list of locked nodes per datastore is also returned in Instance > Identifier format." > > So the answer is yes it is indicated, and the returned list tells the > manager exactly what is locked. This is also indicated in the relevant > YANG model. > OK, but... My first concern is that full XPath relies heavily on the 'XML document order' concept and related mechanisms. IMO, a NETCONF database has no set document order. It is implementation-specific. It is not even useful, since every node in the database has a unique identifier. The order the user picks in the config may not stay in that order internally. So any expression involving XML document order is problematic. What if the last entry in is not the same as in ? This is not even implementation-dependent. What if the user adds new stuff to , so the 2 databases are out of sync? 127 /rte:routing/rte:virtualRouter[rte:routerName='router2'] /rte:routing/rte:virtualRouter[rte:routerName='router1'] Even though the reply indicates that different entries were locked, I do not think the draft does a good job documenting the issues with XPath and NETCONF. I don't really care where the problem gets punted, but just ignoring it seems like poor standards practice. >> >> 3) Since the WG is unwilling to discuss any ill effects >> from full XPath due to implementation-specific results, >> IMO, locking multiple databases at-once seems too error-prone, >> and should be removed. > > BALAZS: If you lock multiple datastores in separate requests, you > increase the possibility of dead-locks. What specific dangers do you see? > > Multiple people have explicitly requested locking multiple datastores. > The relevant encoding was discussed on the last IETF and no one objected > there. > > Also I would like to avoid solving all Netconf-XPath related issues in > the partial-lock draft, I would prefer to deal only with locking related > stuff. > Yet the draft allows full XPath, without really providing any guidance on what that means. Such under-specification cannot adequately promote multi-vendor interoperability. > Balazs > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 10:11:30 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4463A28C145; Fri, 30 Jan 2009 10:11:30 -0800 (PST) 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 179CC28C145 for ; Fri, 30 Jan 2009 10:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.061, 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 f0OdSSAhrpML for ; Fri, 30 Jan 2009 10:11:25 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 873A428C137 for ; Fri, 30 Jan 2009 10:11:25 -0800 (PST) Received: (qmail 71783 invoked from network); 30 Jan 2009 18:11:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 18:11:04 -0000 X-YMail-OSG: f8rC.FUVM1nar1k6KcO8hc7vgU.GJrA4fbzgCABMI3m7KGSp0HFLR8ktCHt2eLjKbyo0frw5.iEjh2RUvBcnlVLyNF_AbxV4pjRWgibg7aOhWla9utR5toGEWng7YcUkDBCxdQhIa8P1H_jyt.K.W1WY X-Yahoo-Newman-Property: ymail-3 Message-ID: <498342B7.6050004@netconfcentral.com> Date: Fri, 30 Jan 2009 10:11:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <49832E6A.30604@netconfcentral.com> <49833762.7030708@ericsson.com> In-Reply-To: <49833762.7030708@ericsson.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > My 2nd concern with full XPath for partial-locking (and access-control) is that it is mandatory if the :xpath capability is supported. The :xpath capability was solely intended for the and operations when it was written. RFC 4741, 8.9.1.: The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the element. XPath is described in [2]. IMO, piling on more features to :xpath breaks this original contract. By overloading the :xpath capability, the WG is removing an important implementation choice by vendors. Just because my full XPath code is capable of producing a node-set result for any possible NETCONF/YANG construct, does not mean I WANT to use it for every possible NETCONF/YANG construct. IMO, full XPath for partial-locking is problematic, although some 'power' expressions are really useful. I think a vendor could easily decide it was better to stick with full XPath just for , just to avoid all the bug reports that full XPath might generate. But they can't, because partial-lock redefines what advertising the :xpath capability means. > Balazs > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 10:11:30 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4463A28C145; Fri, 30 Jan 2009 10:11:30 -0800 (PST) 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 179CC28C145 for ; Fri, 30 Jan 2009 10:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=0.061, 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 f0OdSSAhrpML for ; Fri, 30 Jan 2009 10:11:25 -0800 (PST) Received: from smtp120.sbc.mail.sp1.yahoo.com (smtp120.sbc.mail.sp1.yahoo.com [69.147.64.93]) by core3.amsl.com (Postfix) with SMTP id 873A428C137 for ; Fri, 30 Jan 2009 10:11:25 -0800 (PST) Received: (qmail 71783 invoked from network); 30 Jan 2009 18:11:06 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@68.120.231.114 with plain) by smtp120.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 18:11:04 -0000 X-YMail-OSG: f8rC.FUVM1nar1k6KcO8hc7vgU.GJrA4fbzgCABMI3m7KGSp0HFLR8ktCHt2eLjKbyo0frw5.iEjh2RUvBcnlVLyNF_AbxV4pjRWgibg7aOhWla9utR5toGEWng7YcUkDBCxdQhIa8P1H_jyt.K.W1WY X-Yahoo-Newman-Property: ymail-3 Message-ID: <498342B7.6050004@netconfcentral.com> Date: Fri, 30 Jan 2009 10:11:03 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Balazs Lengyel References: <49832E6A.30604@netconfcentral.com> <49833762.7030708@ericsson.com> In-Reply-To: <49833762.7030708@ericsson.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Balazs Lengyel wrote: > > My 2nd concern with full XPath for partial-locking (and access-control) is that it is mandatory if the :xpath capability is supported. The :xpath capability was solely intended for the and operations when it was written. RFC 4741, 8.9.1.: The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the element. XPath is described in [2]. IMO, piling on more features to :xpath breaks this original contract. By overloading the :xpath capability, the WG is removing an important implementation choice by vendors. Just because my full XPath code is capable of producing a node-set result for any possible NETCONF/YANG construct, does not mean I WANT to use it for every possible NETCONF/YANG construct. IMO, full XPath for partial-locking is problematic, although some 'power' expressions are really useful. I think a vendor could easily decide it was better to stick with full XPath just for , just to avoid all the bug reports that full XPath might generate. But they can't, because partial-lock redefines what advertising the :xpath capability means. > Balazs > > > Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 12:29:57 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37E93A6B63; Fri, 30 Jan 2009 12:29:57 -0800 (PST) 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 63E0B28C2CA for ; Fri, 30 Jan 2009 10:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 VYJ7mkFuNHC2 for ; Fri, 30 Jan 2009 10:37:23 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id BE6D028C2D1 for ; Fri, 30 Jan 2009 10:37:23 -0800 (PST) Received: (qmail 24251 invoked from network); 30 Jan 2009 18:37:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 18:37:03 -0000 X-YMail-OSG: icyBplcVM1kNH7WgmPb9lSR0yWEl6DD2o2wnRZrkgPcK4YaiH2Cl9_GYnYSiFA5r09KBfWYnBacGIVc8vcpg7jCXQZus867PhmYDbkeS_RtVpwZS7zSx6O_lJ3FdbL9zLVi3Vxv_yPJkxJ152.0rD2eK X-Yahoo-Newman-Property: ymail-3 Message-ID: <498348CE.9020301@andybierman.com> Date: Fri, 30 Jan 2009 10:37:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF X-Mailman-Approved-At: Fri, 30 Jan 2009 12:29:56 -0800 Subject: [Netconf] overlapping nodes within a lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I don't think the draft is clear on how nested nodes are handled. Full XPath is not even required: I'm not sure what it means to properly process this request. Is it OK if an implementation prunes overlapping nodes in the request? So the response (and internal lock) will look like this: /foo Since this is all part of 1 lock, it should be OK. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 12:29:57 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37E93A6B63; Fri, 30 Jan 2009 12:29:57 -0800 (PST) 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 63E0B28C2CA for ; Fri, 30 Jan 2009 10:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 VYJ7mkFuNHC2 for ; Fri, 30 Jan 2009 10:37:23 -0800 (PST) Received: from smtp122.sbc.mail.sp1.yahoo.com (smtp122.sbc.mail.sp1.yahoo.com [69.147.64.95]) by core3.amsl.com (Postfix) with SMTP id BE6D028C2D1 for ; Fri, 30 Jan 2009 10:37:23 -0800 (PST) Received: (qmail 24251 invoked from network); 30 Jan 2009 18:37:05 -0000 Received: from unknown (HELO ?127.0.0.1?) (andy@67.127.164.237 with plain) by smtp122.sbc.mail.sp1.yahoo.com with SMTP; 30 Jan 2009 18:37:03 -0000 X-YMail-OSG: icyBplcVM1kNH7WgmPb9lSR0yWEl6DD2o2wnRZrkgPcK4YaiH2Cl9_GYnYSiFA5r09KBfWYnBacGIVc8vcpg7jCXQZus867PhmYDbkeS_RtVpwZS7zSx6O_lJ3FdbL9zLVi3Vxv_yPJkxJ152.0rD2eK X-Yahoo-Newman-Property: ymail-3 Message-ID: <498348CE.9020301@andybierman.com> Date: Fri, 30 Jan 2009 10:37:02 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: NETCONF X-Mailman-Approved-At: Fri, 30 Jan 2009 12:29:56 -0800 Subject: [Netconf] overlapping nodes within a lock 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I don't think the draft is clear on how nested nodes are handled. Full XPath is not even required: I'm not sure what it means to properly process this request. Is it OK if an implementation prunes overlapping nodes in the request? So the response (and internal lock) will look like this: /foo Since this is all part of 1 lock, it should be OK. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Jan 30 15:39:50 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B4D3A6A05; Fri, 30 Jan 2009 15:39:50 -0800 (PST) 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 4A08E3A6A05 for ; Fri, 30 Jan 2009 15:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 8w+WD1w+oBMF for ; Fri, 30 Jan 2009 15:39:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 25DEB3A67A3 for ; Fri, 30 Jan 2009 15:39:44 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47E56C00F7; Sat, 31 Jan 2009 00:39:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kVvDBmwoHCdr; Sat, 31 Jan 2009 00:39:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33D2BC00A4; Sat, 31 Jan 2009 00:39:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03C5291E14A; Sat, 31 Jan 2009 00:39:13 +0100 (CET) Date: Sat, 31 Jan 2009 00:39:13 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090130233913.GB16764@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <49832DA5.5070101@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49832DA5.5070101@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 30, 2009 at 05:41:09PM +0100, Balazs Lengyel wrote: >> What I do not understand is that on the one hand the lock on allUsers >> is claimed to protect everything below allUsers but then you can >> acquire a lock on Joe even though I thought it is locked. > > BALAZS: from the draft: > "When a NETCONF session holds a lock on a node, no other session or > non-NETCONF mechanism of the system can change that node or any node > in the hierarchy of nodes beneath it." > > By locking a node you don't actually change it, so this feature does > not block that. later from the draft: > > "A partial lock operation MUST fail if: > > o Any part of the area to be protected is already locked (or > protected by partial locking) by another management session, > including other NETCONF sessions using or any other > non-NETCONF management method." > > It states that a partial lock only blocks another partial lock if it > executed "by another management session". I found the behaviour irritating and it would have helped me a lot if the text in the document would have been more explicit that it is OK to lock something that is already locked by the same management session and that the system has to maintain multiple locks even if they cover the same "region" (I do not think this is stated anywhere; or again I have to read between the lines somewhere). /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 netconf-bounces@ietf.org Fri Jan 30 15:39:50 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B4D3A6A05; Fri, 30 Jan 2009 15:39:50 -0800 (PST) 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 4A08E3A6A05 for ; Fri, 30 Jan 2009 15:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.176 X-Spam-Level: X-Spam-Status: No, score=-2.176 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 8w+WD1w+oBMF for ; Fri, 30 Jan 2009 15:39:45 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 25DEB3A67A3 for ; Fri, 30 Jan 2009 15:39:44 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47E56C00F7; Sat, 31 Jan 2009 00:39:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kVvDBmwoHCdr; Sat, 31 Jan 2009 00:39:19 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 33D2BC00A4; Sat, 31 Jan 2009 00:39:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03C5291E14A; Sat, 31 Jan 2009 00:39:13 +0100 (CET) Date: Sat, 31 Jan 2009 00:39:13 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20090130233913.GB16764@elstar.local> Mail-Followup-To: Balazs Lengyel , netconf mailing list , Martin Bjorklund References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <49832DA5.5070101@ericsson.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49832DA5.5070101@ericsson.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On Fri, Jan 30, 2009 at 05:41:09PM +0100, Balazs Lengyel wrote: >> What I do not understand is that on the one hand the lock on allUsers >> is claimed to protect everything below allUsers but then you can >> acquire a lock on Joe even though I thought it is locked. > > BALAZS: from the draft: > "When a NETCONF session holds a lock on a node, no other session or > non-NETCONF mechanism of the system can change that node or any node > in the hierarchy of nodes beneath it." > > By locking a node you don't actually change it, so this feature does > not block that. later from the draft: > > "A partial lock operation MUST fail if: > > o Any part of the area to be protected is already locked (or > protected by partial locking) by another management session, > including other NETCONF sessions using or any other > non-NETCONF management method." > > It states that a partial lock only blocks another partial lock if it > executed "by another management session". I found the behaviour irritating and it would have helped me a lot if the text in the document would have been more explicit that it is OK to lock something that is already locked by the same management session and that the system has to maintain multiple locks even if they cover the same "region" (I do not think this is stated anywhere; or again I have to read between the lines somewhere). /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 netconf-bounces@ietf.org Sat Jan 31 01:02:30 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA68D3A6991; Sat, 31 Jan 2009 01:02:30 -0800 (PST) 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 1E6773A67AE for ; Sat, 31 Jan 2009 01:02:29 -0800 (PST) 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 BfK-Yx0c+uOQ for ; Sat, 31 Jan 2009 01:02:27 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 9554D3A6949 for ; Sat, 31 Jan 2009 01:02:27 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00JISVREX520@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 17:02:04 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00DJ9VRC5Q00@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 17:02:02 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Sat, 31 Jan 2009 17:02:00 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 31 Jan 2009 17:02:00 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090124112300.GA10423@elstar.local> References: <20090123130028.GA8291@elstar.local> <20090124061957.GB10301@elstar.local> <20090124112300.GA10423@elstar.local> Cc: netconf@ietf.org Subject: Re: [Netconf] review of draft-ietf-netconf-monitoring-03 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Sorry, I made a mistake. Just ignore it. washam > > > > "The selection is the xpath expression which was used to evaluate > > > > the list of nodes to lock." Is subtree expression ignored? > > > > > > I don't understand your question. The select elements > > > carry xpath expressions, or if :xpath is not supported, instance > > > identifier expressions. I am not sure that was your question. > > > > Sorry for ambiguity. I meant if subtree filtering is used, how to > > deal with elements, instance identifier expressions? > > Edit-config does not do subtree filtering. I still don't get the > question. And even if it would, I fail to see the issue since the > locks a set of nodes and once processing > is complete, the select / instance identifier expressions do not > really matter anymore from the processing point of view. > > /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 netconf-bounces@ietf.org Sat Jan 31 02:07:40 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9753A69F3; Sat, 31 Jan 2009 02:07:40 -0800 (PST) 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 BF2903A69F3 for ; Sat, 31 Jan 2009 02:07:38 -0800 (PST) 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 gqM80IjYupDk for ; Sat, 31 Jan 2009 02:07:37 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id C01593A68A4 for ; Sat, 31 Jan 2009 02:07:37 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00JVIYS3X520@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 18:07:17 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00DKYYS10700@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 18:07:15 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Sat, 31 Jan 2009 18:07:13 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 31 Jan 2009 18:07:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090130233913.GB16764@elstar.local> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <49832DA5.5070101@ericsson.com> <20090130233913.GB16764@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I think this proposal is based on "Partial lock cannot be used to lock non-existent nodes, which would effectively attempt to reserve them for future use." stated in sec 2.4.1.2. Why locking non-existent nodes is not allowed currently, could anyone elaborate it? washam > On Fri, Jan 30, 2009 at 05:41:09PM +0100, Balazs Lengyel wrote: > > >> What I do not understand is that on the one hand the lock on allUsers > >> is claimed to protect everything below allUsers but then you can > >> acquire a lock on Joe even though I thought it is locked. > > > > BALAZS: from the draft: > > "When a NETCONF session holds a lock on a node, no other session or > > non-NETCONF mechanism of the system can change that node or any node > > in the hierarchy of nodes beneath it." > > > > By locking a node you don't actually change it, so this feature does > > not block that. later from the draft: > > > > "A partial lock operation MUST fail if: > > > > o Any part of the area to be protected is already locked (or > > protected by partial locking) by another management session, > > including other NETCONF sessions using or any other > > non-NETCONF management method." > > > > It states that a partial lock only blocks another partial lock if it > > > executed "by another management session". > > I found the behaviour irritating and it would have helped me a lot if > the text in the document would have been more explicit that it is OK > to lock something that is already locked by the same management > session and that the system has to maintain multiple locks even if > they cover the same "region" (I do not think this is stated anywhere; > or again I have to read between the lines somewhere). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 02:07:40 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9753A69F3; Sat, 31 Jan 2009 02:07:40 -0800 (PST) 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 BF2903A69F3 for ; Sat, 31 Jan 2009 02:07:38 -0800 (PST) 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 gqM80IjYupDk for ; Sat, 31 Jan 2009 02:07:37 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id C01593A68A4 for ; Sat, 31 Jan 2009 02:07:37 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00JVIYS3X520@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 18:07:17 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEB00DKYYS10700@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 18:07:15 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Sat, 31 Jan 2009 18:07:13 +0800 From: WashamFan To: j.schoenwaelder@jacobs-university.de Message-id: Date: Sat, 31 Jan 2009 18:07:13 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <20090130233913.GB16764@elstar.local> References: <20090122.080521.42945278.mbj@tail-f.com> <20090122072901.GA606@elstar.local> <20090122.083653.38607212.mbj@tail-f.com> <497DD39A.7030507@ericsson.com> <20090126170051.GA12088@elstar.local> <49832DA5.5070101@ericsson.com> <20090130233913.GB16764@elstar.local> Cc: netconf mailing list Subject: Re: [Netconf] Partial Lock Modifications, do you like them? : draft-ietf-netconf-partial-lock-05 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, I think this proposal is based on "Partial lock cannot be used to lock non-existent nodes, which would effectively attempt to reserve them for future use." stated in sec 2.4.1.2. Why locking non-existent nodes is not allowed currently, could anyone elaborate it? washam > On Fri, Jan 30, 2009 at 05:41:09PM +0100, Balazs Lengyel wrote: > > >> What I do not understand is that on the one hand the lock on allUsers > >> is claimed to protect everything below allUsers but then you can > >> acquire a lock on Joe even though I thought it is locked. > > > > BALAZS: from the draft: > > "When a NETCONF session holds a lock on a node, no other session or > > non-NETCONF mechanism of the system can change that node or any node > > in the hierarchy of nodes beneath it." > > > > By locking a node you don't actually change it, so this feature does > > not block that. later from the draft: > > > > "A partial lock operation MUST fail if: > > > > o Any part of the area to be protected is already locked (or > > protected by partial locking) by another management session, > > including other NETCONF sessions using or any other > > non-NETCONF management method." > > > > It states that a partial lock only blocks another partial lock if it > > > executed "by another management session". > > I found the behaviour irritating and it would have helped me a lot if > the text in the document would have been more explicit that it is OK > to lock something that is already locked by the same management > session and that the system has to maintain multiple locks even if > they cover the same "region" (I do not think this is stated anywhere; > or again I have to read between the lines somewhere). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 < > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 03:18:26 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430853A6982; Sat, 31 Jan 2009 03:18:26 -0800 (PST) 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 626E33A6982 for ; Sat, 31 Jan 2009 03:18:25 -0800 (PST) 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 H7s54opCqLnb for ; Sat, 31 Jan 2009 03:18:24 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 8A78E3A68F2 for ; Sat, 31 Jan 2009 03:18:24 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEC00FKH220HA20@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 19:18:02 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEC00CPW21YZV00@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 19:18:00 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Sat, 31 Jan 2009 19:17:58 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 31 Jan 2009 19:17:58 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <498348CE.9020301@andybierman.com> References: <498348CE.9020301@andybierman.com> Cc: NETCONF Subject: Re: [Netconf] overlapping nodes within a lock 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > > I don't think the draft is clear on how > nested nodes are handled. Full XPath is > not even required: > > > > > > > I'm not sure what it means to properly process > this request. Is it OK if an implementation prunes > overlapping nodes in the request? So the response > (and internal lock) will look like this: > > /foo > > Since this is all part of 1 lock, it should be OK. IMO, it should be OK, since all s. washam > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 03:18:26 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430853A6982; Sat, 31 Jan 2009 03:18:26 -0800 (PST) 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 626E33A6982 for ; Sat, 31 Jan 2009 03:18:25 -0800 (PST) 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 H7s54opCqLnb for ; Sat, 31 Jan 2009 03:18:24 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 8A78E3A68F2 for ; Sat, 31 Jan 2009 03:18:24 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEC00FKH220HA20@hstga02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 19:18:02 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KEC00CPW21YZV00@hstml02-in.huaweisymantec.com> for netconf@ietf.org; Sat, 31 Jan 2009 19:18:00 +0800 (CST) Received: from [220.249.46.106] by hstml02-in.huaweisymantec.com (mshttpd) ; Sat, 31 Jan 2009 19:17:58 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sat, 31 Jan 2009 19:17:58 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <498348CE.9020301@andybierman.com> References: <498348CE.9020301@andybierman.com> Cc: NETCONF Subject: Re: [Netconf] overlapping nodes within a lock 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > > I don't think the draft is clear on how > nested nodes are handled. Full XPath is > not even required: > > > > > > > I'm not sure what it means to properly process > this request. Is it OK if an implementation prunes > overlapping nodes in the request? So the response > (and internal lock) will look like this: > > /foo > > Since this is all part of 1 lock, it should be OK. IMO, it should be OK, since all s. washam > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 17:24:25 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8177128C101; Sat, 31 Jan 2009 17:24:25 -0800 (PST) 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 82D9A28C10F for ; Sat, 31 Jan 2009 17:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 pa0kJI4IAEpe for ; Sat, 31 Jan 2009 17:24:23 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 986953A68EB for ; Sat, 31 Jan 2009 17:24:23 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED00F6K57ZC200@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:24:01 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED002QC57XDZ10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:23:59 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sun, 01 Feb 2009 09:23:57 +0800 From: WashamFan To: Andy Bierman Message-id: Date: Sun, 01 Feb 2009 09:23:57 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49833EBB.2070107@netconfcentral.com> References: <49832E6A.30604@netconfcentral.com> <49833762.7030708@ericsson.com> <49833EBB.2070107@netconfcentral.com> Cc: NETCONF Subject: Re: [Netconf] partial-lock on multiple databases 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Balazs Lengyel wrote: > My first concern is that full XPath relies heavily on > the 'XML document order' concept and related mechanisms. > IMO, a NETCONF database has no set document order. > It is implementation-specific. It is not even useful, > since every node in the database has a unique identifier. > The order the user picks in the config may > not stay in that order internally. Yes. But I am a little confused, I remember the order issue has been discussed several times. Most people think it is a implementation-specific, and using *order* expr takes the risk of non-deterministic results. > So any expression involving XML document order is problematic. > > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > message-id="135"> > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > message-id="135"> > 127 > > /rte:routing/rte:virtualRouter[rte:routerName='router1'] > > > > > > Even though the reply indicates that different entries were locked, > I do not think the draft does a good job documenting the issues > with XPath and NETCONF. I don't really care where the problem > gets punted, but just ignoring it seems like poor standards > practice. > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 17:43:10 2009 Return-Path: X-Original-To: netconf-archive@ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB64828C0F4; Sat, 31 Jan 2009 17:43:10 -0800 (PST) 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 D6ECF3A68CB for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 u2IocVrlJmfL for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 1A8033A68EB for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED00FJ263BC200@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:42:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED003VX639UP10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:42:47 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sun, 01 Feb 2009 09:42:45 +0800 From: WashamFan To: Johan Rydberg Message-id: Date: Sun, 01 Feb 2009 09:42:45 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49830095.9030804@edgeware.tv> References: <49830095.9030804@edgeware.tv> Cc: netconf@ietf.org Subject: Re: [Netconf] access control: current implementations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, That is the question I want to ask, too. Access control seems have not yet been put on the table. I am not sure how people care about this issue now. washam > Could you out there who have your own agent implementations describe > your access control mechanism, and how it maps to different NETCONF > operations? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Jan 31 17:43:10 2009 Return-Path: X-Original-To: netconf-archive@lists.ietf.org Delivered-To: ietfarch-netconf-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB64828C0F4; Sat, 31 Jan 2009 17:43:10 -0800 (PST) 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 D6ECF3A68CB for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 u2IocVrlJmfL for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 1A8033A68EB for ; Sat, 31 Jan 2009 17:43:09 -0800 (PST) MIME-version: 1.0 Content-disposition: inline Received: from hstml01-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED00FJ263BC200@hstga01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:42:49 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KED003VX639UP10@hstml01-in.huaweisymantec.com> for netconf@ietf.org; Sun, 01 Feb 2009 09:42:47 +0800 (CST) Received: from [10.27.141.6] by hstml01-in.huaweisymantec.com (mshttpd); Sun, 01 Feb 2009 09:42:45 +0800 From: WashamFan To: Johan Rydberg Message-id: Date: Sun, 01 Feb 2009 09:42:45 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-5.02 (built Oct 12 2007; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal In-reply-to: <49830095.9030804@edgeware.tv> References: <49830095.9030804@edgeware.tv> Cc: netconf@ietf.org Subject: Re: [Netconf] access control: current implementations 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, That is the question I want to ask, too. Access control seems have not yet been put on the table. I am not sure how people care about this issue now. washam > Could you out there who have your own agent implementations describe > your access control mechanism, and how it maps to different NETCONF > operations? _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf