From netconf-bounces@ietf.org Mon Sep 1 07:37:17 2008 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 0C1533A69DA; Mon, 1 Sep 2008 07:37:17 -0700 (PDT) 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 448B53A69D9 for ; Mon, 1 Sep 2008 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 Q5CXMaUhCMXr for ; Mon, 1 Sep 2008 07:37:15 -0700 (PDT) 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 1BA2B3A6980 for ; Mon, 1 Sep 2008 07:37:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,307,1217822400"; d="scan'208";a="141863152" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 01 Sep 2008 10:37:15 -0400 X-IronPort-AV: E=Sophos;i="4.32,307,1217822400"; d="scan'208";a="263710895" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Sep 2008 10:37:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 16:37:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF over SOAP issue with draft-iijima-netconf-soap-implementation-10 Thread-Index: AckMQDh/C8n4Gpm+RiGIguY5Xotr5Q== From: "Romascanu, Dan (Dan)" To: Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com Subject: [Netconf] NETCONF over SOAP issue with draft-iijima-netconf-soap-implementation-10 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 During the IESG review of draft-iijima-netconf-soap-implementation-10 (AD-sponsored independent submission targeting Informational RFC) Pasi Eronen raised the issue of the usage by the implementation described in the document of the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. This makes such an implementation implementation to be an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. In the IESG discussions we chose to approve the document as Informational but make clear in the text that such implementations are not interoperable. We would like however to have the NETCONF WG look at the proposed text and make sure that we got it right and especially that RFC4743 is not in error. If you believe that there are any problems with the proposed text please let us know until 9/10 the latest. Proposed Notes to the RFC Editor: 1. In the Abstract Section: OLD: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. NEW: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. It describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. 2. Add to Section 1.2 the following paragraph: This document describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation as it relies on cookies used on top of the persistent transport connections of HTTP. This is provided for information purposes only based on the implementation experience of the authors. 3. In Section 3.1.2 OLD: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session will be supported by an HTTP connection. However HTTP is a stateless protocol; that is, HTTP cannot process a user's request according to the state resulting from the user's previous request. Unless the state is kept at the HTTP- level, a different NETCONF service provider will be invoked every time the NETCONF application sends a NETCONF message to the NETCONF service provider. To ensure that the same NETCONF service provider is used every time the NETCONF application sends a NETCONF message, the state of the HTTP connection must be maintained. Accordingly, a cookie field inside an HTTP header was devised for maintaining the state of an HTTP connection. We therefore used such a cookie field to maintain the state of the HTTP connection over which the NETCONF- session maintenance is ensured. NEW: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session state is tied to the state of the underlying transport (TCP) connection (just like in NETCONF over SSH [RFC4742] and NETCONF over BEEP [RFC4744]). However, HTTP itself is a stateless protocol, and many server implementations process user requests independently of previous requests received over the same transport connection. To simplify implementation of the NETCONF service provider, we used the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. Note that this means our implementation actually uses an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. Thanks and Regards, Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 1 07:37:17 2008 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 0C1533A69DA; Mon, 1 Sep 2008 07:37:17 -0700 (PDT) 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 448B53A69D9 for ; Mon, 1 Sep 2008 07:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 Q5CXMaUhCMXr for ; Mon, 1 Sep 2008 07:37:15 -0700 (PDT) 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 1BA2B3A6980 for ; Mon, 1 Sep 2008 07:37:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,307,1217822400"; d="scan'208";a="141863152" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 01 Sep 2008 10:37:15 -0400 X-IronPort-AV: E=Sophos;i="4.32,307,1217822400"; d="scan'208";a="263710895" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Sep 2008 10:37:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 16:37:12 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NETCONF over SOAP issue with draft-iijima-netconf-soap-implementation-10 Thread-Index: AckMQDh/C8n4Gpm+RiGIguY5Xotr5Q== From: "Romascanu, Dan (Dan)" To: Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com Subject: [Netconf] NETCONF over SOAP issue with draft-iijima-netconf-soap-implementation-10 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 During the IESG review of draft-iijima-netconf-soap-implementation-10 (AD-sponsored independent submission targeting Informational RFC) Pasi Eronen raised the issue of the usage by the implementation described in the document of the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. This makes such an implementation implementation to be an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. In the IESG discussions we chose to approve the document as Informational but make clear in the text that such implementations are not interoperable. We would like however to have the NETCONF WG look at the proposed text and make sure that we got it right and especially that RFC4743 is not in error. If you believe that there are any problems with the proposed text please let us know until 9/10 the latest. Proposed Notes to the RFC Editor: 1. In the Abstract Section: OLD: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. NEW: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. It describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. 2. Add to Section 1.2 the following paragraph: This document describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation as it relies on cookies used on top of the persistent transport connections of HTTP. This is provided for information purposes only based on the implementation experience of the authors. 3. In Section 3.1.2 OLD: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session will be supported by an HTTP connection. However HTTP is a stateless protocol; that is, HTTP cannot process a user's request according to the state resulting from the user's previous request. Unless the state is kept at the HTTP- level, a different NETCONF service provider will be invoked every time the NETCONF application sends a NETCONF message to the NETCONF service provider. To ensure that the same NETCONF service provider is used every time the NETCONF application sends a NETCONF message, the state of the HTTP connection must be maintained. Accordingly, a cookie field inside an HTTP header was devised for maintaining the state of an HTTP connection. We therefore used such a cookie field to maintain the state of the HTTP connection over which the NETCONF- session maintenance is ensured. NEW: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session state is tied to the state of the underlying transport (TCP) connection (just like in NETCONF over SSH [RFC4742] and NETCONF over BEEP [RFC4744]). However, HTTP itself is a stateless protocol, and many server implementations process user requests independently of previous requests received over the same transport connection. To simplify implementation of the NETCONF service provider, we used the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. Note that this means our implementation actually uses an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. Thanks and Regards, Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 1 14:15:04 2008 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 7555C28C10A; Mon, 1 Sep 2008 14:15:04 -0700 (PDT) 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 E351328C105 for ; Mon, 1 Sep 2008 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_50=0.001, STOX_REPLY_TYPE=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 WSNA8rU+lvPN for ; Mon, 1 Sep 2008 14:15:03 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id BE67928C10A for ; Mon, 1 Sep 2008 14:15:00 -0700 (PDT) Received: (qmail 56148 invoked from network); 1 Sep 2008 21:15:05 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 1 Sep 2008 21:15:05 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> In-Reply-To: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> Date: Mon, 1 Sep 2008 23:14:29 +0200 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] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On page 7 I see: Example: Lock virtual router 1 and interface eth1 xmlns:rte="http://example.com/ns/route"> -> xmlns:if="http://example.com/ns/interface"> nc:message-id="135"> xmlns:rte="http://example.com/ns/route"> -> xmlns:if="http://example.com/ns/interface"> nc:message-id="135"> 127 Can the authors/editors explain to me why the lines marked with -> are needed? Further, I wonder how a client knows exactly what he/she has locked if the partial-lock succeeds. How is the client sure that what he/she thinks that the expression will result in is the same than what the server (the managed device) thinks? I still need to check the appendices. Bert _______________________________From netconf-bounces@ietf.org Mon Sep 1 14:15:04 2008 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 7555C28C10A; Mon, 1 Sep 2008 14:15:04 -0700 (PDT) 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 E351328C105 for ; Mon, 1 Sep 2008 14:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.34 X-Spam-Level: X-Spam-Status: No, score=0.34 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_50=0.001, STOX_REPLY_TYPE=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 WSNA8rU+lvPN for ; Mon, 1 Sep 2008 14:15:03 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id BE67928C10A for ; Mon, 1 Sep 2008 14:15:00 -0700 (PDT) Received: (qmail 56148 invoked from network); 1 Sep 2008 21:15:05 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 1 Sep 2008 21:15:05 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> In-Reply-To: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> Date: Mon, 1 Sep 2008 23:14:29 +0200 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] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org On page 7 I see: Example: Lock virtual router 1 and interface eth1 xmlns:rte="http://example.com/ns/route"> -> xmlns:if="http://example.com/ns/interface"> nc:message-id="135"> xmlns:rte="http://example.com/ns/route"> -> xmlns:if="http://example.com/ns/interface"> nc:message-id="135"> 127 Can the authors/editors explain to me why the lines marked with -> are needed? Further, I wonder how a client knows exactly what he/she has locked if the partial-lock succeeds. How is the client sure that what he/she thinks that the expression will result in is the same than what the server (the managed device) thinks? I still need to check the appendices. Bert _____________________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf __________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 00:01:48 2008 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 6FF713A6B82; Tue, 2 Sep 2008 00:01:48 -0700 (PDT) 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 9F4363A6B82 for ; Tue, 2 Sep 2008 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 3+9druK5x9X7 for ; Tue, 2 Sep 2008 00:01:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8842F3A6B78 for ; Tue, 2 Sep 2008 00:01:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 52A4F76C4D7; Tue, 2 Sep 2008 09:01:49 +0200 (CEST) Date: Tue, 02 Sep 2008 09:02:19 +0200 (CEST) Message-Id: <20080902.090219.226892285.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > On page 7 I see: > > > Example: Lock virtual router 1 and interface eth1 > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > -> xmlns:rte="http://example.com/ns/route"> > -> xmlns:if="http://example.com/ns/interface"> > nc:message-id="135"> > > > > > > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > -> xmlns:rte="http://example.com/ns/route"> > -> xmlns:if="http://example.com/ns/interface"> > nc:message-id="135"> > > 127 > > > > Can the authors/editors explain to me why the lines marked with -> > are needed? There's an error in the 'select' XPath expressions. The prefixes declareed should really be used. In order to avoid discussions about whether xmlns declarations in has to be present in the , I suggest we change this example From netconf-bounces@ietf.org Tue Sep 2 00:01:48 2008 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 6FF713A6B82; Tue, 2 Sep 2008 00:01:48 -0700 (PDT) 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 9F4363A6B82 for ; Tue, 2 Sep 2008 00:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.149, 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 3+9druK5x9X7 for ; Tue, 2 Sep 2008 00:01:45 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 8842F3A6B78 for ; Tue, 2 Sep 2008 00:01:45 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 52A4F76C4D7; Tue, 2 Sep 2008 09:01:49 +0200 (CEST) Date: Tue, 02 Sep 2008 09:02:19 +0200 (CEST) Message-Id: <20080902.090219.226892285.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > On page 7 I see: > > > Example: Lock virtual router 1 and interface eth1 > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > -> xmlns:rte="http://example.com/ns/route"> > -> xmlns:if="http://example.com/ns/interface"> > nc:message-id="135"> > > > > > > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > -> xmlns:rte="http://example.com/ns/route"> > -> xmlns:if="http://example.com/ns/interface"> > nc:message-id="135"> > > 127 > > > > Can the authors/editors explain to me why the lines marked with -> > are needed? There's an error in the 'select' XPath expressions. The prefixes declareed should really be used. In order to avoid discussions about whether xmlns declarations in has to be present in the , I suggest we change this exinto: 127 > Further, I wonder how a client knows exactly what he/she has > locked if the partial-lock succeeds. How is the client sure that > what he/she thinks that the expression will result in is the > same than what the server (the managed device) thinks? In practise, I think the expressions used for the partial-lock operation will be limited to expressions which selects a single subtree (or a set of them) by using an instance-identifier, as in the examples above. This works if the client knows the data model - the predicates above matches on the keys of a router and interface. In these cases, the client knows that if the lock succeeds, the subtree exists and is locked. In general, the XPath expression could be arbitrarily complex, in which case it might not be obvious exactly which nodes are locked. One way to learn which nodes are locked could be to use the monitoring data model. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ample into: 127 > Further, I wonder how a client knows exactly what he/she has > locked if the partial-lock succeeds. How is the client sure that > what he/she thinks that the expression will result in is the > same than what the server (the managed device) thinks? In practise, I think the expressions used for the partial-lock operation will be limited to expressions which selects a single subtree (or a set of them) by using an instance-identifier, as in the examples above. This works if the client knows the data model - the predicates above matches on the keys of a router and interface. In these cases, the client knows that if the lock succeeds, the subtree exists and is locked. In general, the XPath expression could be arbitrarily complex, in which case it might not be obvious exactly which nodes are locked. One way to learn which nodes are locked could be to use the monitoring data model. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 02:12:05 2008 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 0F3E43A6BAF; Tue, 2 Sep 2008 02:12:05 -0700 (PDT) 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 146E128C139 for ; Tue, 2 Sep 2008 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xncmK05lVbhj for ; Tue, 2 Sep 2008 02:11:59 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 0F9D83A6B96 for ; Tue, 2 Sep 2008 02:11:58 -0700 (PDT) X-Trace: 21704588/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.249 X-SBRS: None X-RemoteIP: 213.116.50.249 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHugvEjVdDL5/2dsb2JhbACDRziIDKcEA4Fm X-IronPort-AV: E=Sophos;i="4.32,315,1217804400"; d="scan'208";a="21704588" X-IP-Direction: IN Received: from 1cust249.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.249]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 10:11:17 +0100 Message-ID: <015801c90cd2$85b88e20$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> Date: Tue, 2 Sep 2008 09:59:33 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, August 28, 2008 4:39 PM Subject: [Netconf] netconf-tls > The syslog WG is finalizing their document on syslog-tls. The IESG > review raised a number of DISCUSSES for important security issues. > > draft-hodges-server-ident-check-00 is an attempt to standardize how > applications check server identities using TLS. I am not comfortable with this I-D and do not see it as a good reference without substantially more discussion; its focus is much narrower than the title suggests. Trouble is, where can that discussion be? The TLS list has shown itself reluctant to discuss such issues and indeed, the I-D, while TLS-centric, does make claims to have a wider scope. I did e-mail the AD who raised the DISCUSS on syslog-tls citing this expired I-D asking for a wider discussion but as yet, nothing has materialised. So for the moment, I would not use it, but rather go back to the many RFC already published with such sections. Tom Petch I strongly recommend > the editors of netconf-tls pay close attention to the work being done > for syslog-tls and the hodges draft, to ensure consistency and > compatibility and to ease the approval path. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > 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 Tue Sep 2 02:12:05 2008 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 0F3E43A6BAF; Tue, 2 Sep 2008 02:12:05 -0700 (PDT) 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 146E128C139 for ; Tue, 2 Sep 2008 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.057 X-Spam-Level: X-Spam-Status: No, score=-0.057 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xncmK05lVbhj for ; Tue, 2 Sep 2008 02:11:59 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 0F9D83A6B96 for ; Tue, 2 Sep 2008 02:11:58 -0700 (PDT) X-Trace: 21704588/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.249 X-SBRS: None X-RemoteIP: 213.116.50.249 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHugvEjVdDL5/2dsb2JhbACDRziIDKcEA4Fm X-IronPort-AV: E=Sophos;i="4.32,315,1217804400"; d="scan'208";a="21704588" X-IP-Direction: IN Received: from 1cust249.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.249]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 10:11:17 +0100 Message-ID: <015801c90cd2$85b88e20$0601a8c0@allison> From: "tom.petch" To: "David Harrington" , References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> Date: Tue, 2 Sep 2008 09:59:33 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "David Harrington" To: Sent: Thursday, August 28, 2008 4:39 PM Subject: [Netconf] netconf-tls > The syslog WG is finalizing their document on syslog-tls. The IESG > review raised a number of DISCUSSES for important security issues. > > draft-hodges-server-ident-check-00 is an attempt to standardize how > applications check server identities using TLS. I am not comfortable with this I-D and do not see it as a good reference without substantially more discussion; its focus is much narrower than the title suggests. Trouble is, where can that discussion be? The TLS list has shown itself reluctant to discuss such issues and indeed, the I-D, while TLS-centric, does make claims to have a wider scope. I did e-mail the AD who raised the DISCUSS on syslog-tls citing this expired I-D asking for a wider discussion but as yet, nothing has materialised. So for the moment, I would not use it, but rather go back to the many RFC already published with such sections. Tom Petch I strongly recommend > the editors of netconf-tls pay close attention to the work being done > for syslog-tls and the hodges draft, to ensure consistency and > compatibility and to ease the approval path. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > 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 Tue Sep 2 06:32:32 2008 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 74B333A6AB4; Tue, 2 Sep 2008 06:32:32 -0700 (PDT) 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 4CE9B3A6AB4 for ; Tue, 2 Sep 2008 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, STOX_REPLY_TYPE=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 38FeD+XC+Oxk for ; Tue, 2 Sep 2008 06:32:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id F336B3A6AAC for ; Tue, 2 Sep 2008 06:32:28 -0700 (PDT) Received: (qmail 90980 invoked from network); 2 Sep 2008 13:32:16 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 13:32:16 -0000 Message-ID: <1005A99D457D4709BDB8EC6BBB422FA0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> <20080902.090219.226892285.mbj@tail-f.com> In-Reply-To: <20080902.090219.226892285.mbj@tail-f.com> Date: Tue, 2 Sep 2008 15:31:36 +0200 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 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, September 02, 2008 9:02 AM Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt > "Bert Wijnen \(IETF\)" wrote: >> On page 7 I see: >> >> >> Example: Lock virtual router 1 and interface eth1 >> >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" >> -> xmlns:rte="http://example.com/ns/route"> >> -> xmlns:if="http://example.com/ns/interface"> >> nc:message-id="135"> >> >> >> >> >> >> >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" >> -> xmlns:rte="http://example.com/ns/route"> >> -> xmlns:if="http://example.com/ns/interface"> >> nc:message-id="135"> >> >> 127 >> >> >> >> Can the authors/editors explain to me why the lines marked with -> >> are needed? > > There's an error in the 'select' XPath expressions. The prefixes > declareed should really be used. In order to avoid > discussions about whether xmlns declarations in has to be > present in the , I suggest we change this example into: > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > nc:message-id="135"> > > > > > > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > nc:message-id="135"> > > 127 > > > > That looks better to me. >> Further, I wonder how a client knows exactly what he/she has >> locked if the partial-lock succeeds. How is the client sure that >> what he/she thinks that the expression will result in is the >> same than what the server (the managed device) thinks? > > In practise, I think the expressions used for the partial-lock > operation will be limited to expressions which selects a single > subtree (or a set of them) by using an instance-identifier, as in the > examples above. This works if the client knows the data model - the > predicates above matches on the keys of a router and interface. In > these cases, the client knows that if the lock succeeds, the subtree > exists and is locked. > > In general, the XPath expression could be arbitrarily complex, in > which case it might not be obvious exactly which nodes are locked. > One way to learn which nodes are locked could be to use the monitoring > data model. > Mmm... we do not want to depend on the monitoring draft do we? Is there no way with the existing protocol operations to find out? Anyway... it would be good to describe these aspects in the document (i think, as a technical contributor). > > /martin > > Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 06:32:32 2008 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 74B333A6AB4; Tue, 2 Sep 2008 06:32:32 -0700 (PDT) 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 4CE9B3A6AB4 for ; Tue, 2 Sep 2008 06:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.028 X-Spam-Level: X-Spam-Status: No, score=-1.028 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, STOX_REPLY_TYPE=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 38FeD+XC+Oxk for ; Tue, 2 Sep 2008 06:32:30 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id F336B3A6AAC for ; Tue, 2 Sep 2008 06:32:28 -0700 (PDT) Received: (qmail 90980 invoked from network); 2 Sep 2008 13:32:16 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 13:32:16 -0000 Message-ID: <1005A99D457D4709BDB8EC6BBB422FA0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Martin Bjorklund" References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> <20080902.090219.226892285.mbj@tail-f.com> In-Reply-To: <20080902.090219.226892285.mbj@tail-f.com> Date: Tue, 2 Sep 2008 15:31:36 +0200 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 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Inline ----- Original Message ----- From: "Martin Bjorklund" To: Cc: Sent: Tuesday, September 02, 2008 9:02 AM Subject: Re: [Netconf] My review for: WGLC for draft-ietf-netconf-partial-lock-03.txt > "Bert Wijnen \(IETF\)" wrote: >> On page 7 I see: >> >> >> Example: Lock virtual router 1 and interface eth1 >> >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" >> -> xmlns:rte="http://example.com/ns/route"> >> -> xmlns:if="http://example.com/ns/interface"> >> nc:message-id="135"> >> >> >> >> >> >> >> >> > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" >> xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" >> -> xmlns:rte="http://example.com/ns/route"> >> -> xmlns:if="http://example.com/ns/interface"> >> nc:message-id="135"> >> >> 127 >> >> >> >> Can the authors/editors explain to me why the lines marked with -> >> are needed? > > There's an error in the 'select' XPath expressions. The prefixes > declareed should really be used. In order to avoid > discussions about whether xmlns declarations in has to be > present in the , I suggest we change this example into: > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > nc:message-id="135"> > > > > > > > > xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" > xmlns="urn:ietf:params:xml:ns:netconf:partial-lock:1.0" > nc:message-id="135"> > > 127 > > > > That looks better to me. >> Further, I wonder how a client knows exactly what he/she has >> locked if the partial-lock succeeds. How is the client sure that >> what he/she thinks that the expression will result in is the >> same than what the server (the managed device) thinks? > > In practise, I think the expressions used for the partial-lock > operation will be limited to expressions which selects a single > subtree (or a set of them) by using an instance-identifier, as in the > examples above. This works if the client knows the data model - the > predicates above matches on the keys of a router and interface. In > these cases, the client knows that if the lock succeeds, the subtree > exists and is locked. > > In general, the XPath expression could be arbitrarily complex, in > which case it might not be obvious exactly which nodes are locked. > One way to learn which nodes are locked could be to use the monitoring > data model. > Mmm... we do not want to depend on the monitoring draft do we? Is there no way with the existing protocol operations to find out? Anyway... it would be good to describe these aspects in the document (i think, as a technical contributor). > > /martin > > Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 07:02:21 2008 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 AD65428C170; Tue, 2 Sep 2008 07:02:21 -0700 (PDT) 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 8007828C197 for ; Tue, 2 Sep 2008 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, STOX_REPLY_TYPE=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 8OcJGKRhVwsP for ; Tue, 2 Sep 2008 07:02:19 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3ACC928C15F for ; Tue, 2 Sep 2008 07:02:19 -0700 (PDT) Received: (qmail 29726 invoked from network); 2 Sep 2008 13:55:17 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 13:55:17 -0000 Message-ID: <3187848565A54110A8F711E8BE9F0D04@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "tom.petch" , "Netconf" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> <015801c90cd2$85b88e20$0601a8c0@allison> In-Reply-To: <015801c90cd2$85b88e20$0601a8c0@allison> Date: Tue, 2 Sep 2008 15:36:51 +0200 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: Re: [Netconf] netconf-tls 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 Tom, just to be sure I understand your response correctly. You are saying that we should NOT take the draft-hodges-server-ident-check document as a good source of things to consider, right? Bert ----- Original Message ----- From: "tom.petch" To: "David Harrington" ; Sent: Tuesday, September 02, 2008 9:59 AM Subject: Re: [Netconf] netconf-tls > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, August 28, 2008 4:39 PM > Subject: [Netconf] netconf-tls > > >> The syslog WG is finalizing their document on syslog-tls. The IESG >> review raised a number of DISCUSSES for important security issues. >> >> draft-hodges-server-ident-check-00 is an attempt to standardize how >> applications check server identities using TLS. > > I am not comfortable with this I-D and do not see it as a good reference > without > substantially more discussion; its focus is much narrower than the title > suggests. Trouble is, where can that discussion be? The TLS list has > shown > itself reluctant to discuss such issues and indeed, the I-D, while > TLS-centric, > does make claims to have a wider scope. I did e-mail the AD who raised > the > DISCUSS on syslog-tls citing this expired I-D asking for a wider > discussion but > as yet, nothing has materialised. So for the moment, I would not use it, > but > rather go back to the many RFC already published with such sections. > > Tom Petch > > > I > strongly > recommend >> the editors of netconf-tls pay close attention to the work being done >> for syslog-tls and the hodges draft, to ensure consistency and >> compatibility and to ease the approval path. >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> dharrington@huawei.com >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 07:02:21 2008 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 AD65428C170; Tue, 2 Sep 2008 07:02:21 -0700 (PDT) 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 8007828C197 for ; Tue, 2 Sep 2008 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[AWL=1.308, BAYES_00=-2.599, STOX_REPLY_TYPE=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 8OcJGKRhVwsP for ; Tue, 2 Sep 2008 07:02:19 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3ACC928C15F for ; Tue, 2 Sep 2008 07:02:19 -0700 (PDT) Received: (qmail 29726 invoked from network); 2 Sep 2008 13:55:17 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 13:55:17 -0000 Message-ID: <3187848565A54110A8F711E8BE9F0D04@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "tom.petch" , "Netconf" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> <015801c90cd2$85b88e20$0601a8c0@allison> In-Reply-To: <015801c90cd2$85b88e20$0601a8c0@allison> Date: Tue, 2 Sep 2008 15:36:51 +0200 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: Re: [Netconf] netconf-tls 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 Tom, just to be sure I understand your response correctly. You are saying that we should NOT take the draft-hodges-server-ident-check document as a good source of things to consider, right? Bert ----- Original Message ----- From: "tom.petch" To: "David Harrington" ; Sent: Tuesday, September 02, 2008 9:59 AM Subject: Re: [Netconf] netconf-tls > ----- Original Message ----- > From: "David Harrington" > To: > Sent: Thursday, August 28, 2008 4:39 PM > Subject: [Netconf] netconf-tls > > >> The syslog WG is finalizing their document on syslog-tls. The IESG >> review raised a number of DISCUSSES for important security issues. >> >> draft-hodges-server-ident-check-00 is an attempt to standardize how >> applications check server identities using TLS. > > I am not comfortable with this I-D and do not see it as a good reference > without > substantially more discussion; its focus is much narrower than the title > suggests. Trouble is, where can that discussion be? The TLS list has > shown > itself reluctant to discuss such issues and indeed, the I-D, while > TLS-centric, > does make claims to have a wider scope. I did e-mail the AD who raised > the > DISCUSS on syslog-tls citing this expired I-D asking for a wider > discussion but > as yet, nothing has materialised. So for the moment, I would not use it, > but > rather go back to the many RFC already published with such sections. > > Tom Petch > > > I > strongly > recommend >> the editors of netconf-tls pay close attention to the work being done >> for syslog-tls and the hodges draft, to ensure consistency and >> compatibility and to ease the approval path. >> >> David Harrington >> dbharrington@comcast.net >> ietfdbh@comcast.net >> dharrington@huawei.com >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 07:11:16 2008 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 9C21D3A6A96; Tue, 2 Sep 2008 07:11:16 -0700 (PDT) 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 5F6383A69A3 for ; Tue, 2 Sep 2008 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, STOX_REPLY_TYPE=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 QNnIrWc2w6Dv for ; Tue, 2 Sep 2008 07:11:14 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id AFDD53A635F for ; Tue, 2 Sep 2008 07:11:13 -0700 (PDT) Received: (qmail 56481 invoked from network); 2 Sep 2008 14:10:48 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 14:10:48 -0000 Message-ID: <910D11524E714598B6CC5B5ACC075834@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Romascanu, Dan \(Dan\)" , References: In-Reply-To: Date: Tue, 2 Sep 2008 15:57:00 +0200 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 Cc: Pasi.Eronen@nokia.com, tomoyuki.iijima@alaxala.com Subject: Re: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 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 So it seems that neither the WG chairs, nor the Netconf-over-soap authors/editors. nor any other WG member had noticed this. Strange. I will hacve to go and re-read. Personally I am somewhat worried if we publish "implementation experience of Netconf over SOAP" if it is not interoperable with the NETCONF over SOAP standards track specification!!!! Even if that is spelled out clearly. Does anyone else in teh WG have an opinion (or care)? Bert ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: Cc: ; Sent: Monday, September 01, 2008 4:37 PM Subject: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 > During the IESG review of draft-iijima-netconf-soap-implementation-10 > (AD-sponsored independent submission targeting Informational RFC) Pasi > Eronen raised the issue of the usage by the implementation described in > the document of the cookie field inside the HTTP header to map incoming > requests to NETCONF sessions. This makes such an implementation > implementation to be an alternative SOAP binding for NETCONF which does > not interoperate with RFC4743 compliant implementations. > > In the IESG discussions we chose to approve the document as > Informational but make clear in the text that such implementations are > not interoperable. We would like however to have the NETCONF WG look at > the proposed text and make sure that we got it right and especially that > RFC4743 is not in error. > > If you believe that there are any problems with the proposed text please > let us know until 9/10 the latest. > > Proposed Notes to the RFC Editor: > > > > 1. In the Abstract Section: > > OLD: > > This document describes how the authors developed a SOAP (Simple > Object Access Protocol)-based NETCONF client and server. When SOAP > is used as a transport protocol for NETCONF, various kinds of > development tools are available. By making full use of these tools, > developers can significantly reduce their workload. The authors > developed an NMS (Network Management System) and network equipment > that can deal with NETCONF messages sent over SOAP. This document > aims to provide NETCONF development guidelines gained from the > experience of implementing a SOAP-based NETCONF client and server. > > NEW: > > This document describes how the authors developed a SOAP (Simple > Object Access Protocol)-based NETCONF client and server. It > describes an alternative SOAP binding for NETCONF which does not > interoperate with an RFC4743 conformant implementation making > use of cookies on top of the persistent transport connections of HTTP. > > When SOAP is used as a transport protocol for NETCONF, various kinds > of > development tools are available. By making full use of these tools, > developers can significantly reduce their workload. The authors > developed an NMS (Network Management System) and network equipment > that can deal with NETCONF messages sent over SOAP. This document > aims to provide NETCONF development guidelines gained from the > experience of implementing a SOAP-based NETCONF client and server. > > 2. Add to Section 1.2 the following paragraph: > > This document describes an alternative SOAP binding for NETCONF which > does not interoperate with an RFC4743 conformant implementation as it > relies on cookies used on top of the persistent transport connections > of HTTP. This is provided for information purposes only based on the > implementation experience of the authors. > > 3. In Section 3.1.2 > > OLD: > > In [RFC4743], HTTP is specified as an option of an underlying > protocol for NETCONF over SOAP. When HTTP is used for that purpose, > it is also specified that a NETCONF session will be supported by an > HTTP connection. However HTTP is a stateless protocol; that is, HTTP > cannot process a user's request according to the state resulting from > the user's previous request. Unless the state is kept at the HTTP- > level, a different NETCONF service provider will be invoked every > time the NETCONF application sends a NETCONF message to the NETCONF > service provider. To ensure that the same NETCONF service provider > is used every time the NETCONF application sends a NETCONF message, > the state of the HTTP connection must be maintained. Accordingly, a > cookie field inside an HTTP header was devised for maintaining the > state of an HTTP connection. We therefore used such a cookie field > to maintain the state of the HTTP connection over which the NETCONF- > session maintenance is ensured. > > NEW: > > In [RFC4743], HTTP is specified as an option of an underlying > protocol for NETCONF over SOAP. When HTTP is used for that > purpose, it is also specified that a NETCONF session state is tied > to the state of the underlying transport (TCP) connection (just > like in NETCONF over SSH [RFC4742] and NETCONF over BEEP > [RFC4744]). However, HTTP itself is a stateless protocol, and many > server implementations process user requests independently of > previous requests received over the same transport connection. To > simplify implementation of the NETCONF service provider, we used > the cookie field inside the HTTP header to map incoming requests to > NETCONF sessions. Note that this means our implementation actually > uses an alternative SOAP binding for NETCONF which does not > interoperate with RFC4743 compliant implementations. > > Thanks and Regards, > > Dan > > _______________________________________________ > 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 Tue Sep 2 07:11:16 2008 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 9C21D3A6A96; Tue, 2 Sep 2008 07:11:16 -0700 (PDT) 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 5F6383A69A3 for ; Tue, 2 Sep 2008 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=1.121, BAYES_00=-2.599, STOX_REPLY_TYPE=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 QNnIrWc2w6Dv for ; Tue, 2 Sep 2008 07:11:14 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id AFDD53A635F for ; Tue, 2 Sep 2008 07:11:13 -0700 (PDT) Received: (qmail 56481 invoked from network); 2 Sep 2008 14:10:48 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 14:10:48 -0000 Message-ID: <910D11524E714598B6CC5B5ACC075834@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "Romascanu, Dan \(Dan\)" , References: In-Reply-To: Date: Tue, 2 Sep 2008 15:57:00 +0200 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 Cc: Pasi.Eronen@nokia.com, tomoyuki.iijima@alaxala.com Subject: Re: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 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 So it seems that neither the WG chairs, nor the Netconf-over-soap authors/editors. nor any other WG member had noticed this. Strange. I will hacve to go and re-read. Personally I am somewhat worried if we publish "implementation experience of Netconf over SOAP" if it is not interoperable with the NETCONF over SOAP standards track specification!!!! Even if that is spelled out clearly. Does anyone else in teh WG have an opinion (or care)? Bert ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: Cc: ; Sent: Monday, September 01, 2008 4:37 PM Subject: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 > During the IESG review of draft-iijima-netconf-soap-implementation-10 > (AD-sponsored independent submission targeting Informational RFC) Pasi > Eronen raised the issue of the usage by the implementation described in > the document of the cookie field inside the HTTP header to map incoming > requests to NETCONF sessions. This makes such an implementation > implementation to be an alternative SOAP binding for NETCONF which does > not interoperate with RFC4743 compliant implementations. > > In the IESG discussions we chose to approve the document as > Informational but make clear in the text that such implementations are > not interoperable. We would like however to have the NETCONF WG look at > the proposed text and make sure that we got it right and especially that > RFC4743 is not in error. > > If you believe that there are any problems with the proposed text please > let us know until 9/10 the latest. > > Proposed Notes to the RFC Editor: > > > > 1. In the Abstract Section: > > OLD: > > This document describes how the authors developed a SOAP (Simple > Object Access Protocol)-based NETCONF client and server. When SOAP > is used as a transport protocol for NETCONF, various kinds of > development tools are available. By making full use of these tools, > developers can significantly reduce their workload. The authors > developed an NMS (Network Management System) and network equipment > that can deal with NETCONF messages sent over SOAP. This document > aims to provide NETCONF development guidelines gained from the > experience of implementing a SOAP-based NETCONF client and server. > > NEW: > > This document describes how the authors developed a SOAP (Simple > Object Access Protocol)-based NETCONF client and server. It > describes an alternative SOAP binding for NETCONF which does not > interoperate with an RFC4743 conformant implementation making > use of cookies on top of the persistent transport connections of HTTP. > > When SOAP is used as a transport protocol for NETCONF, various kinds > of > development tools are available. By making full use of these tools, > developers can significantly reduce their workload. The authors > developed an NMS (Network Management System) and network equipment > that can deal with NETCONF messages sent over SOAP. This document > aims to provide NETCONF development guidelines gained from the > experience of implementing a SOAP-based NETCONF client and server. > > 2. Add to Section 1.2 the following paragraph: > > This document describes an alternative SOAP binding for NETCONF which > does not interoperate with an RFC4743 conformant implementation as it > relies on cookies used on top of the persistent transport connections > of HTTP. This is provided for information purposes only based on the > implementation experience of the authors. > > 3. In Section 3.1.2 > > OLD: > > In [RFC4743], HTTP is specified as an option of an underlying > protocol for NETCONF over SOAP. When HTTP is used for that purpose, > it is also specified that a NETCONF session will be supported by an > HTTP connection. However HTTP is a stateless protocol; that is, HTTP > cannot process a user's request according to the state resulting from > the user's previous request. Unless the state is kept at the HTTP- > level, a different NETCONF service provider will be invoked every > time the NETCONF application sends a NETCONF message to the NETCONF > service provider. To ensure that the same NETCONF service provider > is used every time the NETCONF application sends a NETCONF message, > the state of the HTTP connection must be maintained. Accordingly, a > cookie field inside an HTTP header was devised for maintaining the > state of an HTTP connection. We therefore used such a cookie field > to maintain the state of the HTTP connection over which the NETCONF- > session maintenance is ensured. > > NEW: > > In [RFC4743], HTTP is specified as an option of an underlying > protocol for NETCONF over SOAP. When HTTP is used for that > purpose, it is also specified that a NETCONF session state is tied > to the state of the underlying transport (TCP) connection (just > like in NETCONF over SSH [RFC4742] and NETCONF over BEEP > [RFC4744]). However, HTTP itself is a stateless protocol, and many > server implementations process user requests independently of > previous requests received over the same transport connection. To > simplify implementation of the NETCONF service provider, we used > the cookie field inside the HTTP header to map incoming requests to > NETCONF sessions. Note that this means our implementation actually > uses an alternative SOAP binding for NETCONF which does not > interoperate with RFC4743 compliant implementations. > > Thanks and Regards, > > Dan > > _______________________________________________ > 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 Tue Sep 2 07:28:25 2008 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 34B683A6A8C; Tue, 2 Sep 2008 07:28:25 -0700 (PDT) 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 552023A6A7E for ; Tue, 2 Sep 2008 07:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.779, 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 5nmHTrTmuVAj for ; Tue, 2 Sep 2008 07:28:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3A2A33A694F for ; Tue, 2 Sep 2008 07:28:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB962C000F; Tue, 2 Sep 2008 16:28:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jEsBPOngQu5m; Tue, 2 Sep 2008 16:28:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68FACC0015; Tue, 2 Sep 2008 16:28:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 399CD6B878A; Tue, 2 Sep 2008 16:28:08 +0200 (CEST) Date: Tue, 2 Sep 2008 16:28:08 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20080902142808.GA6978@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , "Romascanu, Dan (Dan)" , netconf@ietf.org, Pasi.Eronen@nokia.com, tomoyuki.iijima@alaxala.com References: <910D11524E714598B6CC5B5ACC075834@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <910D11524E714598B6CC5B5ACC075834@BertLaptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com, netconf@ietf.org Subject: Re: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 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, Sep 02, 2008 at 03:57:00PM +0200, Bert Wijnen (IETF) wrote: > Personally I am somewhat worried if we publish "implementation > experience of Netconf over SOAP" if it is not interoperable with the > NETCONF over SOAP standards track specification!!!! Even if that is > spelled out clearly. I tend to agree. I personally don't care much about the SOAP interface and as such I did not bother to read this document carefully. Looking at it now, it strikes me a little bit when the document talks about file names such as "netconf-soap_1.0.wsdl" in section 4 under 'Guidelines for Developing NETCONF Clients and Servers'. It seems the authors document in quite some detail their specific implementation and I am not sure this belongs into an RFC - how stable is all this going to be? The same goes to the discussion of build files etc. which I personally find pretty out of scope for RFCs. /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 Sep 2 07:28:25 2008 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 34B683A6A8C; Tue, 2 Sep 2008 07:28:25 -0700 (PDT) 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 552023A6A7E for ; Tue, 2 Sep 2008 07:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=0.779, 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 5nmHTrTmuVAj for ; Tue, 2 Sep 2008 07:28:23 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3A2A33A694F for ; Tue, 2 Sep 2008 07:28:23 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AB962C000F; Tue, 2 Sep 2008 16:28:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jEsBPOngQu5m; Tue, 2 Sep 2008 16:28:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 68FACC0015; Tue, 2 Sep 2008 16:28:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 399CD6B878A; Tue, 2 Sep 2008 16:28:08 +0200 (CEST) Date: Tue, 2 Sep 2008 16:28:08 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20080902142808.GA6978@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , "Romascanu, Dan (Dan)" , netconf@ietf.org, Pasi.Eronen@nokia.com, tomoyuki.iijima@alaxala.com References: <910D11524E714598B6CC5B5ACC075834@BertLaptop> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <910D11524E714598B6CC5B5ACC075834@BertLaptop> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com, netconf@ietf.org Subject: Re: [Netconf] NETCONF over SOAP issue withdraft-iijima-netconf-soap-implementation-10 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, Sep 02, 2008 at 03:57:00PM +0200, Bert Wijnen (IETF) wrote: > Personally I am somewhat worried if we publish "implementation > experience of Netconf over SOAP" if it is not interoperable with the > NETCONF over SOAP standards track specification!!!! Even if that is > spelled out clearly. I tend to agree. I personally don't care much about the SOAP interface and as such I did not bother to read this document carefully. Looking at it now, it strikes me a little bit when the document talks about file names such as "netconf-soap_1.0.wsdl" in section 4 under 'Guidelines for Developing NETCONF Clients and Servers'. It seems the authors document in quite some detail their specific implementation and I am not sure this belongs into an RFC - how stable is all this going to be? The same goes to the discussion of build files etc. which I personally find pretty out of scope for RFCs. /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 Sep 2 07:34:06 2008 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 B55BB3A6908; Tue, 2 Sep 2008 07:34:06 -0700 (PDT) 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 8BAC03A6908 for ; Tue, 2 Sep 2008 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, STOX_REPLY_TYPE=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 tY7LThLDMf3T for ; Tue, 2 Sep 2008 07:34:05 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 40D4D3A635F for ; Tue, 2 Sep 2008 07:34:03 -0700 (PDT) Received: (qmail 95289 invoked from network); 2 Sep 2008 14:33:27 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 14:33:27 -0000 Message-ID: <674D06A979CB488A92F2FEF594F75BC8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <910D11524E714598B6CC5B5ACC075834@BertLaptop> <20080902142808.GA6978@elstar.local> In-Reply-To: <20080902142808.GA6978@elstar.local> Date: Tue, 2 Sep 2008 16:32:47 +0200 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 Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com, netconf@ietf.org Subject: Re: [Netconf] NETCONF over SOAP issuewithdraft-iijima-netconf-soap-implementation-10 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 Inline ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Bert Wijnen (IETF)" Cc: "Romascanu, Dan (Dan)" ; ; ; Sent: Tuesday, September 02, 2008 4:28 PM Subject: Re: [Netconf] NETCONF over SOAP issuewithdraft-iijima-netconf-soap-implementation-10 > On Tue, Sep 02, 2008 at 03:57:00PM +0200, Bert Wijnen (IETF) wrote: > >> Personally I am somewhat worried if we publish "implementation >> experience of Netconf over SOAP" if it is not interoperable with the >> NETCONF over SOAP standards track specification!!!! Even if that is >> spelled out clearly. > > I tend to agree. I personally don't care much about the SOAP interface > and as such I did not bother to read this document carefully. > > Looking at it now, it strikes me a little bit when the document talks > about file names such as "netconf-soap_1.0.wsdl" in section 4 under > 'Guidelines for Developing NETCONF Clients and Servers'. It seems the > authors document in quite some detail their specific implementation > and I am not sure this belongs into an RFC - how stable is all this > going to be? The same goes to the discussion of build files etc. > which I personally find pretty out of scope for RFCs. > It is not us (NETCONF WG) who have anything to say about such content (as individuals, we can do so of course). As a WG however, we have the duty and right to make sure that the document does not conflict (or otherwise disagree) with the NETCONF related standards track documents we produce (or have produced). And as such, the fact that it describes an implementation that does not interoperate with our standard protocol spec seems VERY ODD to me. And that is a point that we as WG can (and probably should) have an opinion on. Bert > /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 Sep 2 07:34:06 2008 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 B55BB3A6908; Tue, 2 Sep 2008 07:34:06 -0700 (PDT) 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 8BAC03A6908 for ; Tue, 2 Sep 2008 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=0.981, BAYES_00=-2.599, STOX_REPLY_TYPE=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 tY7LThLDMf3T for ; Tue, 2 Sep 2008 07:34:05 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 40D4D3A635F for ; Tue, 2 Sep 2008 07:34:03 -0700 (PDT) Received: (qmail 95289 invoked from network); 2 Sep 2008 14:33:27 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 14:33:27 -0000 Message-ID: <674D06A979CB488A92F2FEF594F75BC8@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <910D11524E714598B6CC5B5ACC075834@BertLaptop> <20080902142808.GA6978@elstar.local> In-Reply-To: <20080902142808.GA6978@elstar.local> Date: Tue, 2 Sep 2008 16:32:47 +0200 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 Cc: tomoyuki.iijima@alaxala.com, Pasi.Eronen@nokia.com, netconf@ietf.org Subject: Re: [Netconf] NETCONF over SOAP issuewithdraft-iijima-netconf-soap-implementation-10 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 Inline ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Bert Wijnen (IETF)" Cc: "Romascanu, Dan (Dan)" ; ; ; Sent: Tuesday, September 02, 2008 4:28 PM Subject: Re: [Netconf] NETCONF over SOAP issuewithdraft-iijima-netconf-soap-implementation-10 > On Tue, Sep 02, 2008 at 03:57:00PM +0200, Bert Wijnen (IETF) wrote: > >> Personally I am somewhat worried if we publish "implementation >> experience of Netconf over SOAP" if it is not interoperable with the >> NETCONF over SOAP standards track specification!!!! Even if that is >> spelled out clearly. > > I tend to agree. I personally don't care much about the SOAP interface > and as such I did not bother to read this document carefully. > > Looking at it now, it strikes me a little bit when the document talks > about file names such as "netconf-soap_1.0.wsdl" in section 4 under > 'Guidelines for Developing NETCONF Clients and Servers'. It seems the > authors document in quite some detail their specific implementation > and I am not sure this belongs into an RFC - how stable is all this > going to be? The same goes to the discussion of build files etc. > which I personally find pretty out of scope for RFCs. > It is not us (NETCONF WG) who have anything to say about such content (as individuals, we can do so of course). As a WG however, we have the duty and right to make sure that the document does not conflict (or otherwise disagree) with the NETCONF related standards track documents we produce (or have produced). And as such, the fact that it describes an implementation that does not interoperate with our standard protocol spec seems VERY ODD to me. And that is a point that we as WG can (and probably should) have an opinion on. Bert > /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 Sep 2 08:40:03 2008 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 0723B3A6BAB; Tue, 2 Sep 2008 08:40:03 -0700 (PDT) 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 5426F3A6BAB for ; Tue, 2 Sep 2008 08:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_50=0.001, J_CHICKENPOX_74=0.6, STOX_REPLY_TYPE=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 uHkCAgqzxC-Q for ; Tue, 2 Sep 2008 08:39:56 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 967CA3A6803 for ; Tue, 2 Sep 2008 08:39:53 -0700 (PDT) Received: (qmail 99529 invoked from network); 2 Sep 2008 15:39:59 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 15:39:59 -0000 Message-ID: <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> In-Reply-To: Date: Tue, 2 Sep 2008 17:39:18 +0200 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: Re: [Netconf] My review for: WGLC fordraft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I see (in appendix B): grouping configName { description "A choice to list the datastore names for NETCONF. This could be moved to a netconf.yang module."; And wonder if we want to leave that DESCRIPTION as is or not? Should we not decide to leae it here (in this module) for now and removed that 2nd sentence? Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 08:40:03 2008 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 0723B3A6BAB; Tue, 2 Sep 2008 08:40:03 -0700 (PDT) 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 5426F3A6BAB for ; Tue, 2 Sep 2008 08:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_50=0.001, J_CHICKENPOX_74=0.6, STOX_REPLY_TYPE=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 uHkCAgqzxC-Q for ; Tue, 2 Sep 2008 08:39:56 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 967CA3A6803 for ; Tue, 2 Sep 2008 08:39:53 -0700 (PDT) Received: (qmail 99529 invoked from network); 2 Sep 2008 15:39:59 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 2 Sep 2008 15:39:59 -0000 Message-ID: <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> From: "Bert Wijnen \(IETF\)" To: References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> In-Reply-To: Date: Tue, 2 Sep 2008 17:39:18 +0200 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: Re: [Netconf] My review for: WGLC fordraft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org I see (in appendix B): grouping configName { description "A choice to list the datastore names for NETCONF. This could be moved to a netconf.yang module."; And wonder if we want to leave that DESCRIPTION as is or not? Should we not decide to leae it here (in this module) for now and removed that 2nd sentence? Bert _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 08:57:12 2008 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 C69803A6BAB; Tue, 2 Sep 2008 08:57:12 -0700 (PDT) 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 D586B3A6BB4 for ; Tue, 2 Sep 2008 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 XMoKXh7jlXYs for ; Tue, 2 Sep 2008 08:57:07 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id CCB533A6BCE for ; Tue, 2 Sep 2008 08:57:07 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 9nVR1a0050QkzPwAArx846; Tue, 02 Sep 2008 15:57:08 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 9rx61a00H4HwxpC8Nrx7lQ; Tue, 02 Sep 2008 15:57:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=zpbnjeM6tE7NK1nqnzYA:9 a=BbjotAzf_Li0zeqW5aIA:7 a=8j52_nxi-A559eHkv5BwdGUqL9MA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen \(IETF\)'" , "'tom.petch'" , "'Netconf'" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com><015801c90cd2$85b88e20$0601a8c0@allison> <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Date: Tue, 2 Sep 2008 11:57:06 -0400 Message-ID: <009501c90d14$8d8ec1e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckNBInR2kyNAI3gRUm8Z/SK0tABsAADnD9w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Subject: Re: [Netconf] netconf-tls 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, An AD raised a DISCUSS during the IESG approval process and pointed to the hodges draft. As Tom points out, the draft is expired. My primary concern is that we do not develop multiple /TLS solutions, all with different rules for matching the identities used in certificates, and with different required cipher-suites, etc. We should be trying to make it easier for operators to manage the security for NM protocols, not harder. Syslog WG has a TLS-transport draft currently under consideration by the IESG, and the IESG has raised a number of "late surprises" related to that draft. A (D)TLS transport draft has been published and brought into some discussion in the ISMS WG. CAPWAP uses DTLS. IPFIX supports a TLS transport, IIRC. I think the worse thing we could do is ignore what has gone before and develop a netconf-silo with its own TLS solution that is inconsistent with other IETF NM protocol transports. I recommend the author of the netconf/tls draft review the discussions in the syslog WG to see whether the discussions are relevant to netconf or not, and to determine whether the compliance requirements for netconf/tls are consistent with other /tls proposals - especially the ones already approved by, or in the process of approval by, the IESG. I don't care whether the hodges draft is used as the basis for the evaluation, but will warn that at least one AD seems to be using that draft as their basis for evaluation. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, September 02, 2008 9:37 AM > To: tom.petch; Netconf > Subject: Re: [Netconf] netconf-tls > > Tom, just to be sure I understand your response correctly. > > You are saying that we should NOT take the > draft-hodges-server-ident-check > document as a good source of things to consider, right? > > Bert > ----- Original Message ----- > From: "tom.petch" > To: "David Harrington" ; > Sent: Tuesday, September 02, 2008 9:59 AM > Subject: Re: [Netconf] netconf-tls > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Thursday, August 28, 2008 4:39 PM > > Subject: [Netconf] netconf-tls > > > > > >> The syslog WG is finalizing their document on syslog-tls. The IESG > >> review raised a number of DISCUSSES for important security issues. > >> > >> draft-hodges-server-ident-check-00 is an attempt to standardize how > >> applications check server identities using TLS. > > > > I am not comfortable with this I-D and do not see it as a > good reference > > without > > substantially more discussion; its focus is much narrower > than the title > > suggests. Trouble is, where can that discussion be? The > TLS list has > > shown > > itself reluctant to discuss such issues and indeed, the I-D, while > > TLS-centric, > > does make claims to have a wider scope. I did e-mail the > AD who raised > > the > > DISCUSS on syslog-tls citing this expired I-D asking for a wider > > discussion but > > as yet, nothing has materialised. So for the moment, I > would not use it, > > but > > rather go back to the many RFC already published with such sections. > > > > Tom Petch > > > > > > > I > > strongly > > recommend > >> the editors of netconf-tls pay close attention to the work > being done > >> for syslog-tls and the hodges draft, to ensure consistency and > >> compatibility and to ease the approval path. > >> > >> David Harrington > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> dharrington@huawei.com > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 08:57:12 2008 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 C69803A6BAB; Tue, 2 Sep 2008 08:57:12 -0700 (PDT) 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 D586B3A6BB4 for ; Tue, 2 Sep 2008 08:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 XMoKXh7jlXYs for ; Tue, 2 Sep 2008 08:57:07 -0700 (PDT) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id CCB533A6BCE for ; Tue, 2 Sep 2008 08:57:07 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id 9nVR1a0050QkzPwAArx846; Tue, 02 Sep 2008 15:57:08 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id 9rx61a00H4HwxpC8Nrx7lQ; Tue, 02 Sep 2008 15:57:08 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=zpbnjeM6tE7NK1nqnzYA:9 a=BbjotAzf_Li0zeqW5aIA:7 a=8j52_nxi-A559eHkv5BwdGUqL9MA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: "'Bert Wijnen \(IETF\)'" , "'tom.petch'" , "'Netconf'" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com><015801c90cd2$85b88e20$0601a8c0@allison> <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Date: Tue, 2 Sep 2008 11:57:06 -0400 Message-ID: <009501c90d14$8d8ec1e0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckNBInR2kyNAI3gRUm8Z/SK0tABsAADnD9w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Subject: Re: [Netconf] netconf-tls 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, An AD raised a DISCUSS during the IESG approval process and pointed to the hodges draft. As Tom points out, the draft is expired. My primary concern is that we do not develop multiple /TLS solutions, all with different rules for matching the identities used in certificates, and with different required cipher-suites, etc. We should be trying to make it easier for operators to manage the security for NM protocols, not harder. Syslog WG has a TLS-transport draft currently under consideration by the IESG, and the IESG has raised a number of "late surprises" related to that draft. A (D)TLS transport draft has been published and brought into some discussion in the ISMS WG. CAPWAP uses DTLS. IPFIX supports a TLS transport, IIRC. I think the worse thing we could do is ignore what has gone before and develop a netconf-silo with its own TLS solution that is inconsistent with other IETF NM protocol transports. I recommend the author of the netconf/tls draft review the discussions in the syslog WG to see whether the discussions are relevant to netconf or not, and to determine whether the compliance requirements for netconf/tls are consistent with other /tls proposals - especially the ones already approved by, or in the process of approval by, the IESG. I don't care whether the hodges draft is used as the basis for the evaluation, but will warn that at least one AD seems to be using that draft as their basis for evaluation. dbh > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of Bert Wijnen (IETF) > Sent: Tuesday, September 02, 2008 9:37 AM > To: tom.petch; Netconf > Subject: Re: [Netconf] netconf-tls > > Tom, just to be sure I understand your response correctly. > > You are saying that we should NOT take the > draft-hodges-server-ident-check > document as a good source of things to consider, right? > > Bert > ----- Original Message ----- > From: "tom.petch" > To: "David Harrington" ; > Sent: Tuesday, September 02, 2008 9:59 AM > Subject: Re: [Netconf] netconf-tls > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Thursday, August 28, 2008 4:39 PM > > Subject: [Netconf] netconf-tls > > > > > >> The syslog WG is finalizing their document on syslog-tls. The IESG > >> review raised a number of DISCUSSES for important security issues. > >> > >> draft-hodges-server-ident-check-00 is an attempt to standardize how > >> applications check server identities using TLS. > > > > I am not comfortable with this I-D and do not see it as a > good reference > > without > > substantially more discussion; its focus is much narrower > than the title > > suggests. Trouble is, where can that discussion be? The > TLS list has > > shown > > itself reluctant to discuss such issues and indeed, the I-D, while > > TLS-centric, > > does make claims to have a wider scope. I did e-mail the > AD who raised > > the > > DISCUSS on syslog-tls citing this expired I-D asking for a wider > > discussion but > > as yet, nothing has materialised. So for the moment, I > would not use it, > > but > > rather go back to the many RFC already published with such sections. > > > > Tom Petch > > > > > > > I > > strongly > > recommend > >> the editors of netconf-tls pay close attention to the work > being done > >> for syslog-tls and the hodges draft, to ensure consistency and > >> compatibility and to ease the approval path. > >> > >> David Harrington > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> dharrington@huawei.com > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 10:56:53 2008 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 BAEF83A6405; Tue, 2 Sep 2008 10:56:53 -0700 (PDT) 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 62ACB3A6405 for ; Tue, 2 Sep 2008 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 Bq+i6OXQ38Ew for ; Tue, 2 Sep 2008 10:56:51 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 35EF63A63C9 for ; Tue, 2 Sep 2008 10:56:51 -0700 (PDT) X-Trace: 165093379/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.139.7 X-SBRS: None X-RemoteIP: 62.188.139.7 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFANQavUg+vIsH/2dsb2JhbACDRziIDKZ7A4Fm X-IronPort-AV: E=Sophos;i="4.32,318,1217804400"; d="scan'208";a="165093379" X-IP-Direction: IN Received: from 1cust7.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.7]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 18:56:53 +0100 Message-ID: <001201c90d1b$f2397660$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen \(IETF\)" , "Netconf" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> <015801c90cd2$85b88e20$0601a8c0@allison> <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Date: Tue, 2 Sep 2008 18:16:06 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "tom.petch" ; "Netconf" Sent: Tuesday, September 02, 2008 3:36 PM Subject: Re: [Netconf] netconf-tls > Tom, just to be sure I understand your response correctly. > > You are saying that we should NOT take the draft-hodges-server-ident-check > document as a good source of things to consider, right? Sorry, I was being too coy. Yes, I think that more discussion of this I-D is needed before it will serve as a reference for authors of '... over TLS..' I-Ds. It claims to be about verifying server identity in PKI (why not clients, what about certificates without PKI?) and yet its scope is narrower, largely being about string comparison. In syslog-tls, the discussions have ranged wider (fingerprints, formats of locally configured names, what to do with multiple names in the certificate, roots of chains, ...) and my sense is that much of this has come from above, ie is seen as a requirement of the IETF for a TLS specification (in the third quarter of 2008). The I-D is lifted from RFC4513 and may be adequate for that context but not IMO for the IETF at large. Tom Petch > Bert > ----- Original Message ----- > From: "tom.petch" > To: "David Harrington" ; > Sent: Tuesday, September 02, 2008 9:59 AM > Subject: Re: [Netconf] netconf-tls > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Thursday, August 28, 2008 4:39 PM > > Subject: [Netconf] netconf-tls > > > > > >> The syslog WG is finalizing their document on syslog-tls. The IESG > >> review raised a number of DISCUSSES for important security issues. > >> > >> draft-hodges-server-ident-check-00 is an attempt to standardize how > >> applications check server identities using TLS. > > > > I am not comfortable with this I-D and do not see it as a good reference > > without > > substantially more discussion; its focus is much narrower than the title > > suggests. Trouble is, where can that discussion be? The TLS list has > > shown > > itself reluctant to discuss such issues and indeed, the I-D, while > > TLS-centric, > > does make claims to have a wider scope. I did e-mail the AD who raised > > the > > DISCUSS on syslog-tls citing this expired I-D asking for a wider > > discussion but > > as yet, nothing has materialised. So for the moment, I would not use it, > > but > > rather go back to the many RFC already published with such sections. > > > > Tom Petch > > > > > > I > > strongly > > recommend > >> the editors of netconf-tls pay close attention to the work being done > >> for syslog-tls and the hodges draft, to ensure consistency and > >> compatibility and to ease the approval path. > >> > >> David Harrington > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> dharrington@huawei.com > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 10:56:53 2008 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 BAEF83A6405; Tue, 2 Sep 2008 10:56:53 -0700 (PDT) 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 62ACB3A6405 for ; Tue, 2 Sep 2008 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 Bq+i6OXQ38Ew for ; Tue, 2 Sep 2008 10:56:51 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 35EF63A63C9 for ; Tue, 2 Sep 2008 10:56:51 -0700 (PDT) X-Trace: 165093379/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.139.7 X-SBRS: None X-RemoteIP: 62.188.139.7 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFANQavUg+vIsH/2dsb2JhbACDRziIDKZ7A4Fm X-IronPort-AV: E=Sophos;i="4.32,318,1217804400"; d="scan'208";a="165093379" X-IP-Direction: IN Received: from 1cust7.tnt10.lnd4.gbr.da.uu.net (HELO allison) ([62.188.139.7]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 18:56:53 +0100 Message-ID: <001201c90d1b$f2397660$0601a8c0@allison> From: "tom.petch" To: "Bert Wijnen \(IETF\)" , "Netconf" References: <036301c9091b$dc473170$0600a8c0@china.huawei.com> <015801c90cd2$85b88e20$0601a8c0@allison> <3187848565A54110A8F711E8BE9F0D04@BertLaptop> Date: Tue, 2 Sep 2008 18:16:06 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Netconf] netconf-tls X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "Bert Wijnen (IETF)" To: "tom.petch" ; "Netconf" Sent: Tuesday, September 02, 2008 3:36 PM Subject: Re: [Netconf] netconf-tls > Tom, just to be sure I understand your response correctly. > > You are saying that we should NOT take the draft-hodges-server-ident-check > document as a good source of things to consider, right? Sorry, I was being too coy. Yes, I think that more discussion of this I-D is needed before it will serve as a reference for authors of '... over TLS..' I-Ds. It claims to be about verifying server identity in PKI (why not clients, what about certificates without PKI?) and yet its scope is narrower, largely being about string comparison. In syslog-tls, the discussions have ranged wider (fingerprints, formats of locally configured names, what to do with multiple names in the certificate, roots of chains, ...) and my sense is that much of this has come from above, ie is seen as a requirement of the IETF for a TLS specification (in the third quarter of 2008). The I-D is lifted from RFC4513 and may be adequate for that context but not IMO for the IETF at large. Tom Petch > Bert > ----- Original Message ----- > From: "tom.petch" > To: "David Harrington" ; > Sent: Tuesday, September 02, 2008 9:59 AM > Subject: Re: [Netconf] netconf-tls > > > > ----- Original Message ----- > > From: "David Harrington" > > To: > > Sent: Thursday, August 28, 2008 4:39 PM > > Subject: [Netconf] netconf-tls > > > > > >> The syslog WG is finalizing their document on syslog-tls. The IESG > >> review raised a number of DISCUSSES for important security issues. > >> > >> draft-hodges-server-ident-check-00 is an attempt to standardize how > >> applications check server identities using TLS. > > > > I am not comfortable with this I-D and do not see it as a good reference > > without > > substantially more discussion; its focus is much narrower than the title > > suggests. Trouble is, where can that discussion be? The TLS list has > > shown > > itself reluctant to discuss such issues and indeed, the I-D, while > > TLS-centric, > > does make claims to have a wider scope. I did e-mail the AD who raised > > the > > DISCUSS on syslog-tls citing this expired I-D asking for a wider > > discussion but > > as yet, nothing has materialised. So for the moment, I would not use it, > > but > > rather go back to the many RFC already published with such sections. > > > > Tom Petch > > > > > > I > > strongly > > recommend > >> the editors of netconf-tls pay close attention to the work being done > >> for syslog-tls and the hodges draft, to ensure consistency and > >> compatibility and to ease the approval path. > >> > >> David Harrington > >> dbharrington@comcast.net > >> ietfdbh@comcast.net > >> dharrington@huawei.com > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 23:10:16 2008 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 6C3283A6BEF; Tue, 2 Sep 2008 23:10:16 -0700 (PDT) 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 2D38B3A6A61 for ; Tue, 2 Sep 2008 23:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 JBJTu0zZ9sjk for ; Tue, 2 Sep 2008 23:10:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4EC233A699A for ; Tue, 2 Sep 2008 23:10:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 80E4C76C2AB; Wed, 3 Sep 2008 08:10:18 +0200 (CEST) Date: Wed, 03 Sep 2008 08:10:50 +0200 (CEST) Message-Id: <20080903.081050.223572001.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC fordraft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > I see (in appendix B): > > grouping configName { > description > "A choice to list the datastore names for NETCONF. > This could be moved to a netconf.yang module."; > > > And wonder if we want to leave that DESCRIPTION as is or not? > Should we not decide to leae it here (in this module) for now > and removed that 2nd sentence? Yes. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 2 23:10:16 2008 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 6C3283A6BEF; Tue, 2 Sep 2008 23:10:16 -0700 (PDT) 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 2D38B3A6A61 for ; Tue, 2 Sep 2008 23:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 JBJTu0zZ9sjk for ; Tue, 2 Sep 2008 23:10:14 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 4EC233A699A for ; Tue, 2 Sep 2008 23:10:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 80E4C76C2AB; Wed, 3 Sep 2008 08:10:18 +0200 (CEST) Date: Wed, 03 Sep 2008 08:10:50 +0200 (CEST) Message-Id: <20080903.081050.223572001.mbj@tail-f.com> To: bertietf@bwijnen.net From: Martin Bjorklund In-Reply-To: <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> References: <2E7964AA249F4CEBB499F03FEE7EDE1B@BertLaptop> <4E148AD409774C6BA3DD86E4353FAD71@BertLaptop> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] My review for: WGLC fordraft-ietf-netconf-partial-lock-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "Bert Wijnen \(IETF\)" wrote: > I see (in appendix B): > > grouping configName { > description > "A choice to list the datastore names for NETCONF. > This could be moved to a netconf.yang module."; > > > And wonder if we want to leave that DESCRIPTION as is or not? > Should we not decide to leae it here (in this module) for now > and removed that 2nd sentence? Yes. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 4 02:51:51 2008 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 61BD13A6E41; Thu, 4 Sep 2008 02:51:51 -0700 (PDT) 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 EA69D3A6E3D for ; Thu, 4 Sep 2008 02:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=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 n1djutZmGp6F for ; Thu, 4 Sep 2008 02:51:48 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 1B8DF3A6DF2 for ; Thu, 4 Sep 2008 02:51:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="27460146" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 04 Sep 2008 09:51:22 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m849pLoP017795; Thu, 4 Sep 2008 17:51:21 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m849pF3v019955; Thu, 4 Sep 2008 09:51:21 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Sep 2008 17:51:15 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 17:52:38 +0800 Message-ID: In-Reply-To: <046b01c90904$89d003c0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] continue-on-error Thread-Index: AckJDed/f05jbWa6S+qGzr/m7DTSnQFY9grQ References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> From: "James Balestriere (jbalestr)" To: "tom.petch" , "Andy Bierman" , "Phil Shafer" X-OriginalArrivalTime: 04 Sep 2008 09:51:15.0072 (UTC) FILETIME=[C5496800:01C90E73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3612; t=1220521881; x=1221385881; c=relaxed/simple; s=hkgdkim2001; 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]=20continue-on-error |Sender:=20; bh=jh9ds2wmv/mVleLLBx+uyhymg6cl1xOr7uFM+pOkmlI=; b=sQomi5v3NxamZWVBCL/UlMXRCXqaRXjZC1XdSiFGA2tuVH+FF0rdtPtHAI SJBf6sU8txXHXC5uBip+gAbXUxiMrqBsUFIkSD5uBb9xywtT/XGKeRh6kBWf N/6g3DYNzHnkDD4YSUyYwP16wUcWjaU7yMgIavwinWa9Y+y7iFzvU=; Authentication-Results: hkg-dkim-2; header.From=jbalestr@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 Surely we have to check the well-formedness of the XML before we execute on it especially for config. We are talking about applying configuration to a box. You would think having valid XML framing would be critical in interpreting the context correctly. When you are displaying badly formed HTML what's the worst that can happen, it doesn't align on screen properly, but if you apply config to the wrong interface on a box because you guessed the wrong XML context you could seriously disrupt your network. I assumed the continue-on-error would refer to semantic errors in the config we are trying to apply. e.g. lets say I configured a duplicate ip-address, I could undo/ignore that one config and just keep applying everything else, but the XML must be well formed. James. > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of tom.petch > Sent: Thursday, 28 August 2008 9:51 PM > To: Andy Bierman; Phil Shafer > Cc: NETCONF > Subject: Re: [Netconf] continue-on-error > > ----- Original Message ----- > From: "Andy Bierman" > To: "Phil Shafer" > Cc: "NETCONF" > Sent: Saturday, August 23, 2008 12:29 AM > Subject: Re: [Netconf] continue-on-error > > > Phil Shafer wrote: > > > Andy Bierman writes: > > >> But first, does anybody implement continue-on-error, > > >> and if so, what does it really mean in your agent? > > > > > > "continue-on-error" means "do your best to keep going". > > > "your best" can't be defined easily, since you're > > > facing input that contains errors. > > > > pretty vague. > > I used to think it meant there are no errors > > detected in syntax or constraints, but if > > an error occurred trying to apply the > > (e.g., malloc failed), then try to continue. > > > > Clearly this is the intent if test-option 'test-then-set' is true. > > (It actually requires more -- a must succeed too.) > > > > But for my internal operation, using the > > same infrastructure as , I want to > > skip over syntax errors in one subtree if another subtree > > is good. > > > > You are suggesting that even for , skipping > > over invalid well-formed XML is OK for 'continue-on-error'. > > Seems fine to me, since the spec doesn't really say. > > > 'continue-on-error' is what (almost?) every HTML browser > does. Look at the > source for web sites and many if not most is invalid, at > least in the sense of > using mismatched start and end tags, eg for

>

  • etc so there > seems a general implementation rule that if a is > missing, supply it. > > Easier to do for syntax errors than for misspelt QNaems. > > The better systems I am used to have a classification of > errors - eg minor, > severe, catastrophic - with different actions specifiable for > each. The systems > I dislike most are the ones that continue on catastrophic > errors thus generating > hundreds or thousands of error messages for one typo > (something I see with SMI > checkers:-( > > Tom Petch > > > > > > Thanks, > > > Phil > > > > > > > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 4 02:51:51 2008 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 61BD13A6E41; Thu, 4 Sep 2008 02:51:51 -0700 (PDT) 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 EA69D3A6E3D for ; Thu, 4 Sep 2008 02:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=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 n1djutZmGp6F for ; Thu, 4 Sep 2008 02:51:48 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 1B8DF3A6DF2 for ; Thu, 4 Sep 2008 02:51:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="27460146" Received: from hkg-dkim-2.cisco.com ([10.75.231.163]) by ind-iport-1.cisco.com with ESMTP; 04 Sep 2008 09:51:22 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m849pLoP017795; Thu, 4 Sep 2008 17:51:21 +0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m849pF3v019955; Thu, 4 Sep 2008 09:51:21 GMT Received: from xmb-hkg-411.apac.cisco.com ([64.104.123.77]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Sep 2008 17:51:15 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 17:52:38 +0800 Message-ID: In-Reply-To: <046b01c90904$89d003c0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] continue-on-error Thread-Index: AckJDed/f05jbWa6S+qGzr/m7DTSnQFY9grQ References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> From: "James Balestriere (jbalestr)" To: "tom.petch" , "Andy Bierman" , "Phil Shafer" X-OriginalArrivalTime: 04 Sep 2008 09:51:15.0072 (UTC) FILETIME=[C5496800:01C90E73] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3612; t=1220521881; x=1221385881; c=relaxed/simple; s=hkgdkim2001; 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]=20continue-on-error |Sender:=20; bh=jh9ds2wmv/mVleLLBx+uyhymg6cl1xOr7uFM+pOkmlI=; b=sQomi5v3NxamZWVBCL/UlMXRCXqaRXjZC1XdSiFGA2tuVH+FF0rdtPtHAI SJBf6sU8txXHXC5uBip+gAbXUxiMrqBsUFIkSD5uBb9xywtT/XGKeRh6kBWf N/6g3DYNzHnkDD4YSUyYwP16wUcWjaU7yMgIavwinWa9Y+y7iFzvU=; Authentication-Results: hkg-dkim-2; header.From=jbalestr@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim2001 verified; ); Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 Surely we have to check the well-formedness of the XML before we execute on it especially for config. We are talking about applying configuration to a box. You would think having valid XML framing would be critical in interpreting the context correctly. When you are displaying badly formed HTML what's the worst that can happen, it doesn't align on screen properly, but if you apply config to the wrong interface on a box because you guessed the wrong XML context you could seriously disrupt your network. I assumed the continue-on-error would refer to semantic errors in the config we are trying to apply. e.g. lets say I configured a duplicate ip-address, I could undo/ignore that one config and just keep applying everything else, but the XML must be well formed. James. > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of tom.petch > Sent: Thursday, 28 August 2008 9:51 PM > To: Andy Bierman; Phil Shafer > Cc: NETCONF > Subject: Re: [Netconf] continue-on-error > > ----- Original Message ----- > From: "Andy Bierman" > To: "Phil Shafer" > Cc: "NETCONF" > Sent: Saturday, August 23, 2008 12:29 AM > Subject: Re: [Netconf] continue-on-error > > > Phil Shafer wrote: > > > Andy Bierman writes: > > >> But first, does anybody implement continue-on-error, > > >> and if so, what does it really mean in your agent? > > > > > > "continue-on-error" means "do your best to keep going". > > > "your best" can't be defined easily, since you're > > > facing input that contains errors. > > > > pretty vague. > > I used to think it meant there are no errors > > detected in syntax or constraints, but if > > an error occurred trying to apply the > > (e.g., malloc failed), then try to continue. > > > > Clearly this is the intent if test-option 'test-then-set' is true. > > (It actually requires more -- a must succeed too.) > > > > But for my internal operation, using the > > same infrastructure as , I want to > > skip over syntax errors in one subtree if another subtree > > is good. > > > > You are suggesting that even for , skipping > > over invalid well-formed XML is OK for 'continue-on-error'. > > Seems fine to me, since the spec doesn't really say. > > > 'continue-on-error' is what (almost?) every HTML browser > does. Look at the > source for web sites and many if not most is invalid, at > least in the sense of > using mismatched start and end tags, eg for

    >

  • etc so there > seems a general implementation rule that if a is > missing, supply it. > > Easier to do for syntax errors than for misspelt QNaems. > > The better systems I am used to have a classification of > errors - eg minor, > severe, catastrophic - with different actions specifiable for > each. The systems > I dislike most are the ones that continue on catastrophic > errors thus generating > hundreds or thousands of error messages for one typo > (something I see with SMI > checkers:-( > > Tom Petch > > > > > > Thanks, > > > Phil > > > > > > > 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 > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 4 04:30:02 2008 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 D365B3A6923; Thu, 4 Sep 2008 04:30:02 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 20DB03A6923; Thu, 4 Sep 2008 04:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080904113002.20DB03A6923@core3.amsl.com> Date: Thu, 4 Sep 2008 04:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over Transport Layer Security (TLS) Author(s) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-04.txt Pages : 10 Date : 2008-09-04 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-tls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-04042654.I-D@ietf.org> --NextPart 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-- From netconf-bounces@ietf.org Thu Sep 4 04:30:02 2008 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 D365B3A6923; Thu, 4 Sep 2008 04:30:02 -0700 (PDT) X-Original-To: netconf@ietf.org Delivered-To: netconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 20DB03A6923; Thu, 4 Sep 2008 04:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080904113002.20DB03A6923@core3.amsl.com> Date: Thu, 4 Sep 2008 04:30:02 -0700 (PDT) Cc: netconf@ietf.org Subject: [Netconf] I-D Action:draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : NETCONF over Transport Layer Security (TLS) Author(s) : M. Badra, I. Hajjeh Filename : draft-ietf-netconf-tls-04.txt Pages : 10 Date : 2008-09-04 The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices. This document describes how to use the Transport Layer Protocol (TLS) to secure NETCONF exchanges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netconf-tls-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-09-04042654.I-D@ietf.org> --NextPart 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-- From netconf-bounces@ietf.org Thu Sep 4 04:48:32 2008 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 AF0FF3A6DCB; Thu, 4 Sep 2008 04:48:32 -0700 (PDT) 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 16D6F3A6DAA for ; Thu, 4 Sep 2008 04:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_FR=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 Y5pZXMaVul3L for ; Thu, 4 Sep 2008 04:48:31 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id D38E73A6D92 for ; Thu, 4 Sep 2008 04:48:24 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m84CmYjl643202 for ; Thu, 4 Sep 2008 13:48:35 +0100 Message-ID: <48BFCAD2.4070204@isima.fr> Date: Thu, 04 Sep 2008 13:47:30 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netconf@ietf.org References: <20080904113002.20DB03A6923@core3.amsl.com> In-Reply-To: <20080904113002.20DB03A6923@core3.amsl.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Sep 2008 13:48:35 +0100 (WEST) Subject: [Netconf] Netconf over TLS: new version, please comment 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 Dear all I posted a new version of "Netconf over TLS" document. It incorporates the Security AD reviews and suggestions (e.g., removing the password-based authentication). Currently, there is a discussion on the syslog mailing list regarding the client/server identity check and the authorization when syslog is used over TLS. "Netconf over TLS" applies the rules described in RFC4642 to check the server/client identity (There rules are equivalent to those described in RFC4513, and recently in the I-D draft-hodges-server-ident-check-00). But RFC4642 doesn't discuss the authorization. Please comment on that new version and kindly say your opinion regarding the identity check; the document cannot move forward without your input and contribution. Best regards, Mohamad Badra CNRS - LIMOS Laboratory Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-04.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 4 04:48:32 2008 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 AF0FF3A6DCB; Thu, 4 Sep 2008 04:48:32 -0700 (PDT) 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 16D6F3A6DAA for ; Thu, 4 Sep 2008 04:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HELO_EQ_FR=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 Y5pZXMaVul3L for ; Thu, 4 Sep 2008 04:48:31 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id D38E73A6D92 for ; Thu, 4 Sep 2008 04:48:24 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m84CmYjl643202 for ; Thu, 4 Sep 2008 13:48:35 +0100 Message-ID: <48BFCAD2.4070204@isima.fr> Date: Thu, 04 Sep 2008 13:47:30 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: netconf@ietf.org References: <20080904113002.20DB03A6923@core3.amsl.com> In-Reply-To: <20080904113002.20DB03A6923@core3.amsl.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Thu, 04 Sep 2008 13:48:35 +0100 (WEST) Subject: [Netconf] Netconf over TLS: new version, please comment 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 Dear all I posted a new version of "Netconf over TLS" document. It incorporates the Security AD reviews and suggestions (e.g., removing the password-based authentication). Currently, there is a discussion on the syslog mailing list regarding the client/server identity check and the authorization when syslog is used over TLS. "Netconf over TLS" applies the rules described in RFC4642 to check the server/client identity (There rules are equivalent to those described in RFC4513, and recently in the I-D draft-hodges-server-ident-check-00). But RFC4642 doesn't discuss the authorization. Please comment on that new version and kindly say your opinion regarding the identity check; the document cannot move forward without your input and contribution. Best regards, Mohamad Badra CNRS - LIMOS Laboratory Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-netconf-tls-04.txt _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 4 06:50:24 2008 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 5F9EA3A6BC4; Thu, 4 Sep 2008 06:50:24 -0700 (PDT) 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 C02C63A68DA for ; Thu, 4 Sep 2008 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDsGe+cFRKRz for ; Thu, 4 Sep 2008 06:50:19 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 4AE2A3A696F for ; Thu, 4 Sep 2008 06:50:19 -0700 (PDT) Received: (qmail 69152 invoked from network); 4 Sep 2008 13:49:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2008 13:49:49 -0000 X-YMail-OSG: blpnXsEVM1kYCIED9EhsNwLhr5XBIiUCsYV0qURUvozYcYbhnU8.g2WQ3T4GdXumVvTXFEum8k7aiiaarOt7JXcZ7RCl0NhMQdozqWHfFw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BFE77C.4050004@netconfcentral.com> Date: Thu, 04 Sep 2008 06:49:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "James Balestriere (jbalestr)" References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> In-Reply-To: Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 James Balestriere (jbalestr) wrote: > Surely we have to check the well-formedness of the XML before we execute > on it especially > for config. We are talking about applying configuration to a box. You > would think having > valid XML framing would be critical in interpreting the context > correctly. When you are displaying > badly formed HTML what's the worst that can happen, it doesn't align on > screen properly, > but if you apply config to the wrong interface on a box because you > guessed the wrong XML context > you could seriously disrupt your network. > > I assumed the continue-on-error would refer to semantic errors in the > config we are trying > to apply. e.g. lets say I configured a duplicate ip-address, I could > undo/ignore that one config > and just keep applying everything else, but the XML must be well formed. > Well-formed XML isn't very much at all. Some library code (e.g., libxml2 xmlTextReader) doesn't even deliver malformed XML to the application. The parser can hit EOF looking for well-formed XML, etc. Phil and I were referring to invalid-value and other errors in well-formed XML. Clearly, if 'test-then-set' is selected, then no subset From netconf-bounces@ietf.org Thu Sep 4 06:50:24 2008 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 5F9EA3A6BC4; Thu, 4 Sep 2008 06:50:24 -0700 (PDT) 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 C02C63A68DA for ; Thu, 4 Sep 2008 06:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDsGe+cFRKRz for ; Thu, 4 Sep 2008 06:50:19 -0700 (PDT) Received: from smtp118.sbc.mail.sp1.yahoo.com (smtp118.sbc.mail.sp1.yahoo.com [69.147.64.91]) by core3.amsl.com (Postfix) with SMTP id 4AE2A3A696F for ; Thu, 4 Sep 2008 06:50:19 -0700 (PDT) Received: (qmail 69152 invoked from network); 4 Sep 2008 13:49:51 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.227.160 with plain) by smtp118.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2008 13:49:49 -0000 X-YMail-OSG: blpnXsEVM1kYCIED9EhsNwLhr5XBIiUCsYV0qURUvozYcYbhnU8.g2WQ3T4GdXumVvTXFEum8k7aiiaarOt7JXcZ7RCl0NhMQdozqWHfFw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48BFE77C.4050004@netconfcentral.com> Date: Thu, 04 Sep 2008 06:49:48 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "James Balestriere (jbalestr)" References: <200808202134.m7KLYLOZ003375@idle.juniper.net><48AF3DD0.7010800@netconfcentral.com> <046b01c90904$89d003c0$0601a8c0@allison> In-Reply-To: Cc: NETCONF Subject: Re: [Netconf] continue-on-error 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 James Balestriere (jbalestr) wrote: > Surely we have to check the well-formedness of the XML before we execute > on it especially > for config. We are talking about applying configuration to a box. You > would think having > valid XML framing would be critical in interpreting the context > correctly. When you are displaying > badly formed HTML what's the worst that can happen, it doesn't align on > screen properly, > but if you apply config to the wrong interface on a box because you > guessed the wrong XML context > you could seriously disrupt your network. > > I assumed the continue-on-error would refer to semantic errors in the > config we are trying > to apply. e.g. lets say I configured a duplicate ip-address, I could > undo/ignore that one config > and just keep applying everything else, but the XML must be well formed. > Well-formed XML isn't very much at all. Some library code (e.g., libxml2 xmlTextReader) doesn't even deliver malformed XML to the application. The parser can hit EOF looking for well-formed XML, etc. Phil and I were referring to invalid-value and other errors in well-formed XML. Clearly, if 'test-then-set' is selected, then no subset of the config should be applied before all of it passes all 'static' validation tests. An invalid-value should never succeed during the 'test phase' yet fail during the 'apply phase'. The original intent was to support the 'load startup config' operation found in CLI. Config file commands that cause errors don't automatically crash a router. This is not always the case in other applications, such as Apache -- if httpd.conf has unknown or invalid commands the WEB server will not start. > James. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf of the config should be applied before all of it passes all 'static' validation tests. An invalid-value should never succeed during the 'test phase' yet fail during the 'apply phase'. The original intent was to support the 'load startup config' operation found in CLI. Config file commands that cause errors don't automatically crash a router. This is not always the case in other applications, such as Apache -- if httpd.conf has unknown or invalid commands the WEB server will not start. > James. Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 8 08:04:18 2008 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 711B83A699C; Mon, 8 Sep 2008 08:04:18 -0700 (PDT) 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 E8F113A68A2 for ; Mon, 8 Sep 2008 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_50=0.001, 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 o7XYJ8ka4e09 for ; Mon, 8 Sep 2008 08:04:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E9F083A699C for ; Mon, 8 Sep 2008 08:04:07 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1967F20B5A; Mon, 8 Sep 2008 17:04:10 +0200 (CEST) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-27-48c53ee95a2c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9B5A20B49; Mon, 8 Sep 2008 17:04:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 17:04:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 17:04:08 +0200 Message-ID: <48C53EEC.4080009@ericsson.com> Date: Mon, 08 Sep 2008 17:04:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Wes Hardaker , Bert Wijnen - IETF , netconf mailing list References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080404070508010701040804" X-OriginalArrivalTime: 08 Sep 2008 15:04:08.0887 (UTC) FILETIME=[25013C70:01C911C4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] evaluation of the partial-lock document 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. --------------080404070508010701040804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Wes, Bert, Thanks for the review. Please see the answers for Wes below! If you have a look of the attached version, you can see that I also included Bert's comments. I basically accepted them all e.g. I added a list of locked-nodes to the rpc-reply. Please indicate if you still have problems with some of the issues. Balazs Wes Hardaker wrote: > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... > > > Netconf WG last call report on partial lock > =========================================== > > Author: Wes Hardaker > Date: 2008-08-26 16:50:09 PDT > >From netconf-bounces@ietf.org Mon Sep 8 08:04:18 2008 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 711B83A699C; Mon, 8 Sep 2008 08:04:18 -0700 (PDT) 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 E8F113A68A2 for ; Mon, 8 Sep 2008 08:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-1.253, BAYES_50=0.001, 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 o7XYJ8ka4e09 for ; Mon, 8 Sep 2008 08:04:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E9F083A699C for ; Mon, 8 Sep 2008 08:04:07 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1967F20B5A; Mon, 8 Sep 2008 17:04:10 +0200 (CEST) X-AuditID: c1b4fb3c-ac8cbbb0000015b5-27-48c53ee95a2c Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C9B5A20B49; Mon, 8 Sep 2008 17:04:09 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 17:04:09 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 17:04:08 +0200 Message-ID: <48C53EEC.4080009@ericsson.com> Date: Mon, 08 Sep 2008 17:04:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: Wes Hardaker , Bert Wijnen - IETF , netconf mailing list References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------080404070508010701040804" X-OriginalArrivalTime: 08 Sep 2008 15:04:08.0887 (UTC) FILETIME=[25013C70:01C911C4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [Netconf] evaluation of the partial-lock document 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. --------------080404070508010701040804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Wes, Bert, Thanks for the review. Please see the answers for Wes below! If you have a look of the attached version, you can see that I also included Bert's comments. I basically accepted them all e.g. I added a list of locked-nodes to the rpc-reply. Please indicate if you still have problems with some of the issues. Balazs Wes Hardaker wrote: > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... > > > Netconf WG last call report on partial lock > =========================================== > > Author: Wes Hardaker > Date: 2008-08-26 16:50:09 PDT > > Table Table of Contents > ================= > 1 General Notes > 2 Thoughts on: Partial locks don't cover non-existing nodes > 3 section 2.1: "Note:" wording > 4 section 2.1, starting with "As with most locking..." > 5 Question about multiple locks from the same session... > 6 Section 2.4.1.1: target: > 7 Section 2.4.1.1: text change > 8 Section 2.4.1.1: first example > 9 Side thought: netconf documents all assume a particular data model > 10 Section 2.4.1.1: 2nd to last paragraph: > 11 Section 2.4.2: > 12 Section 2.4.2, negative response: > 13 Section 2.5 > 14 Section 3, second paragraph: first sentence needs ()s or commas > 15 Comparison of xpath evaluated partial lock vs locked nodes > > > > 1 General Notes > --------------- > * Document is very well layed out and easy to understand. > It flows well and is easy to read. > * But... The English grammar could use some polishing in a few > more places than I've listed here. > + I'd recommend the authors hand it to someone that hasn't > been involved in editing for a simple polishing pass. [BALAZS]: Will try. > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... > > 2 Thoughts on: Partial locks don't cover non-existing nodes > ----------------------------------------------------------- > * (Section 2.4.1-ish) > * note: can't lock a tree part that doesn't exist yet > * There exists odd an usage case when a tree doesn't yet exist > (empty configuration). E.G., I can't lock the users tree until > at least 1 users/user exists. If I try to lock when > no subelement exists then I believe I get an error back (I'm > not even positive about this). Section 2.4.1 seems to > indicate that it'll fail since at least one of the select sets > MUST be non-empty. > + The result is that you *must* create a single before > you can lock the table, for example. IE a manager > is expected to be able to perform and understand why it's > doing the following odd sequence: > - partial-lock => failure because it's empty. > - create a joe > - partial-lock => success > - Edit users > - unlock > + This is just an odd error handling case that manegers will > have to cope with and it only exists because of the > inability to lock an empty tree. > * Section 2.4.1.2 discusses this aspect of partial-locking, but > the security implications may be that you don't have > permission to lock a parent node of for exmaple. IE, > You shouldn't have to take out lock on just because you > want to lock (and you shouldn't have to create a user > before you can lock the table). [BALAZS]: I am not sure I fully understand your comment, but here is what I think is the answer (in YANG to makes think simpler :-) If you have a data model: container USERS { list user { ... } } Here you CAN lock the container USERS even if there are no user nodes below it. The select will return the USERS node, so it will not be empty. In this case no one else can touch any of the user nodes or create a new user. > > 3 section 2.1: "Note:" wording > ------------------------------ > * First sentence isn't a complete sentence > * I'd argue this isn't just a "Note" but an interaction with > another capability and probably should be spelled out more > importantly than just as a "Note:" that implies it's just > additional information. [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / Candidate Configuration Capability > > 4 section 2.1, starting with "As with most locking..." > ------------------------------------------------------ > * Change: > * "parts of the configuration become dead-locked" => > * "parts of the configuration *could* become dead-locked" [BALAZS]: OK > > 5 Question about multiple locks from the same session... > -------------------------------------------------------- > * Is it allowed? Doesn't say one way or another... > * Consider: > of Contents > ================= > 1 General Notes > 2 Thoughts on: Partial locks don't cover non-existing nodes > 3 section 2.1: "Note:" wording > 4 section 2.1, starting with "As with most locking..." > 5 Question about multiple locks from the same session... > 6 Section 2.4.1.1: target: > 7 Section 2.4.1.1: text change > 8 Section 2.4.1.1: first example > 9 Side thought: netconf documents all assume a particular data model > 10 Section 2.4.1.1: 2nd to last paragraph: > 11 Section 2.4.2: > 12 Section 2.4.2, negative response: > 13 Section 2.5 > 14 Section 3, second paragraph: first sentence needs ()s or commas > 15 Comparison of xpath evaluated partial lock vs locked nodes > > > > 1 General Notes > --------------- > * Document is very well layed out and easy to understand. > It flows well and is easy to read. > * But... The English grammar could use some polishing in a few > more places than I've listed here. > + I'd recommend the authors hand it to someone that hasn't > been involved in editing for a simple polishing pass. [BALAZS]: Will try. > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... > > 2 Thoughts on: Partial locks don't cover non-existing nodes > ----------------------------------------------------------- > * (Section 2.4.1-ish) > * note: can't lock a tree part that doesn't exist yet > * There exists odd an usage case when a tree doesn't yet exist > (empty configuration). E.G., I can't lock the users tree until > at least 1 users/user exists. If I try to lock when > no subelement exists then I believe I get an error back (I'm > not even positive about this). Section 2.4.1 seems to > indicate that it'll fail since at least one of the select sets > MUST be non-empty. > + The result is that you *must* create a single before > you can lock the table, for example. IE a manager > is expected to be able to perform and understand why it's > doing the following odd sequence: > - partial-lock => failure because it's empty. > - create a joe > - partial-lock => success > - Edit users > - unlock > + This is just an odd error handling case that manegers will > have to cope with and it only exists because of the > inability to lock an empty tree. > * Section 2.4.1.2 discusses this aspect of partial-locking, but > the security implications may be that you don't have > permission to lock a parent node of for exmaple. IE, > You shouldn't have to take out lock on just because you > want to lock (and you shouldn't have to create a user > before you can lock the table). [BALAZS]: I am not sure I fully understand your comment, but here is what I think is the answer (in YANG to makes think simpler :-) If you have a data model: container USERS { list user { ... } } Here you CAN lock the container USERS even if there are no user nodes below it. The select will return the USERS node, so it will not be empty. In this case no one else can touch any of the user nodes or create a new user. > > 3 section 2.1: "Note:" wording > ------------------------------ > * First sentence isn't a complete sentence > * I'd argue this isn't just a "Note" but an interaction with > another capability and probably should be spelled out more > importantly than just as a "Note:" that implies it's just > additional information. [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / Candidate Configuration Capability > > 4 section 2.1, starting with "As with most locking..." > ------------------------------------------------------ > * Change: > * "parts of the configuration become dead-locked" => > * "parts of the configuration *could* become dead-locked" [BALAZS]: OK > > 5 Question about multiple locks from the same session... > -------------------------------------------------------- > * Is it allowed? Doesn't say one way or another... > * Consider: > 1. lo 1. lock with one partial nodes A and B > 2. and then with another try to lock B and C > 3. Do I get an error because B is locked (by me in this session)? > 4. or now do I have multiple locks covering A, B and C? > * I *think* I get an error? > * If I do have A, B and C locked: > + and then I release the lock > + do I still have B and C locked with the second or just C > (I'd assume B and C)? > * The document discusses this ramification for but not > really well for > * It sort of implies an error further in 2.4.1.1 "If a lock is > already held on any node..." [BALAZS]: It is allowed to have multiple locks from the same session. In 2.4.1.1 will be reworded to indicate this. In 2.1 it is stated that: "A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock." Indicating that a session might have multiple locks. I will also add to 2.4.1: A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of the locks are released. > > 6 Section 2.4.1.1: target: > -------------------------- > * Wouldn't it be best to state directly: "a may > only have one parameter?" [BALAZS]: OK > > 7 Section 2.4.1.1: text change > ------------------------------ > * "If the device supports the :xpath capability as well any valid" => > * "If the device supports the :xpath capability *then* any valid" [BALAZS]: OK > > 8 Section 2.4.1.1: first example > -------------------------------- > * Shouldn't be within a scope? > * The schema seems to indicate no > * But it should (IMHO) if nothing else to match usage > which does have a parameter. > + (if memory serves this was discussed early on in netconf and > it was agreed that all targets should be directly specified > inside a named or similar parameter tag) [BALAZS]: OK > > 9 Side thought: netconf documents all assume a particular data model > -------------------------------------------------------------------- > * Is it just me, or should all the netconf documents be replaced > once a real data model exists with real example nodes to use? > * Right now all the examples give the impression that the example > RPCs will work, when in actuality they won't match the real > world data models. > + EG: /interfaces/interface[Id='eth1'] [BALAZS]: This is just an example no more. IMHO we simply can not avoid assuming some data model for now. I agree, it would be nice to later include real examples from standard modules; whether we will have the time for that? > > 10 Section 2.4.1.1: 2nd to last paragraph: > ------------------------------------------ > * Explicitly spelling out an xpath failure is nice to > understand. But in reality this should be more generic in > order to handle failing on future select type expressions > (xpath2) or other syntax errors. Maybe something like "search > expression type not supported"? [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later we will anyway have to update the RFC, and I don't see how that update would cause problems for a management system. Once it gets the error it will anyway know it failed. > + What type of error do I get back for /users/user[name='Joe [BALAZS]: Tag: invalid-value > > 11 Section 2.4.2: > ----------------- > * Nit: Replace "Example: Unlock" with "Example: Unlock a > previously created lock" > + or just remove: "Unlock" > + The title just looks a touch odd as is (incomplete). [BALAZS]: OK > > 12 Section 2.4.2, negative response: > ------------------------------------ > * So there is no way to break a lock from a different session? > Then what happens if a TCP connection drops according to the > client (or is forced to drop) but the server hasn't realck with one partial nodes A and B > 2. and then with another try to lock B and C > 3. Do I get an error because B is locked (by me in this session)? > 4. or now do I have multiple locks covering A, B and C? > * I *think* I get an error? > * If I do have A, B and C locked: > + and then I release the lock > + do I still have B and C locked with the second or just C > (I'd assume B and C)? > * The document discusses this ramification for but not > really well for > * It sort of implies an error further in 2.4.1.1 "If a lock is > already held on any node..." [BALAZS]: It is allowed to have multiple locks from the same session. In 2.4.1.1 will be reworded to indicate this. In 2.1 it is stated that: "A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock." Indicating that a session might have multiple locks. I will also add to 2.4.1: A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of the locks are released. > > 6 Section 2.4.1.1: target: > -------------------------- > * Wouldn't it be best to state directly: "a may > only have one parameter?" [BALAZS]: OK > > 7 Section 2.4.1.1: text change > ------------------------------ > * "If the device supports the :xpath capability as well any valid" => > * "If the device supports the :xpath capability *then* any valid" [BALAZS]: OK > > 8 Section 2.4.1.1: first example > -------------------------------- > * Shouldn't be within a scope? > * The schema seems to indicate no > * But it should (IMHO) if nothing else to match usage > which does have a parameter. > + (if memory serves this was discussed early on in netconf and > it was agreed that all targets should be directly specified > inside a named or similar parameter tag) [BALAZS]: OK > > 9 Side thought: netconf documents all assume a particular data model > -------------------------------------------------------------------- > * Is it just me, or should all the netconf documents be replaced > once a real data model exists with real example nodes to use? > * Right now all the examples give the impression that the example > RPCs will work, when in actuality they won't match the real > world data models. > + EG: /interfaces/interface[Id='eth1'] [BALAZS]: This is just an example no more. IMHO we simply can not avoid assuming some data model for now. I agree, it would be nice to later include real examples from standard modules; whether we will have the time for that? > > 10 Section 2.4.1.1: 2nd to last paragraph: > ------------------------------------------ > * Explicitly spelling out an xpath failure is nice to > understand. But in reality this should be more generic in > order to handle failing on future select type expressions > (xpath2) or other syntax errors. Maybe something like "search > expression type not supported"? [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later we will anyway have to update the RFC, and I don't see how that update would cause problems for a management system. Once it gets the error it will anyway know it failed. > + What type of error do I get back for /users/user[name='Joe [BALAZS]: Tag: invalid-value > > 11 Section 2.4.2: > ----------------- > * Nit: Replace "Example: Unlock" with "Example: Unlock a > previously created lock" > + or just remove: "Unlock" > + The title just looks a touch odd as is (incomplete). [BALAZS]: OK > > 12 Section 2.4.2, negative response: > ------------------------------------ > * So there is no way to break a lock from a different session? > Then what happens if a TCP connection drops according to the > client (or is forced to drop) but the server hasn't realized >ized > it's closed? > + Looks like kill-session is the solution based on later reading, > but I'd suggest spelling it out here. > + Requires access to the kill-session command to release a > hung-lock. Possibly worth mentioning in the security > expectations. [BALAZS}: OK > > 13 Section 2.5 > -------------- > * I'd spell out in no uncertain terms that any command that > modifies a datastore will be blocked, and that "includes" the > current list. The wording as is could be easily > misinterpreted to read that the current list is all you need > to worry about (which I know wasn't the intent). [BALAZS}: OK > > 14 Section 3, second paragraph: first sentence needs ()s or commas > ------------------------------------------------------------------ > around the lock types. [BALAZS}: OK > > 15 Comparison of xpath evaluated partial lock vs locked nodes > ------------------------------------------------------------- > * I'm not personally convienced still that locking existing > nodes only is the best solution for partial locking. I know > it's been debated a bunch in the past but I'm not even > convienced there is consusus on the subject. I suspect that > if you counted the number of folks that started an argument > about it the numbers wouldn't point clearly to a consensus. > Many of the arguments came at different times, which makes it > hard to count. > + That being said, letting this one go forward doesn't > prohibit a different later solution. [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad to see that you can still live with this solution. > + I'm not convienced that locking nodes is cheaper to > implement or execute than evaluating edits based on a > memorized xpath solution. > * Comparison: > * XPATH eval: > + easier to list in a "list of outstanding locks" table > + storage cost is very small (a list of xpaths) > + CPU usage is higher (An eval on every command is required) > + I think it's more intuitive... There isn't an unknown "it's > no longer locked because you deleted it" sudden surprise. > * locking a list of nodes with a eval-once: > + Lower CPU usage since it's a single xpath eval > - Higher memory cost (need to memorize every locked node > either through a list or a flag) > - Usage complexity is much higher > - Can't lock empty parent nodes > - security ramifications require parent nodes for *everything* > - deleted nodes can be recreated > * This is most critical when manipulating ordered lists of > things like access rules (eg, firewall rules) > * I've seen real-world current discussions surrounding the need > to put in a parent tree for all nodes *just* because of the > partial-lock inability to lock a common set of nodes. The > result of this type of partical lock means either: > + data models will add extra tree nodes everywhere > + Or they wont' and it'll turn out later they should have > because of opreational needs for locking all the subnodes > and it can't be done. > - IE, it becomes critical to create a node to > surround a list of firewall nodes. > + I think it's worth spelling out this issue in the security > considerations so that every data model ever created gets a > otherwise-empty top node added above it so that it can be locked. [BALAZS}: In my eyes the deciding factor is avoiding surprises. XPATH surprise 1: I have a user: John OConnor. I lock him based on his name. Later I correct his name to John O'Connor. Whoops suddenly he is not locked. (The name might not even be the key attribute/leaf). XPATH surprise 2: We use XPATH: and "preceding-sibling::*". I modify some data in my locked nodes. The order of the nodes might be modified by the modifying their content in the datastore (e.g. modifying a leaf called "priority"). Due to the change in priority some nodes that were previously locked suddenly become unlocked. XPATH surprise 3: I know I have 3 users: Jack and J it's closed? > + Looks like kill-session is the solution based on later reading, > but I'd suggest spelling it out here. > + Requires access to the kill-session command to release a > hung-lock. Possibly worth mentioning in the security > expectations. [BALAZS}: OK > > 13 Section 2.5 > -------------- > * I'd spell out in no uncertain terms that any command that > modifies a datastore will be blocked, and that "includes" the > current list. The wording as is could be easily > misinterpreted to read that the current list is all you need > to worry about (which I know wasn't the intent). [BALAZS}: OK > > 14 Section 3, second paragraph: first sentence needs ()s or commas > ------------------------------------------------------------------ > around the lock types. [BALAZS}: OK > > 15 Comparison of xpath evaluated partial lock vs locked nodes > ------------------------------------------------------------- > * I'm not personally convienced still that locking existing > nodes only is the best solution for partial locking. I know > it's been debated a bunch in the past but I'm not even > convienced there is consusus on the subject. I suspect that > if you counted the number of folks that started an argument > about it the numbers wouldn't point clearly to a consensus. > Many of the arguments came at different times, which makes it > hard to count. > + That being said, letting this one go forward doesn't > prohibit a different later solution. [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad to see that you can still live with this solution. > + I'm not convienced that locking nodes is cheaper to > implement or execute than evaluating edits based on a > memorized xpath solution. > * Comparison: > * XPATH eval: > + easier to list in a "list of outstanding locks" table > + storage cost is very small (a list of xpaths) > + CPU usage is higher (An eval on every command is required) > + I think it's more intuitive... There isn't an unknown "it's > no longer locked because you deleted it" sudden surprise. > * locking a list of nodes with a eval-once: > + Lower CPU usage since it's a single xpath eval > - Higher memory cost (need to memorize every locked node > either through a list or a flag) > - Usage complexity is much higher > - Can't lock empty parent nodes > - security ramifications require parent nodes for *everything* > - deleted nodes can be recreated > * This is most critical when manipulating ordered lists of > things like access rules (eg, firewall rules) > * I've seen real-world current discussions surrounding the need > to put in a parent tree for all nodes *just* because of the > partial-lock inability to lock a common set of nodes. The > result of this type of partical lock means either: > + data models will add extra tree nodes everywhere > + Or they wont' and it'll turn out later they should have > because of opreational needs for locking all the subnodes > and it can't be done. > - IE, it becomes critical to create a node to > surround a list of firewall nodes. > + I think it's worth spelling out this issue in the security > considerations so that every data model ever created gets a > otherwise-empty top node added above it so that it can be locked. [BALAZS}: In my eyes the deciding factor is avoiding surprises. XPATH surprise 1: I have a user: John OConnor. I lock him based on his name. Later I correct his name to John O'Connor. Whoops suddenly he is not locked. (The name might not even be the key attribute/leaf). XPATH surprise 2: We use XPATH: and "preceding-sibling::*". I modify some data in my locked nodes. The order of the nodes might be modified by the modifying their content in the datastore (e.g. modifying a leaf called "priority"). Due to the change in priority some nodes that were previously locked suddenly become unlocked. XPATH surprise 3: I know I have 3 users: Jack and Jill anill and John. I store my users in alphabetical order. I want to lock John so I use from XPATH: "position() = 3" Now another operator comes and adds user Blaise. Suddenly I am locking Jill instead of John. XPATH surprise 4: Using an XPATH that includes state data or any configuration data that is not itself locked is just asking for disaster. Probably a many more strange XPATH expressions could be designed. regards Balazs --------------080404070508010701040804 Content-Type: text/plain; name="draft-ietf-netconf-partial-lock-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-netconf-partial-lock-04.txt" NETCONF B. Lengyel Internet-Draft Ericsson Hungary Intended status: Standards Track M. Bjorklund Expires: March 12, 2009 Tail-f Systems September 08, 2008 Partial Lock RPC for NETCONF draft-ietf-netconf-partial-lock-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 12, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. Lengyel & Bjorklund Expires March 12, 2009 [Page 1] Internet-Draft Partial Lock RPC for NETCONF September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 4 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1. . . . . . . . . . . . . . . . . . . . . 4 2.4.2. . . . . . . . . . . . . . . . . . . . 8 2.5. Modifications to Existing Operations . . . . . . . . . . . 9 2.6. Interactions with Other Capabilities . . . . . . . . . . . 9 2.6.1. Writable-Running Capability . . . . . . . . . . . . . 9 2.6.2. Candidate Configuration Capability . . . . . . . . . . 9 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Appendix A - XML Schema for Partial Locking (normative) . . 12 6. Appendix B - YANG Module for Partial Locking (non-normative) . . . . . . . . . .d John. I store my users in alphabetical order. I want to lock John so I use from XPATH: "position() = 3" Now another operator comes and adds user Blaise. Suddenly I am locking Jill instead of John. XPATH surprise 4: Using an XPATH that includes state data or any configuration data that is not itself locked is just asking for disaster. Probably a many more strange XPATH expressions could be designed. regards Balazs --------------080404070508010701040804 Content-Type: text/plain; name="draft-ietf-netconf-partial-lock-04.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-netconf-partial-lock-04.txt" NETCONF B. Lengyel Internet-Draft Ericsson Hungary Intended status: Standards Track M. Bjorklund Expires: March 12, 2009 Tail-f Systems September 08, 2008 Partial Lock RPC for NETCONF draft-ietf-netconf-partial-lock-04 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 12, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract The NETCONF protocol defines the lock and unlock RPCs that lock entire configuration datastores. In some situations, a way to lock only parts of a configuration datastore is required. This document defines a capability-based extension to the NETCONF protocol for locking portions of a configuration datastore. Lengyel & Bjorklund Expires March 12, 2009 [Page 1] Internet-Draft Partial Lock RPC for NETCONF September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 2. Partial Locking Capability . . . . . . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Capability Identifier . . . . . . . . . . . . . . . . . . 4 2.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1. . . . . . . . . . . . . . . . . . . . . 4 2.4.2. . . . . . . . . . . . . . . . . . . . 8 2.5. Modifications to Existing Operations . . . . . . . . . . . 9 2.6. Interactions with Other Capabilities . . . . . . . . . . . 9 2.6.1. Writable-Running Capability . . . . . . . . . . . . . 9 2.6.2. Candidate Configuration Capability . . . . . . . . . . 9 2.6.3. Distinct Startup Capability . . . . . . . . . . . . . 10 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Appendix A - XML Schema for Partial Locking (normative) . . 12 6. Appendix B - YANG Module for Partial Locking (non-normative) . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 16 7.1. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Lengyel & Bjorklund Expires March 12, 2009 [Page 2] Internet-Draft Partial Lock RPC for NETCONF September 2008 1. Introduction The NETCONF protocol [NETCONF] describes the lock and unlock RPCs that operate on entire configuration datastores. Often, multiple management sessions need to be able to modify the configuration of a managed device in parallel. In these cases, locking only parts of a configuration datastore is needed. This document defines an extension to the NETCONF protocol to allow this. The mechanism for partial locking is based on the existing XPath filtering mechanisms. Partial locking is defined as a capability to NETCONF. 1.1. Definition of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 2. Partial Locking Capability 2.1. Overview The :partial-lock capability indicates that the device supports the locking of its configuration with a scope smaller then a complete configuration datastore. The scope to be locked is specified by using restricted or full XPath expressions. Partial locking covers configuration data, but not state data. The system MUST ensure that configuration resources covered by the lock are not modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI. The duration of the partial lock is defined as beginning when the partial lock is granted. The partial lock lasts until either the corresponding operation succeeds or the NETCONF session terminates. A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock. Lengyel & Bjorklund Expires March 12, 2009 [Page 3] Internet-Draft Partial Lock RPC for NETCONF September 2008 2.2. Dependencies The device MUST support the restricted XPath expressions in the select element, as described in Section 2.4.1. If optionally the :xpath capability is also supported, the device MUST also support the usage of any XPath 1.0 expression in the select element. 2.3. Capability Identifier urn:ietf:params:netconf:capability:partial-lock:1.0 2.4. New Operations 2.4.1. The operation allows the client to lock a portion of a data store. The portion to lock is specified by using XPath expressions in the select elements of the operation. Each XPath expression MUST return a node set. Locking a node protects the complete subtree under it from modification by others. The select XPath expressions are evaluated only once at lock time, thereafter the scope of the lock is maintained as a set of nodes. If the configuration data is later altered in a way that would make the original select XPath expressi . . . . . . . . . . 14 7. Appendix C - Change Log . . . . . . . . . . . . . . . . . . 16 7.1. 03-04 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.4. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Lengyel & Bjorklund Expires March 12, 2009 [Page 2] Internet-Draft Partial Lock RPC for NETCONF September 2008 1. Introduction The NETCONF protocol [NETCONF] describes the lock and unlock RPCs that operate on entire configuration datastores. Often, multiple management sessions need to be able to modify the configuration of a managed device in parallel. In these cases, locking only parts of a configuration datastore is needed. This document defines an extension to the NETCONF protocol to allow this. The mechanism for partial locking is based on the existing XPath filtering mechanisms. Partial locking is defined as a capability to NETCONF. 1.1. Definition of Terms The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 2. Partial Locking Capability 2.1. Overview The :partial-lock capability indicates that the device supports the locking of its configuration with a scope smaller then a complete configuration datastore. The scope to be locked is specified by using restricted or full XPath expressions. Partial locking covers configuration data, but not state data. The system MUST ensure that configuration resources covered by the lock are not modified by other NETCONF or non-NETCONF management operations such as SNMP and the CLI. The duration of the partial lock is defined as beginning when the partial lock is granted. The partial lock lasts until either the corresponding operation succeeds or the NETCONF session terminates. A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock. Lengyel & Bjorklund Expires March 12, 2009 [Page 3] Internet-Draft Partial Lock RPC for NETCONF September 2008 2.2. Dependencies The device MUST support the restricted XPath expressions in the select element, as described in Section 2.4.1. If optionally the :xpath capability is also supported, the device MUST also support the usage of any XPath 1.0 expression in the select element. 2.3. Capability Identifier urn:ietf:params:netconf:capability:partial-lock:1.0 2.4. New Operations 2.4.1. The operation allows the client to lock a portion of a data store. The portion to lock is specified by using XPath expressions in the select elements of the operation. Each XPath expression MUST return a node set. Locking a node protects the complete subtree under it from modification by others. The select XPath expressions are evaluated only once at lock time, thereafter the scope of the lock is maintained as a set of nodes. If the configuration data is later altered in a way that would make the original select XPath expressions evons evaluate to a different set of nodes, this does not affect the scope of the partial lock. XPath is only used for the creation of the partial lock. Conceptually the scope of the lock is defined by the returned node set and not by the XPath expression. A operation MUST be handled atomically by the NETCONF server. The server either locks all requested parts of the data store or none; I.e. if during the operation one of the requested parts cannot be locked the server MUST unlock all parts that have been already locked during that operation. If a node is locked by a session, only that same session is able to modify that node or any node in the subtree underneath it. If a top level node of a locked subtree is deleted, any other session can recreate it, as it is not covered by the lock anymore. If all top level nodes are deleted, the lock will still be present, however it's scope will become nil i.e. it will not cover any nodes. A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of Lengyel & Bjorklund Expires March 12, 2009 [Page 4] Internet-Draft Partial Lock RPC for NETCONF September 2008 the locks are released. A partial lock operation MUST fail if: o Any NETCONF session (including the current session) owns the global lock on the datastore. o Any part of the scope to be locked is already locked by another management session/protocol, including other NETCONF sessions using the or any other non-NETCONF management method. o The NETCONF server implements access control and the locking user does not have sufficient privileges, to all parts of the datastore section to be locked. The exact handling of access rights is outside the scope of this document, but it is assumed that there is an access control system that MAY deny or allow the partial lock operation. Note: If partial lock is requested for the running datastore, and the NETCONF server implements the :confirmed-commit capability, and there was a recent confirmed operation, where the confirming operation has not been received. In this case the lock MUST be denied, because if the confirmation does not arrive, the running datastore MUST be rolled back to its state before the commit, thus the NETCONF server might need to modify the configuration. As with most locking systems, there is a possibility that two management sessions trying to lock different parts of the configuration could become dead-locked. To avoid this situation, clients SHOULD lock everything they need in one operation. If that operation still fails, the client SHOULD back down, release any already acquired locks, and retry the procedure after some time interval. The length of the interval should preferably be random to avoid repeated dead-locks when both (or all) clients back down and then repeat locking. It is the intention to keep partial-locking simple, so when a partial lock is executed you get what you asked for: a set of nodes that are locked for writing. There are some other issues that are intentionally not addressed for the sake of simplicity: o Locking does not affect read operations. o If a part of a datastore is locked, this has no effect on any unlocked parts of the datastore. If this is a problem e.g. the operator's changes depend on data values in the unlocked part of the datastore, the operator should include these values in the Lengyel & Bjorklund Expires March 12, 2009 [Page 5] Internet-Draft Partial Lock RPC for NETCONF September 2008 scope of the lock. o An operator is allowed to edit the configuration both inside and outside the scope of a lock. It is the operatoaluate to a different set of nodes, this does not affect the scope of the partial lock. XPath is only used for the creation of the partial lock. Conceptually the scope of the lock is defined by the returned node set and not by the XPath expression. A operation MUST be handled atomically by the NETCONF server. The server either locks all requested parts of the data store or none; I.e. if during the operation one of the requested parts cannot be locked the server MUST unlock all parts that have been already locked during that operation. If a node is locked by a session, only that same session is able to modify that node or any node in the subtree underneath it. If a top level node of a locked subtree is deleted, any other session can recreate it, as it is not covered by the lock anymore. If all top level nodes are deleted, the lock will still be present, however it's scope will become nil i.e. it will not cover any nodes. A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of Lengyel & Bjorklund Expires March 12, 2009 [Page 4] Internet-Draft Partial Lock RPC for NETCONF September 2008 the locks are released. A partial lock operation MUST fail if: o Any NETCONF session (including the current session) owns the global lock on the datastore. o Any part of the scope to be locked is already locked by another management session/protocol, including other NETCONF sessions using the or any other non-NETCONF management method. o The NETCONF server implements access control and the locking user does not have sufficient privileges, to all parts of the datastore section to be locked. The exact handling of access rights is outside the scope of this document, but it is assumed that there is an access control system that MAY deny or allow the partial lock operation. Note: If partial lock is requested for the running datastore, and the NETCONF server implements the :confirmed-commit capability, and there was a recent confirmed operation, where the confirming operation has not been received. In this case the lock MUST be denied, because if the confirmation does not arrive, the running datastore MUST be rolled back to its state before the commit, thus the NETCONF server might need to modify the configuration. As with most locking systems, there is a possibility that two management sessions trying to lock different parts of the configuration could become dead-locked. To avoid this situation, clients SHOULD lock everything they need in one operation. If that operation still fails, the client SHOULD back down, release any already acquired locks, and retry the procedure after some time interval. The length of the interval should preferably be random to avoid repeated dead-locks when both (or all) clients back down and then repeat locking. It is the intention to keep partial-locking simple, so when a partial lock is executed you get what you asked for: a set of nodes that are locked for writing. There are some other issues that are intentionally not addressed for the sake of simplicity: o Locking does not affect read operations. o If a part of a datastore is locked, this has no effect on any unlocked parts of the datastore. If this is a problem e.g. the operator's changes depend on data values in the unlocked part of the datastore, the operator should include these values in the Lengyel & Bjorklund Expires March 12, 2009 [Page 5] Internet-Draft Partial Lock RPC for NETCONF September 2008 scope of the lock. o An operator is allowed to edit the configuration both inside and outside the scope of a lock. It is the operator's rer's responsibility to lock all parts of the datastore that are crucial for a specific management action. Note: The operation does not modify the global operation defined in the base NETCONF Protocol [NETCONF]. If part of a datastore is already locked by , then a global lock for that datastore fails even if the global lock is attempted by the same NETCONF session which owns the partial-lock. 2.4.1.1. Parameters, Result, Examples Parameters: target: Name of the configuration datastore of which a part shall be locked. One operation can affect only one of the datastores, so only one parameter is allowed. URLs are not accepted. select: One or more 'select' elements each containing an XPath expression. The XPath expression is evaluated in a context where the context node is the root of the server's conceptual data model, and the set of namespace declarations are those in scope on the select element. The select expressions MUST each return a node set, and at least one of the node sets must be non-empty. If the device supports the :xpath capability then any valid XPath 1.0 expression can be used, if not, the XPath expression MUST be limited to an Instance Identifier expression. An Instance Identifier is an absolute path expression in abbreviated syntax, where predicates are used only to specify values for nodes defined as keys to distinguish multiple instances. Lengyel & Bjorklund Expires March 12, 2009 [Page 6] Internet-Draft Partial Lock RPC for NETCONF September 2008 Example: Lock virtual router 1 and interface eth1 127 /routing/virtualRouter[routerName='router1'] /interfaces/interface[id='eth1'] Positive Response: If the device was able to satisfy the request, an is sent with a element (lock identifier) in the element. A list of locked-nodes is also returned. Negative Response: If a lock is already held by another session on any node within the subtrees to be locked, the element is 'lock-denied' and the element includes the of the lock owner. If the lock is held by a non-NETCONF session, a of 0 Lengyel & Bjorklund Expires March 12, 2009 [Page 7] Internet-Draft Partial Lock RPC for NETCONF September 2008 (zero) is included. If needed the returned session-id may be used to the NETCONF session holding the lock. The same error response is returned if the requesting session already holds the (global) lock for the same datastore. If the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'. If any selecsponsibility to lock all parts of the datastore that are crucial for a specific management action. Note: The operation does not modify the global operation defined in the base NETCONF Protocol [NETCONF]. If part of a datastore is already locked by , then a global lock for that datastore fails even if the global lock is attempted by the same NETCONF session which owns the partial-lock. 2.4.1.1. Parameters, Result, Examples Parameters: target: Name of the configuration datastore of which a part shall be locked. One operation can affect only one of the datastores, so only one parameter is allowed. URLs are not accepted. select: One or more 'select' elements each containing an XPath expression. The XPath expression is evaluated in a context where the context node is the root of the server's conceptual data model, and the set of namespace declarations are those in scope on the select element. The select expressions MUST each return a node set, and at least one of the node sets must be non-empty. If the device supports the :xpath capability then any valid XPath 1.0 expression can be used, if not, the XPath expression MUST be limited to an Instance Identifier expression. An Instance Identifier is an absolute path expression in abbreviated syntax, where predicates are used only to specify values for nodes defined as keys to distinguish multiple instances. Lengyel & Bjorklund Expires March 12, 2009 [Page 6] Internet-Draft Partial Lock RPC for NETCONF September 2008 Example: Lock virtual router 1 and interface eth1 127 /routing/virtualRouter[routerName='router1'] /interfaces/interface[id='eth1'] Positive Response: If the device was able to satisfy the request, an is sent with a element (lock identifier) in the element. A list of locked-nodes is also returned. Negative Response: If a lock is already held by another session on any node within the subtrees to be locked, the element is 'lock-denied' and the element includes the of the lock owner. If the lock is held by a non-NETCONF session, a of 0 Lengyel & Bjorklund Expires March 12, 2009 [Page 7] Internet-Draft Partial Lock RPC for NETCONF September 2008 (zero) is included. If needed the returned session-id may be used to the NETCONF session holding the lock. The same error response is returned if the requesting session already holds the (global) lock for the same datastore. If the select expressions return an empty node set, the is 'operation-failed', and the is 'no-matches'. If any select exprt expression returns anything but a node set, the is 'invalid-value', the is 'XPath does not return a node set'. If the :xpath capability is not supported and the XPath expression is not an Instance Identifier, the is 'invalid-value', the is ':xpath capability not supported'. If access control denies the partial lock, the is 'access-denied'. 2.4.1.2. Reserving model sections for future work Partial lock can not be used to lock non-existing nodes, effectively reserving them for future use. To make sure that a node cannot be created by some other session, the parent node should be locked, the top level node of the new section created, and then locked with another operation. After this the lock on the parent node should be removed. 2.4.2. The operation unlocks a part of a datastore that was previously locked using during the same session. Parameters: lock-id: Lock identifier to unlock; taken from a reply to a previous operation. Lengyel & Bjorklund Expires March 12, 2009 [Page 8] Internet-Draft Partial Lock RPC for NETCONF September 2008 Example: Unlock a previously created lock 127 Positive Response: If the device was able to satisfy the request, an is sent that contains an element. A positive response MUST be sent even if all of the locked part of the datastore has already been deleted. Negative Response: If the parameter does not identify a lock which is owned by the session, an 'invalid-value' error is returned. 2.5. Modifications to Existing Operations A granted partial-lock will cause another operation to fail, if it tries to modify the locked area and is executed in a NETCONF session other then the one that owns the lock. All operations that modify the datastore are affected including: , , , and . A granted partial- lock will also cause the (global) operation to fail. All of these operations are affected only if they are for the same datastore. 2.6. Interactions with Other Capabilities 2.6.1. Writable-Running Capability Partial locking of the running datastore can only be done if the :writable-running capability is supported by the device. 2.6.2. Candidate Configuration Capability Partial locking of the candidate datastore can only be done if the :candidate capability is supported by the device. The partial locking of the candidate datastore does not depend on whether the datastore was modified or not. If partial lock is requested for the running datastore, and the Lengyel & Bjorklund Expires March 12, 2009 [Page 9] Internet-Draft Partial Lock RPC for NETCONF September 2008 NETCONF server implements the :confirmed-commit capability, and there was a recent confirmed operation, where the confirming operation has not been received, in this case the lock MUST be denied, because if the confirmation does not arrive, the running datastore MUST be rolled back to its state before the commit, thus the NETCONF server might need to modify the configuration. 2.6.3. Distinct Startup Capability Partial locking of the startup datastore can only be done if the :startup capability is supported by the device. 3. Security Considerations The same considerations as for the base NETCONF Protocol [NETCONF] are valid. It is assumed that the and RPCs are only allowed for an authenticated user after passing some access control meession returns anything but a node set, the is 'invalid-value', the is 'XPath does not return a node set'. If the :xpath capability is not supported and the XPath expression is not an Instance Identifier, the is 'invalid-value', the is ':xpath capability not supported'. If access control denies the partial lock, the is 'access-denied'. 2.4.1.2. Reserving model sections for future work Partial lock can not be used to lock non-existing nodes, effectively reserving them for future use. To make sure that a node cannot be created by some other session, the parent node should be locked, the top level node of the new section created, and then locked with another operation. After this the lock on the parent node should be removed. 2.4.2. The operation unlocks a part of a datastore that was previously locked using during the same session. Parameters: lock-id: Lock identifier to unlock; taken from a reply to a previous operation. Lengyel & Bjorklund Expires March 12, 2009 [Page 8] Internet-Draft Partial Lock RPC for NETCONF September 2008 Example: Unlock a previously created lock 127 Positive Response: If the device was able to satisfy the request, an is sent that contains an element. A positive response MUST be sent even if all of the locked part of the datastore has already been deleted. Negative Response: If the parameter does not identify a lock which is owned by the session, an 'invalid-value' error is returned. 2.5. Modifications to Existing Operations A granted partial-lock will cause another operation to fail, if it tries to modify the locked area and is executed in a NETCONF session other then the one that owns the lock. All operations that modify the datastore are affected including: , , , and . A granted partial- lock will also cause the (global) operation to fail. All of these operations are affected only if they are for the same datastore. 2.6. Interactions with Other Capabilities 2.6.1. Writable-Running Capability Partial locking of the running datastore can only be done if the :writable-running capability is supported by the device. 2.6.2. Candidate Configuration Capability Partial locking of the candidate datastore can only be done if the :candidate capability is supported by the device. The partial locking of the candidate datastore does not depend on whether the datastore was modified or not. If partial lock is requested for the running datastore, and the Lengyel & Bjorklund Expires March 12, 2009 [Page 9] Internet-Draft Partial Lock RPC for NETCONF September 2008 NETCONF server implements the :confirmed-commit capability, and there was a recent confirmed operation, where the confirming operation has not been received, in this case the lock MUST be denied, because if the confirmation does not arrive, the running datastore MUST be rolled back to its state before the commit, thus the NETCONF server might need to modify the configuration. 2.6.3. Distinct Startup Capability Partial locking of the startup datastore can only be done if the :startup capability is supported by the device. 3. Security Considerations The same considerations as for the base NETCONF Protocol [NETCONF] are valid. It is assumed that the and RPCs are only allowed for an authenticated user after passing some access control mechanischanism. A lock (a partial-lock or a global lock) might prevent other users from configuring the system. The following mechanisms are in place to prevent the misuse of this possibility: Only an authenticated user after passing access control can request a partial-lock. The partial-lock is automatically released when a session is terminated irrespective of the manner the session ends. The operation allows terminating other users sessions. The NETCONF server may log partial-lock requests in an audit trail. A lock that is hanging for any reason, e.g. a broken TCP connection that the server has not yet recognised, can be released from another NETCONF session by explicitly killing the session owning that lock using the operation. Partial locking is NOT an authorization mechanism, it should not be used to provide security or access control. Partial locking should only be used as a mechanism to provide consistency in case of multiple managers trying to configure the node. It is vital that the operator can easily understand the exact scope of a lock, for this Lengyel & Bjorklund Expires March 12, 2009 [Page 10] Internet-Draft Partial Lock RPC for NETCONF September 2008 reason the scope is determined when granting a lock and is not modified dynamically later. 4. IANA Considerations This document registers two URIs for the NETCONF XML namespace in the IETF XML registry [RFC3688]. Note that the capability URN is compliant to [NETCONF] section 10.3. +---------------+---------------------------------------------------+ | Index | Capability Identifier | +---------------+---------------------------------------------------+ | :partial-lock | urn:ietf:params:netconf:capability:partial-lock:1 | | | .0 | +---------------+---------------------------------------------------+ URI: urn:ietf:params:xml:ns:netconf:partial-lock:1.0 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. Lengyel & Bjorklund Expires March 12, 2009 [Page 11] Internet-Draft Partial Lock RPC for NETCONF September 2008 5. Appendix A - XML Schema for Partial Locking (normative) The following XML Schema defines the and operations: Schema defining the partial-lock and unlock operations. organization "IETF NETCONF Working Group" contact "Balazs Lengyel Ericsson Hungary, Inc. balazs.lengyel@ericsson.com" A NETCONF operation that locks part of a datastore. XPath expression that specifies the scope of the lock. An Instance Identifier expression must be used unless the :xpath capability is supported in which case any XPath 1.0 exprem. A lock (a partial-lock or a global lock) might prevent other users from configuring the system. The following mechanisms are in place to prevent the misuse of this possibility: Only an authenticated user after passing access control can request a partial-lock. The partial-lock is automatically released when a session is terminated irrespective of the manner the session ends. The operation allows terminating other users sessions. The NETCONF server may log partial-lock requests in an audit trail. A lock that is hanging for any reason, e.g. a broken TCP connection that the server has not yet recognised, can be released from another NETCONF session by explicitly killing the session owning that lock using the operation. Partial locking is NOT an authorization mechanism, it should not be used to provide security or access control. Partial locking should only be used as a mechanism to provide consistency in case of multiple managers trying to configure the node. It is vital that the operator can easily understand the exact scope of a lock, for this Lengyel & Bjorklund Expires March 12, 2009 [Page 10] Internet-Draft Partial Lock RPC for NETCONF September 2008 reason the scope is determined when granting a lock and is not modified dynamically later. 4. IANA Considerations This document registers two URIs for the NETCONF XML namespace in the IETF XML registry [RFC3688]. Note that the capability URN is compliant to [NETCONF] section 10.3. +---------------+---------------------------------------------------+ | Index | Capability Identifier | +---------------+---------------------------------------------------+ | :partial-lock | urn:ietf:params:netconf:capability:partial-lock:1 | | | .0 | +---------------+---------------------------------------------------+ URI: urn:ietf:params:xml:ns:netconf:partial-lock:1.0 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. Lengyel & Bjorklund Expires March 12, 2009 [Page 11] Internet-Draft Partial Lock RPC for NETCONF September 2008 5. Appendix A - XML Schema for Partial Locking (normative) The following XML Schema defines the and operations: Schema defining the partial-lock and unlock operations. organization "IETF NETCONF Working Group" contact "Balazs Lengyel Ericsson Hungary, Inc. balazs.lengyel@ericsson.com" A NETCONF operation that locks part of a datastore. XPath expression that specifies the scope of the lock. An Instance Identifier expression must be used unless the :xpath capability is supported in which case any XPath 1.0 expression ssion is allowed. Lengyel & Bjorklund Expires March 12, 2009 [Page 12] Internet-Draft Partial Lock RPC for NETCONF September 2008 A NETCONF operation that releases a previously acquired partial-lock. Identifies the lock to be released. Must be the value received in the response to the partial-lock operation. Lengyel & Bjorklund Expires March 12, 2009 [Page 13] Internet-Draft Partial Lock RPC for NETCONF September 2008 6. Appendix B - YANG Module for Partial Locking (non-normative) The following YANG module defines the and operations. The YANG language is defined in [I-D.ietf-netmod-yang]. module netconf-partial-lock { namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0; prefix pl; organization "IETF NETCONF Working Group"; contact "Balazs Lengyel Ericsson Hungary, Inc. balazs.lengyel@ericsson.com"; description "This YANG module defines the and operations."; revision 2008-06-06 { description "Initial version."; } grouping configName { container target { description "A choice to list the datastore names for NETCONF."; choice configNameType { leaf running { type empty; } leaf candidate { type empty; } leaf startup { type empty; } } } } rpc partial-lock { description "A NETCONF operation that locks part of a datastore."; input { uses configName; leaf-list select { description "XPath expression that specifies the scope of the lock. An Instance Identifier expression must be used unless the :xpath capability is supported in which case any XPath 1.0 expression is allowed."; Lengyel & Bjorklund Expires March 12, 2009 [Page 14] Internet-Draft Partial Lock RPC for NETCONF September 2008 type string; min-elements 1; } } output { leaf lock-id { description "Identifies the lock, if granted. The lock-id must be used in the partial-unlock rpc."; type uint32; } leaf-list locked-node { description "List of locked-nodes"; type instance-identifier; } } } rpc partial-unlock { description "A NETCONF operation that releases a previously acquired partial-lock."; input { leaf lock-id { description "Identifies the lock to be released. Must be the value received in the response to the partial-lock operation."; type uint32; } } } } is allowed. Lengyel & Bjorklund Expires March 12, 2009 [Page 12] Internet-Draft Partial Lock RPC for NETCONF September 2008 A NETCONF operation that releases a previously acquired partial-lock. Identifies the lock to be released. Must be the value received in the response to the partial-lock operation. Lengyel & Bjorklund Expires March 12, 2009 [Page 13] Internet-Draft Partial Lock RPC for NETCONF September 2008 6. Appendix B - YANG Module for Partial Locking (non-normative) The following YANG module defines the and operations. The YANG language is defined in [I-D.ietf-netmod-yang]. module netconf-partial-lock { namespace urn:ietf:params:xml:ns:netconf:partial-lock:1.0; prefix pl; organization "IETF NETCONF Working Group"; contact "Balazs Lengyel Ericsson Hungary, Inc. balazs.lengyel@ericsson.com"; description "This YANG module defines the and operations."; revision 2008-06-06 { description "Initial version."; } grouping configName { container target { description "A choice to list the datastore names for NETCONF."; choice configNameType { leaf running { type empty; } leaf candidate { type empty; } leaf startup { type empty; } } } } rpc partial-lock { description "A NETCONF operation that locks part of a datastore."; input { uses configName; leaf-list select { description "XPath expression that specifies the scope of the lock. An Instance Identifier expression must be used unless the :xpath capability is supported in which case any XPath 1.0 expression is allowed."; Lengyel & Bjorklund Expires March 12, 2009 [Page 14] Internet-Draft Partial Lock RPC for NETCONF September 2008 type string; min-elements 1; } } output { leaf lock-id { description "Identifies the lock, if granted. The lock-id must be used in the partial-unlock rpc."; type uint32; } leaf-list locked-node { description "List of locked-nodes"; type instance-identifier; } } } rpc partial-unlock { description "A NETCONF operation that releases a previously acquired partial-lock."; input { leaf lock-id { description "Identifies the lock to be released. Must be the value received in the response to the partial-lock operation."; type uint32; } } } } Leng Lengyel & Bjorklund Expires March 12, 2009 [Page 15] Internet-Draft Partial Lock RPC for NETCONF September 2008 7. Appendix C - Change Log 7.1. 03-04 Minor clarifications Added list of locked-nodes to the output of partial-lock. Added wrapper around datastore name. 7.2. 02-03 Minor clarifications Same descriptions in XSD and YANG. 7.3. 01-02 Made XSD normative Clarified that no specific access control is assumed. Clarified that non-existing nodes are NOT covered by the lock, even if they where existing and covered by the lock when it was originally granted. Some rewording Added app-tags for two of the error cases. Made YANG an informative reference Enhanced security considerations. 7.4. 00-01 Added YANG module. 7.5. -00 Created from draft-lengyel-ngo-partial-lock-01.txt Lengyel & Bjorklund Expires March 12, 2009 [Page 16] Internet-Draft Partial Lock RPC for NETCONF September 2008 8. Acknowledgements Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David Harrington, Mehmet Ersue and many other members of the NETCONF WG for providing important input to this document. Lengyel & Bjorklund Expires March 12, 2009 [Page 17] Internet-Draft Partial Lock RPC for NETCONF September 2008 9. References 9.1. Normative References [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 9.2. Informative References [I-D.ietf-netmod-yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-ietf-netmod-yang-00 (work in progress), May 2008. Lengyel & Bjorklund Expires March 12, 2009 [Page 18] Internet-Draft Partial Lock RPC for NETCONF September 2008 Authors' Addresses Balazs Lengyel Ericsson Hungary Email: balazs.lengyel@ericsson.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Lengyel & Bjorklund Expires March 12, 2009 [Page 19] Internet-Draft Partial Lock RPC for NETCONF September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such pyel & Bjorklund Expires March 12, 2009 [Page 15] Internet-Draft Partial Lock RPC for NETCONF September 2008 7. Appendix C - Change Log 7.1. 03-04 Minor clarifications Added list of locked-nodes to the output of partial-lock. Added wrapper around datastore name. 7.2. 02-03 Minor clarifications Same descriptions in XSD and YANG. 7.3. 01-02 Made XSD normative Clarified that no specific access control is assumed. Clarified that non-existing nodes are NOT covered by the lock, even if they where existing and covered by the lock when it was originally granted. Some rewording Added app-tags for two of the error cases. Made YANG an informative reference Enhanced security considerations. 7.4. 00-01 Added YANG module. 7.5. -00 Created from draft-lengyel-ngo-partial-lock-01.txt Lengyel & Bjorklund Expires March 12, 2009 [Page 16] Internet-Draft Partial Lock RPC for NETCONF September 2008 8. Acknowledgements Thanks to Andy Bierman, Sharon Chisholm, Phil Shafer , David Harrington, Mehmet Ersue and many other members of the NETCONF WG for providing important input to this document. Lengyel & Bjorklund Expires March 12, 2009 [Page 17] Internet-Draft Partial Lock RPC for NETCONF September 2008 9. References 9.1. Normative References [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. 9.2. Informative References [I-D.ietf-netmod-yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", draft-ietf-netmod-yang-00 (work in progress), May 2008. Lengyel & Bjorklund Expires March 12, 2009 [Page 18] Internet-Draft Partial Lock RPC for NETCONF September 2008 Authors' Addresses Balazs Lengyel Ericsson Hungary Email: balazs.lengyel@ericsson.com Martin Bjorklund Tail-f Systems Email: mbj@tail-f.com Lengyel & Bjorklund Expires March 12, 2009 [Page 19] Internet-Draft Partial Lock RPC for NETCONF September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprieroprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lengyel & Bjorklund Expires March 12, 2009 [Page 20] --------------080404070508010701040804 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 --------------080404070508010701040804-- tary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Lengyel & Bjorklund Expires March 12, 2009 [Page 20] --------------080404070508010701040804 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 --------------080404070508010701040804-- From netconf-bounces@ietf.org Mon Sep 8 14:16:46 2008 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 84D0D3A6888; Mon, 8 Sep 2008 14:16:46 -0700 (PDT) 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 6CBAB3A6877 for ; Mon, 8 Sep 2008 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, STOX_REPLY_TYPE=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 76gzc5C3-zzo for ; Mon, 8 Sep 2008 14:16:44 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 9646E3A6888 for ; Mon, 8 Sep 2008 14:16:43 -0700 (PDT) Received: (qmail 91174 invoked from network); 8 Sep 2008 21:16:46 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 8 Sep 2008 21:16:46 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "Wes Hardaker" , "netconf mailing list" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: <48C53EEC.4080009@ericsson.com> Date: Mon, 8 Sep 2008 23:07:43 +0200 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: Re: [Netconf] evaluation of the partial-lock document 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 Inline ----- Original Message ----- From: "Balazs Lengyel" To: "Wes Hardaker" ; "Bert Wijnen - IETF" ; "netconf mailing list" Sent: Monday, September 08, 2008 5:04 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Wes, Bert, > Thanks for the review. Please see the answers for Wes below! > > If you have a look of the attached version, you can see that I also > included Bert's comments. I > basically accepted them all e.g. I added a list of locked-nodes to the > rpc-reply. > Thanks. AS a result I can see that in the example and also in the YANG definition. But I do not see that the list of locked nodes is returned according to the XSD schema? It looks the same as in revision 3. It is quite possible I don't understand XSD well enough. I need to review your responses to Wes in more detail before I can respond. I would encourage other WG members to also read those responses and speak up if they see issues.!!! PLEASE. > Please indicate if you still have problems with some of the issues. My own issues have been addressed, thanks Bert > Balazs > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 8 14:16:46 2008 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 84D0D3A6888; Mon, 8 Sep 2008 14:16:46 -0700 (PDT) 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 6CBAB3A6877 for ; Mon, 8 Sep 2008 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, STOX_REPLY_TYPE=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 76gzc5C3-zzo for ; Mon, 8 Sep 2008 14:16:44 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 9646E3A6888 for ; Mon, 8 Sep 2008 14:16:43 -0700 (PDT) Received: (qmail 91174 invoked from network); 8 Sep 2008 21:16:46 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 8 Sep 2008 21:16:46 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" , "Wes Hardaker" , "netconf mailing list" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: <48C53EEC.4080009@ericsson.com> Date: Mon, 8 Sep 2008 23:07:43 +0200 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: Re: [Netconf] evaluation of the partial-lock document 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 Inline ----- Original Message ----- From: "Balazs Lengyel" To: "Wes Hardaker" ; "Bert Wijnen - IETF" ; "netconf mailing list" Sent: Monday, September 08, 2008 5:04 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Wes, Bert, > Thanks for the review. Please see the answers for Wes below! > > If you have a look of the attached version, you can see that I also > included Bert's comments. I > basically accepted them all e.g. I added a list of locked-nodes to the > rpc-reply. > Thanks. AS a result I can see that in the example and also in the YANG definition. But I do not see that the list of locked nodes is returned according to the XSD schema? It looks the same as in revision 3. It is quite possible I don't understand XSD well enough. I need to review your responses to Wes in more detail before I can respond. I would encourage other WG members to also read those responses and speak up if they see issues.!!! PLEASE. > Please indicate if you still have problems with some of the issues. My own issues have been addressed, thanks Bert > Balazs > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 8 14:23:27 2008 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 61B363A6AF5; Mon, 8 Sep 2008 14:23:27 -0700 (PDT) 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 08B083A6AF5 for ; Mon, 8 Sep 2008 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ZEFc6PsReVwQ for ; Mon, 8 Sep 2008 14:23:24 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id C4DB63A6ACD for ; Mon, 8 Sep 2008 14:23:23 -0700 (PDT) Received: (qmail 91195 invoked from network); 8 Sep 2008 21:16:47 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 8 Sep 2008 21:16:47 -0000 Message-ID: <2683A058D57F4D519C59BF787B0BE131@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: <48C53EEC.4080009@ericsson.com> Date: Mon, 8 Sep 2008 23:16:09 +0200 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] WG, pls review responses from Balazs to Wes. Was: Re: evaluation of the partial-lock document 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 For example, in the below there is this discussion and a question is "do we have consensus" : >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> ------------------------------------------------------------- >> * I'm not personally convienced still that locking existing >> nodes only is the best solution for partial locking. I know >> it's been debated a bunch in the past but I'm not even >> convienced there is consusus on the subject. I suspect that >> if you counted the number of folks that started an argument >> about it the numbers wouldn't point clearly to a consensus. >> Many of the arguments came at different times, which makes it >> hard to count. >> + That being said, letting this one go forward doesn't >> prohibit a different later solution. > [BALAZS}: IMHO we did reach consensus on the issue, > but anyway I am glad to see that you can still live with this solution. Part of any WG Last Call is to make sure that what is the the document being Last Called is indeed consensus of the WG. Unless multiple people speak up, the WG chairs will assume that the document does indeed represent WG consensus. So pls do reveiw the document, Pls do review the responses being posted to Wes's review comments, and DO SPEAK UP if you have concerns or issues. Bert (speaking as co-chair) ----- Original Message ----- From: "Balazs Lengyel" To: "Wes Hardaker" ; "Bert Wijnen - IETF" ; "netconf mailing list" Sent: Monday, September 08, 2008 5:04 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Wes, Bert, > Thanks for the review. Please see the answers for Wes below! > > If you have a look of the attached version, you can see that I also > included Bert's comments. I > basically accepted them all e.g. I added a list of locked-nodes to the > rpc-reply. > > Please indicate if you still have problems with some of the issues. > Balazs > > Wes Hardaker wrote: >> * My final thoughts and concerns on the partial-lock feature as >> a whole are in the last section of this... >> >> >> Netconf WG last call report on partial lock >> =========================================== >> >> Author: Wes Hardaker >> Date: 2008-08-26 16:50:09 PDT >> >> Table of Contents >> ================= >> 1 General Notes >> 2 Thoughts on: Partial locks don't cover non-existing nodes >> 3 section 2.1: "Note:" wording >> 4 section 2.1, starting with "As with most locking..." >> 5 Question about multiple locks from the same session... >> 6 Section 2.4.1.1: target: >> 7 Section 2.4.1.1: text change >> 8 Section 2.4.1.1: first example >> 9 Side thought: netconf documents all assume a particular data model >> 10 Section 2.4.1.1: 2nd to last paragraph: >> 11 Section 2.4.2: >> 12 Section 2.4.2, negative response: >> 13 Section 2.5 >> 14 Section 3, second paragraph: first sentence needs ()s or commas >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> >> >> >> 1 General Notes >> --------------- >> * Document is very well layed out and easy to understand. >> It flows well and is easy to read. >> * But... The English grammar could use some polishing in a few >> more places than I've listed here. >> + I'd recommend the authors hand it to someone that hasn't >> been involved in editing for a simple polishing pass. > [BALAZS]: Will try. >> * My final thoughts and concerns on the partial-lock feature as >> a whole are in the last section of this... >> >> 2 Thoughts on: Partial locks don't cover non-existing nodes >> ----------------------------------------------------------- >> * (Section 2.4.1-ish) >> * note: can't lock a tree part that doesn't exist yet >> * There exists odd an usage case when a tree doesn't yet exist >> (empty configuration). E.G., I can't lock the users tree until >> at least 1 users/user exists. If I try to lock when >> no subelement exists then I believe I get an error back (I'm >> not even positive about this). Section 2.4.1 seems to >> indicate that it'll fail since at least one of the select sets >> MUST be non-empty. >> + The result is that you *must* create a single before >> you can lock the table, for example. IE a manager >> is expected to be able to perform and understand why it's >> doing the following odd sequence: >> - partial-lock => failure because it's empty. >> - create a joe >> - partial-lock => success >> - Edit users >> - unlock >> + This is just an odd error handling case that manegers will >> have to cope with and it only exists because of the >> inability to lock an empty tree. >> * Section 2.4.1.2 discusses this aspect of partial-locking, but >> the security implications may be that you don't have >> permission to lock a parent node of for exmaple. IE, >> You shouldn't have to take out lock on just because you >> want to lock (and you shouldn't have to create a user >> before you can lock the table). > [BALAZS]: > I am not sure I fully understand your comment, but here is what I think is > the answer (in YANG > to makes think simpler :-) > > If you have a data model: > > container USERS { > list user { > ... > } > } > > Here you CAN lock the container USERS even if there are no user nodes > below it. The select will > return the USERS node, so it will not be empty. In this case no one else > can touch any of the > user nodes or create a new user. >> >> 3 section 2.1: "Note:" wording >> ------------------------------ >> * First sentence isn't a complete sentence >> * I'd argue this isn't just a "Note" but an interaction with >> another capability and probably should be spelled out more >> importantly than just as a "Note:" that implies it's just >> additional information. > [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / > Candidate Configuration > Capability >> >> 4 section 2.1, starting with "As with most locking..." >> ------------------------------------------------------ >> * Change: >> * "parts of the configuration become dead-locked" => >> * "parts of the configuration *could* become dead-locked" > [BALAZS]: OK >> >> 5 Question about multiple locks from the same session... >> -------------------------------------------------------- >> * Is it allowed? Doesn't say one way or another... >> * Consider: >> 1. lock with one partial nodes A and B >> 2. and then with another try to lock B and C >> 3. Do I get an error because B is locked (by me in this session)? >> 4. or now do I have multiple locks covering A, B and C? >> * I *think* I get an error? >> * If I do have A, B and C locked: >> + and then I release the lock >> + do I still have B and C locked with the second or just C >> (I'd assume B and C)? >> * The document discusses this ramification for but not >> really well for >> * It sort of implies an error further in 2.4.1.1 "If a lock is >> already held on any node..." > [BALAZS]: It is allowed to have multiple locks from the same session. In > 2.4.1.1 will be > reworded to indicate this. In 2.1 it is stated that: > "A NETCONF session MAY have multiple parts of one or more datastores > (running, candidate,startup) locked using partial lock operations. > The operation returns a lock-id to identify each > successfully acquired lock." > Indicating that a session might have multiple locks. > I will also add to 2.4.1: > A NETCONF server MUST be able to grant multiple simultaneous partial locks > to a single NETCONF > session. If the scope of the individual locks overlap, nodes in the common > area MUST be locked > until all of the locks are released. >> >> 6 Section 2.4.1.1: target: >> -------------------------- >> * Wouldn't it be best to state directly: "a may >> only have one parameter?" > [BALAZS]: OK >> >> 7 Section 2.4.1.1: text change >> ------------------------------ >> * "If the device supports the :xpath capability as well any valid" => >> * "If the device supports the :xpath capability *then* any valid" > [BALAZS]: OK >> >> 8 Section 2.4.1.1: first example >> -------------------------------- >> * Shouldn't be within a scope? >> * The schema seems to indicate no >> * But it should (IMHO) if nothing else to match usage >> which does have a parameter. >> + (if memory serves this was discussed early on in netconf and >> it was agreed that all targets should be directly specified >> inside a named or similar parameter tag) > [BALAZS]: OK >> >> 9 Side thought: netconf documents all assume a particular data model >> -------------------------------------------------------------------- >> * Is it just me, or should all the netconf documents be replaced >> once a real data model exists with real example nodes to use? >> * Right now all the examples give the impression that the example >> RPCs will work, when in actuality they won't match the real >> world data models. >> + EG: /interfaces/interface[Id='eth1'] > [BALAZS]: This is just an example no more. IMHO we simply can not avoid > assuming some data > model for now. I agree, it would be nice to later include real examples > from standard modules; > whether we will have the time for that? >> >> 10 Section 2.4.1.1: 2nd to last paragraph: >> ------------------------------------------ >> * Explicitly spelling out an xpath failure is nice to >> understand. But in reality this should be more generic in >> order to handle failing on future select type expressions >> (xpath2) or other syntax errors. Maybe something like "search >> expression type not supported"? > [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later > we will anyway have to > update the RFC, and I don't see how that update would cause problems for a > management system. > Once it gets the error it will anyway know it failed. >> + What type of error do I get back for /users/user[name='Joe > [BALAZS]: Tag: invalid-value >> >> 11 Section 2.4.2: >> ----------------- >> * Nit: Replace "Example: Unlock" with "Example: Unlock a >> previously created lock" >> + or just remove: "Unlock" >> + The title just looks a touch odd as is (incomplete). > [BALAZS]: OK >> >> 12 Section 2.4.2, negative response: >> ------------------------------------ >> * So there is no way to break a lock from a different session? >> Then what happens if a TCP connection drops according to the >> client (or is forced to drop) but the server hasn't realized >> it's closed? >> + Looks like kill-session is the solution based on later reading, >> but I'd suggest spelling it out here. >> + Requires access to the kill-session command to release a >> hung-lock. Possibly worth mentioning in the security >> expectations. > [BALAZS}: OK >> >> 13 Section 2.5 >> -------------- >> * I'd spell out in no uncertain terms that any command that >> modifies a datastore will be blocked, and that "includes" the >> current list. The wording as is could be easily >> misinterpreted to read that the current list is all you need >> to worry about (which I know wasn't the intent). > [BALAZS}: OK >> >> 14 Section 3, second paragraph: first sentence needs ()s or commas >> ------------------------------------------------------------------ >> around the lock types. > [BALAZS}: OK >> >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> ------------------------------------------------------------- >> * I'm not personally convienced still that locking existing >> nodes only is the best solution for partial locking. I know >> it's been debated a bunch in the past but I'm not even >> convienced there is consusus on the subject. I suspect that >> if you counted the number of folks that started an argument >> about it the numbers wouldn't point clearly to a consensus. >> Many of the arguments came at different times, which makes it >> hard to count. >> + That being said, letting this one go forward doesn't >> prohibit a different later solution. > [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad > to see that you can > still live with this solution. >> + I'm not convienced that locking nodes is cheaper to >> implement or execute than evaluating edits based on a >> memorized xpath solution. >> * Comparison: >> * XPATH eval: >> + easier to list in a "list of outstanding locks" table >> + storage cost is very small (a list of xpaths) >> + CPU usage is higher (An eval on every command is required) >> + I think it's more intuitive... There isn't an unknown "it's >> no longer locked because you deleted it" sudden surprise. >> * locking a list of nodes with a eval-once: >> + Lower CPU usage since it's a single xpath eval >> - Higher memory cost (need to memorize every locked node >> either through a list or a flag) >> - Usage complexity is much higher >> - Can't lock empty parent nodes >> - security ramifications require parent nodes for *everything* >> - deleted nodes can be recreated >> * This is most critical when manipulating ordered lists of >> things like access rules (eg, firewall rules) >> * I've seen real-world current discussions surrounding the need >> to put in a parent tree for all nodes *just* because of the >> partial-lock inability to lock a common set of nodes. The >> result of this type of partical lock means either: >> + data models will add extra tree nodes everywhere >> + Or they wont' and it'll turn out later they should have >> because of opreational needs for locking all the subnodes >> and it can't be done. >> - IE, it becomes critical to create a node to >> surround a list of firewall nodes. >> + I think it's worth spelling out this issue in the security >> considerations so that every data model ever created gets a >> otherwise-empty top node added above it so that it can be locked. > [BALAZS}: In my eyes the deciding factor is avoiding surprises. > XPATH surprise 1: > I have a user: John OConnor. I lock him based on his name. Later I correct > his name to John > O'Connor. Whoops suddenly he is not locked. (The name might not even be > the key attribute/leaf). > XPATH surprise 2: > We use XPATH: and "preceding-sibling::*". I modify some data in my > locked nodes. The order of > the nodes might be modified by the modifying their content in the > datastore (e.g. modifying a > leaf called "priority"). Due to the change in priority some nodes that > were previously locked > suddenly become unlocked. > XPATH surprise 3: > I know I have 3 users: Jack and Jill and John. I store my users in > alphabetical order. I want > to lock John so I use from XPATH: "position() = 3" Now another operator > comes and adds user > Blaise. Suddenly I am locking Jill instead of John. > XPATH surprise 4: > Using an XPATH that includes state data or any configuration data that is > not itself locked is > just asking for disaster. > > Probably a many more strange XPATH expressions could be designed. > > regards Balazs > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 8 14:23:27 2008 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 61B363A6AF5; Mon, 8 Sep 2008 14:23:27 -0700 (PDT) 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 08B083A6AF5 for ; Mon, 8 Sep 2008 14:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.778 X-Spam-Level: X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ZEFc6PsReVwQ for ; Mon, 8 Sep 2008 14:23:24 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id C4DB63A6ACD for ; Mon, 8 Sep 2008 14:23:23 -0700 (PDT) Received: (qmail 91195 invoked from network); 8 Sep 2008 21:16:47 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 8 Sep 2008 21:16:47 -0000 Message-ID: <2683A058D57F4D519C59BF787B0BE131@BertLaptop> From: "Bert Wijnen \(IETF\)" To: "netconf mailing list" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: <48C53EEC.4080009@ericsson.com> Date: Mon, 8 Sep 2008 23:16:09 +0200 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] WG, pls review responses from Balazs to Wes. Was: Re: evaluation of the partial-lock document 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 For example, in the below there is this discussion and a question is "do we have consensus" : >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> ------------------------------------------------------------- >> * I'm not personally convienced still that locking existing >> nodes only is the best solution for partial locking. I know >> it's been debated a bunch in the past but I'm not even >> convienced there is consusus on the subject. I suspect that >> if you counted the number of folks that started an argument >> about it the numbers wouldn't point clearly to a consensus. >> Many of the arguments came at different times, which makes it >> hard to count. >> + That being said, letting this one go forward doesn't >> prohibit a different later solution. > [BALAZS}: IMHO we did reach consensus on the issue, > but anyway I am glad to see that you can still live with this solution. Part of any WG Last Call is to make sure that what is the the document being Last Called is indeed consensus of the WG. Unless multiple people speak up, the WG chairs will assume that the document does indeed represent WG consensus. So pls do reveiw the document, Pls do review the responses being posted to Wes's review comments, and DO SPEAK UP if you have concerns or issues. Bert (speaking as co-chair) ----- Original Message ----- From: "Balazs Lengyel" To: "Wes Hardaker" ; "Bert Wijnen - IETF" ; "netconf mailing list" Sent: Monday, September 08, 2008 5:04 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Wes, Bert, > Thanks for the review. Please see the answers for Wes below! > > If you have a look of the attached version, you can see that I also > included Bert's comments. I > basically accepted them all e.g. I added a list of locked-nodes to the > rpc-reply. > > Please indicate if you still have problems with some of the issues. > Balazs > > Wes Hardaker wrote: >> * My final thoughts and concerns on the partial-lock feature as >> a whole are in the last section of this... >> >> >> Netconf WG last call report on partial lock >> =========================================== >> >> Author: Wes Hardaker >> Date: 2008-08-26 16:50:09 PDT >> >> Table of Contents >> ================= >> 1 General Notes >> 2 Thoughts on: Partial locks don't cover non-existing nodes >> 3 section 2.1: "Note:" wording >> 4 section 2.1, starting with "As with most locking..." >> 5 Question about multiple locks from the same session... >> 6 Section 2.4.1.1: target: >> 7 Section 2.4.1.1: text change >> 8 Section 2.4.1.1: first example >> 9 Side thought: netconf documents all assume a particular data model >> 10 Section 2.4.1.1: 2nd to last paragraph: >> 11 Section 2.4.2: >> 12 Section 2.4.2, negative response: >> 13 Section 2.5 >> 14 Section 3, second paragraph: first sentence needs ()s or commas >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> >> >> >> 1 General Notes >> --------------- >> * Document is very well layed out and easy to understand. >> It flows well and is easy to read. >> * But... The English grammar could use some polishing in a few >> more places than I've listed here. >> + I'd recommend the authors hand it to someone that hasn't >> been involved in editing for a simple polishing pass. > [BALAZS]: Will try. >> * My final thoughts and concerns on the partial-lock feature as >> a whole are in the last section of this... >> >> 2 Thoughts on: Partial locks don't cover non-existing nodes >> ----------------------------------------------------------- >> * (Section 2.4.1-ish) >> * note: can't lock a tree part that doesn't exist yet >> * There exists odd an usage case when a tree doesn't yet exist >> (empty configuration). E.G., I can't lock the users tree until >> at least 1 users/user exists. If I try to lock when >> no subelement exists then I believe I get an error back (I'm >> not even positive about this). Section 2.4.1 seems to >> indicate that it'll fail since at least one of the select sets >> MUST be non-empty. >> + The result is that you *must* create a single before >> you can lock the table, for example. IE a manager >> is expected to be able to perform and understand why it's >> doing the following odd sequence: >> - partial-lock => failure because it's empty. >> - create a joe >> - partial-lock => success >> - Edit users >> - unlock >> + This is just an odd error handling case that manegers will >> have to cope with and it only exists because of the >> inability to lock an empty tree. >> * Section 2.4.1.2 discusses this aspect of partial-locking, but >> the security implications may be that you don't have >> permission to lock a parent node of for exmaple. IE, >> You shouldn't have to take out lock on just because you >> want to lock (and you shouldn't have to create a user >> before you can lock the table). > [BALAZS]: > I am not sure I fully understand your comment, but here is what I think is > the answer (in YANG > to makes think simpler :-) > > If you have a data model: > > container USERS { > list user { > ... > } > } > > Here you CAN lock the container USERS even if there are no user nodes > below it. The select will > return the USERS node, so it will not be empty. In this case no one else > can touch any of the > user nodes or create a new user. >> >> 3 section 2.1: "Note:" wording >> ------------------------------ >> * First sentence isn't a complete sentence >> * I'd argue this isn't just a "Note" but an interaction with >> another capability and probably should be spelled out more >> importantly than just as a "Note:" that implies it's just >> additional information. > [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / > Candidate Configuration > Capability >> >> 4 section 2.1, starting with "As with most locking..." >> ------------------------------------------------------ >> * Change: >> * "parts of the configuration become dead-locked" => >> * "parts of the configuration *could* become dead-locked" > [BALAZS]: OK >> >> 5 Question about multiple locks from the same session... >> -------------------------------------------------------- >> * Is it allowed? Doesn't say one way or another... >> * Consider: >> 1. lock with one partial nodes A and B >> 2. and then with another try to lock B and C >> 3. Do I get an error because B is locked (by me in this session)? >> 4. or now do I have multiple locks covering A, B and C? >> * I *think* I get an error? >> * If I do have A, B and C locked: >> + and then I release the lock >> + do I still have B and C locked with the second or just C >> (I'd assume B and C)? >> * The document discusses this ramification for but not >> really well for >> * It sort of implies an error further in 2.4.1.1 "If a lock is >> already held on any node..." > [BALAZS]: It is allowed to have multiple locks from the same session. In > 2.4.1.1 will be > reworded to indicate this. In 2.1 it is stated that: > "A NETCONF session MAY have multiple parts of one or more datastores > (running, candidate,startup) locked using partial lock operations. > The operation returns a lock-id to identify each > successfully acquired lock." > Indicating that a session might have multiple locks. > I will also add to 2.4.1: > A NETCONF server MUST be able to grant multiple simultaneous partial locks > to a single NETCONF > session. If the scope of the individual locks overlap, nodes in the common > area MUST be locked > until all of the locks are released. >> >> 6 Section 2.4.1.1: target: >> -------------------------- >> * Wouldn't it be best to state directly: "a may >> only have one parameter?" > [BALAZS]: OK >> >> 7 Section 2.4.1.1: text change >> ------------------------------ >> * "If the device supports the :xpath capability as well any valid" => >> * "If the device supports the :xpath capability *then* any valid" > [BALAZS]: OK >> >> 8 Section 2.4.1.1: first example >> -------------------------------- >> * Shouldn't be within a scope? >> * The schema seems to indicate no >> * But it should (IMHO) if nothing else to match usage >> which does have a parameter. >> + (if memory serves this was discussed early on in netconf and >> it was agreed that all targets should be directly specified >> inside a named or similar parameter tag) > [BALAZS]: OK >> >> 9 Side thought: netconf documents all assume a particular data model >> -------------------------------------------------------------------- >> * Is it just me, or should all the netconf documents be replaced >> once a real data model exists with real example nodes to use? >> * Right now all the examples give the impression that the example >> RPCs will work, when in actuality they won't match the real >> world data models. >> + EG: /interfaces/interface[Id='eth1'] > [BALAZS]: This is just an example no more. IMHO we simply can not avoid > assuming some data > model for now. I agree, it would be nice to later include real examples > from standard modules; > whether we will have the time for that? >> >> 10 Section 2.4.1.1: 2nd to last paragraph: >> ------------------------------------------ >> * Explicitly spelling out an xpath failure is nice to >> understand. But in reality this should be more generic in >> order to handle failing on future select type expressions >> (xpath2) or other syntax errors. Maybe something like "search >> expression type not supported"? > [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later > we will anyway have to > update the RFC, and I don't see how that update would cause problems for a > management system. > Once it gets the error it will anyway know it failed. >> + What type of error do I get back for /users/user[name='Joe > [BALAZS]: Tag: invalid-value >> >> 11 Section 2.4.2: >> ----------------- >> * Nit: Replace "Example: Unlock" with "Example: Unlock a >> previously created lock" >> + or just remove: "Unlock" >> + The title just looks a touch odd as is (incomplete). > [BALAZS]: OK >> >> 12 Section 2.4.2, negative response: >> ------------------------------------ >> * So there is no way to break a lock from a different session? >> Then what happens if a TCP connection drops according to the >> client (or is forced to drop) but the server hasn't realized >> it's closed? >> + Looks like kill-session is the solution based on later reading, >> but I'd suggest spelling it out here. >> + Requires access to the kill-session command to release a >> hung-lock. Possibly worth mentioning in the security >> expectations. > [BALAZS}: OK >> >> 13 Section 2.5 >> -------------- >> * I'd spell out in no uncertain terms that any command that >> modifies a datastore will be blocked, and that "includes" the >> current list. The wording as is could be easily >> misinterpreted to read that the current list is all you need >> to worry about (which I know wasn't the intent). > [BALAZS}: OK >> >> 14 Section 3, second paragraph: first sentence needs ()s or commas >> ------------------------------------------------------------------ >> around the lock types. > [BALAZS}: OK >> >> 15 Comparison of xpath evaluated partial lock vs locked nodes >> ------------------------------------------------------------- >> * I'm not personally convienced still that locking existing >> nodes only is the best solution for partial locking. I know >> it's been debated a bunch in the past but I'm not even >> convienced there is consusus on the subject. I suspect that >> if you counted the number of folks that started an argument >> about it the numbers wouldn't point clearly to a consensus. >> Many of the arguments came at different times, which makes it >> hard to count. >> + That being said, letting this one go forward doesn't >> prohibit a different later solution. > [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad > to see that you can > still live with this solution. >> + I'm not convienced that locking nodes is cheaper to >> implement or execute than evaluating edits based on a >> memorized xpath solution. >> * Comparison: >> * XPATH eval: >> + easier to list in a "list of outstanding locks" table >> + storage cost is very small (a list of xpaths) >> + CPU usage is higher (An eval on every command is required) >> + I think it's more intuitive... There isn't an unknown "it's >> no longer locked because you deleted it" sudden surprise. >> * locking a list of nodes with a eval-once: >> + Lower CPU usage since it's a single xpath eval >> - Higher memory cost (need to memorize every locked node >> either through a list or a flag) >> - Usage complexity is much higher >> - Can't lock empty parent nodes >> - security ramifications require parent nodes for *everything* >> - deleted nodes can be recreated >> * This is most critical when manipulating ordered lists of >> things like access rules (eg, firewall rules) >> * I've seen real-world current discussions surrounding the need >> to put in a parent tree for all nodes *just* because of the >> partial-lock inability to lock a common set of nodes. The >> result of this type of partical lock means either: >> + data models will add extra tree nodes everywhere >> + Or they wont' and it'll turn out later they should have >> because of opreational needs for locking all the subnodes >> and it can't be done. >> - IE, it becomes critical to create a node to >> surround a list of firewall nodes. >> + I think it's worth spelling out this issue in the security >> considerations so that every data model ever created gets a >> otherwise-empty top node added above it so that it can be locked. > [BALAZS}: In my eyes the deciding factor is avoiding surprises. > XPATH surprise 1: > I have a user: John OConnor. I lock him based on his name. Later I correct > his name to John > O'Connor. Whoops suddenly he is not locked. (The name might not even be > the key attribute/leaf). > XPATH surprise 2: > We use XPATH: and "preceding-sibling::*". I modify some data in my > locked nodes. The order of > the nodes might be modified by the modifying their content in the > datastore (e.g. modifying a > leaf called "priority"). Due to the change in priority some nodes that > were previously locked > suddenly become unlocked. > XPATH surprise 3: > I know I have 3 users: Jack and Jill and John. I store my users in > alphabetical order. I want > to lock John so I use from XPATH: "position() = 3" Now another operator > comes and adds user > Blaise. Suddenly I am locking Jill instead of John. > XPATH surprise 4: > Using an XPATH that includes state data or any configuration data that is > not itself locked is > just asking for disaster. > > Probably a many more strange XPATH expressions could be designed. > > regards Balazs > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 02:17:11 2008 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 37D4F3A6AA9; Tue, 9 Sep 2008 02:17:11 -0700 (PDT) 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 66A253A6AA9 for ; Tue, 9 Sep 2008 02:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 5J5OuoXJElTr for ; Tue, 9 Sep 2008 02:17:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 80AD03A6A0A for ; Tue, 9 Sep 2008 02:17:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 713BC20F8A; Tue, 9 Sep 2008 11:17:12 +0200 (CEST) X-AuditID: c1b4fb3e-a9686bb000007a96-c6-48c63f1843a1 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50786203E5; Tue, 9 Sep 2008 11:17:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:17:07 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:17:07 +0200 Message-ID: <48C63F1A.8070906@ericsson.com> Date: Tue, 09 Sep 2008 11:17:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 09 Sep 2008 09:17:07.0273 (UTC) FILETIME=[D4C4D390:01C9125C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 Hello Bert, AFAIK we have newer done an XSD about an rpc-reply till now. We could start now but: We want to change the content of from anyXML to something more specific. However as is not a top level element in the Netconf XSD I don know how we could do that. rpcResponse is defined as a grouping, so I cant substitute that either. So I found no way to include this information in XSD, that's why I did not include details in the XSD. Balazs Bert Wijnen (IETF) wrote: > ----- Original Message ----- From: "Balazs Lengyel" >> basically accepted them all e.g. I added a list of locked-nodes to the >> rpc-reply. >> > > Thanks. AS a result I can see that in the example and also in the YANG > definition. But I do not see that the list of locked nodes is returned > according to the XFrom netconf-bounces@ietf.org Tue Sep 9 02:17:11 2008 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 37D4F3A6AA9; Tue, 9 Sep 2008 02:17:11 -0700 (PDT) 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 66A253A6AA9 for ; Tue, 9 Sep 2008 02:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102, 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 5J5OuoXJElTr for ; Tue, 9 Sep 2008 02:17:09 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 80AD03A6A0A for ; Tue, 9 Sep 2008 02:17:09 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 713BC20F8A; Tue, 9 Sep 2008 11:17:12 +0200 (CEST) X-AuditID: c1b4fb3e-a9686bb000007a96-c6-48c63f1843a1 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 50786203E5; Tue, 9 Sep 2008 11:17:12 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:17:07 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 11:17:07 +0200 Message-ID: <48C63F1A.8070906@ericsson.com> Date: Tue, 09 Sep 2008 11:17:14 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" References: <48C53EEC.4080009@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 09 Sep 2008 09:17:07.0273 (UTC) FILETIME=[D4C4D390:01C9125C] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 Hello Bert, AFAIK we have newer done an XSD about an rpc-reply till now. We could start now but: We want to change the content of from anyXML to something more specific. However as is not a top level element in the Netconf XSD I don know how we could do that. rpcResponse is defined as a grouping, so I cant substitute that either. So I found no way to include this information in XSD, that's why I did not include details in the XSD. Balazs Bert Wijnen (IETF) wrote: > ----- Original Message ----- From: "Balazs Lengyel" >> basically accepted them all e.g. I added a list of locked-nodes to the >> rpc-reply. >> > > Thanks. AS a result I can see that in the example and also in the YANG > definition. But I do not see that the list of locked nodes is returned > according toSD schema? It looks the same as in revision 3. > It is quite possible I don't understand XSD well enough. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf the XSD schema? It looks the same as in revision 3. > It is quite possible I don't understand XSD well enough. > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 03:27:26 2008 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 7DF5728C12A; Tue, 9 Sep 2008 03:27:26 -0700 (PDT) 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 6A00E3A6C4E for ; Tue, 9 Sep 2008 03:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, 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 1IxYQRMDj-Qv for ; Tue, 9 Sep 2008 03:27:24 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 401693A67EC for ; Tue, 9 Sep 2008 03:27:24 -0700 (PDT) Received: (qmail 40853 invoked from network); 9 Sep 2008 10:25:50 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Sep 2008 10:25:50 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" References: <48C53EEC.4080009@ericsson.com> <48C63F1A.8070906@ericsson.com> In-Reply-To: <48C63F1A.8070906@ericsson.com> Date: Tue, 9 Sep 2008 12:23:11 +0200 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 Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 reason I am/was confused is because in the XSD that you have now, it looks to me as if only a lockID gets returned. In YANG I can see it is a lockID plus a list of locked nodes. Bert ----- Original Message ----- From: "Balazs Lengyel" To: "Bert Wijnen (IETF)" Cc: "Wes Hardaker" ; "netconf mailing list" ; "Martin Bjorklund" Sent: Tuesday, September 09, 2008 11:17 AM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Bert, > AFAIK we have newer done an XSD about an rpc-reply till now. We could > start now but: > > We want to change the content of from anyXML to something more > specific. However as is not a top level element in the Netconf XSD > I don know how we could do that. rpcResponse is defined as a grouping, so > I cant substitute that either. > > So I found no way to include this information in XSD, that's why I did not > include details in the XSD. > > Balazs > > > Bert Wijnen (IETF) wrote: >> ----- Original Message ----- From: "Balazs Lengyel" >>> basically accepted them all e.g. I added a list of locked-nodes to the >>> rpc-reply. >>> >> >> Thanks. AS a result I can see that in the example and also in the YANG >> definition. But I do not see that the list of locked nodes is returned >> according to the XSD schema? It looks the same as in revision 3. >> It is quite possible I don't understand XSD well enough. >> > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 03:27:26 2008 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 7DF5728C12A; Tue, 9 Sep 2008 03:27:26 -0700 (PDT) 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 6A00E3A6C4E for ; Tue, 9 Sep 2008 03:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=0.762, 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 1IxYQRMDj-Qv for ; Tue, 9 Sep 2008 03:27:24 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 401693A67EC for ; Tue, 9 Sep 2008 03:27:24 -0700 (PDT) Received: (qmail 40853 invoked from network); 9 Sep 2008 10:25:50 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Sep 2008 10:25:50 -0000 Message-ID: From: "Bert Wijnen \(IETF\)" To: "Balazs Lengyel" References: <48C53EEC.4080009@ericsson.com> <48C63F1A.8070906@ericsson.com> In-Reply-To: <48C63F1A.8070906@ericsson.com> Date: Tue, 9 Sep 2008 12:23:11 +0200 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 Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 reason I am/was confused is because in the XSD that you have now, it looks to me as if only a lockID gets returned. In YANG I can see it is a lockID plus a list of locked nodes. Bert ----- Original Message ----- From: "Balazs Lengyel" To: "Bert Wijnen (IETF)" Cc: "Wes Hardaker" ; "netconf mailing list" ; "Martin Bjorklund" Sent: Tuesday, September 09, 2008 11:17 AM Subject: Re: [Netconf] evaluation of the partial-lock document > Hello Bert, > AFAIK we have newer done an XSD about an rpc-reply till now. We could > start now but: > > We want to change the content of from anyXML to something more > specific. However as is not a top level element in the Netconf XSD > I don know how we could do that. rpcResponse is defined as a grouping, so > I cant substitute that either. > > So I found no way to include this information in XSD, that's why I did not > include details in the XSD. > > Balazs > > > Bert Wijnen (IETF) wrote: >> ----- Original Message ----- From: "Balazs Lengyel" >>> basically accepted them all e.g. I added a list of locked-nodes to the >>> rpc-reply. >>> >> >> Thanks. AS a result I can see that in the example and also in the YANG >> definition. But I do not see that the list of locked nodes is returned >> according to the XSD schema? It looks the same as in revision 3. >> It is quite possible I don't understand XSD well enough. >> > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 03:51:04 2008 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 DBF3D28C114; Tue, 9 Sep 2008 03:51:04 -0700 (PDT) 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 12B523A6BCA for ; Tue, 9 Sep 2008 03:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 ZFWSpLYvTYbk for ; Tue, 9 Sep 2008 03:51:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D6DE33A6B8B for ; Tue, 9 Sep 2008 03:51:02 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E872F204A4; Tue, 9 Sep 2008 12:51:05 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-17-48c655193980 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D085720076; Tue, 9 Sep 2008 12:51:05 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 12:51:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 12:51:05 +0200 Message-ID: <48C65520.3040609@ericsson.com> Date: Tue, 09 Sep 2008 12:51:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Martin Bjorklund References: <48C53EEC.4080009@ericsson.com> <48C63F1A.8070906@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 09 Sep 2008 10:51:05.0482 (UTC) FILETIME=[F5673EA0:01C91269] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 Hello Bert, I could add something like: Existing: NEW: but locked-node will not appear anywhere else in the XSD (lock-id does). This would not even show that lock-id is included once while locked-node can be included multiple times. (I am not in love with XSD anyway :-( Opinion? Balazs Bert Wijnen (IETF) wrote: > The reason I am/was confused is because in the XSD that you have now, > it looks to me as if only a lockID gets returned. > In YANG I can see it is a lockID plus a list of locked nodes. > > Bert > > ----- Original Message ---From netconf-bounces@ietf.org Tue Sep 9 03:51:04 2008 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 DBF3D28C114; Tue, 9 Sep 2008 03:51:04 -0700 (PDT) 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 12B523A6BCA for ; Tue, 9 Sep 2008 03:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, 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 ZFWSpLYvTYbk for ; Tue, 9 Sep 2008 03:51:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D6DE33A6B8B for ; Tue, 9 Sep 2008 03:51:02 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E872F204A4; Tue, 9 Sep 2008 12:51:05 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-17-48c655193980 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D085720076; Tue, 9 Sep 2008 12:51:05 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 12:51:05 +0200 Received: from [159.107.197.224] ([159.107.197.224]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 12:51:05 +0200 Message-ID: <48C65520.3040609@ericsson.com> Date: Tue, 09 Sep 2008 12:51:12 +0200 From: Balazs Lengyel User-Agent: Thunderbird 2.0.0.4 (X11/20070604) MIME-Version: 1.0 To: "Bert Wijnen (IETF)" , Martin Bjorklund References: <48C53EEC.4080009@ericsson.com> <48C63F1A.8070906@ericsson.com> In-Reply-To: X-OriginalArrivalTime: 09 Sep 2008 10:51:05.0482 (UTC) FILETIME=[F5673EA0:01C91269] X-Brightmail-Tracker: AAAAAA== Cc: netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document 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 Hello Bert, I could add something like: Existing: NEW: but locked-node will not appear anywhere else in the XSD (lock-id does). This would not even show that lock-id is included once while locked-node can be included multiple times. (I am not in love with XSD anyway :-( Opinion? Balazs Bert Wijnen (IETF) wrote: > The reason I am/was confused is because in the XSD that you have now, > it looks to me as if only a lockID gets returned. > In YANG I can see it is a lockID plus a list of locked nodes. > > Bert > > ----- Original Message ----- From: "Balazs Lengyel" > > To: "Bert Wijnen (IETF)" > Cc: "Wes Hardaker" ; "netconf mailing list" > ; "Martin Bjorklund" > Sent: Tuesday, September 09, 2008 11:17 AM > Subject: Re: [Netconf] evaluation of the partial-lock document > > >> Hello Bert, >> AFAIK we have newer done an XSD about an rpc-reply till now. We could >> start now but: >> >> We want to change the content of from anyXML to something more >> specific. However as is not a top level element in the Netconf >> XSD I don know how we could do that. rpcResponse is defined as a >> grouping, so I cant substitute that either. >> >> So I found no way to include this information in XSD, that's why I did >> not include details in the XSD. >> >> Balazs >> >> >> Bert Wijnen (IETF) wrote: >>> ----- Original Message ----- From: "Balazs Lengyel" >>>> basically accepted them all e.g. I added a list of locked-nodes to >>>> the rpc-reply. >>>> >>> >>> Thanks. AS a result I can see that in the example and also in the YANG >>> definition. But I do not see that the list of locked nodes is returned >>> according to the XSD schema? It looks the same as in revision 3. >>> It is quite possible I don't understand XSD well enough. >>> >> >> > > -- 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: "Balazs Lengyel" > > To: "Bert Wijnen (IETF)" > Cc: "Wes Hardaker" ; "netconf mailing list" > ; "Martin Bjorklund" > Sent: Tuesday, September 09, 2008 11:17 AM > Subject: Re: [Netconf] evaluation of the partial-lock document > > >> Hello Bert, >> AFAIK we have newer done an XSD about an rpc-reply till now. We could >> start now but: >> >> We want to change the content of from anyXML to something more >> specific. However as is not a top level element in the Netconf >> XSD I don know how we could do that. rpcResponse is defined as a >> grouping, so I cant substitute that either. >> >> So I found no way to include this information in XSD, that's why I did >> not include details in the XSD. >> >> Balazs >> >> >> Bert Wijnen (IETF) wrote: >>> ----- Original Message ----- From: "Balazs Lengyel" >>>> basically accepted them all e.g. I added a list of locked-nodes to >>>> the rpc-reply. >>>> >>> >>> Thanks. AS a result I can see that in the example and also in the YANG >>> definition. But I do not see that the list of locked nodes is returned >>> according to the XSD schema? It looks the same as in revision 3. >>> It is quite possible I don't understand XSD well enough. >>> >> >> > > -- 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 Tue Sep 9 04:17:56 2008 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 28F123A695F; Tue, 9 Sep 2008 04:17:56 -0700 (PDT) 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 4CAD43A68F4 for ; Tue, 9 Sep 2008 04:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.250, 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 9WgN6y+P+fpd for ; Tue, 9 Sep 2008 04:17:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E0743A67B6 for ; Tue, 9 Sep 2008 04:17:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B9D476C326; Tue, 9 Sep 2008 13:17:57 +0200 (CEST) Date: Tue, 09 Sep 2008 13:18:25 +0200 (CEST) Message-Id: <20080909.131825.211162657.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48C65520.3040609@ericsson.com> References: <48C63F1A.8070906@ericsson.com> <48C65520.3040609@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] evaluation of the partial-lock document 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 Balazs Lengyel wrote: > Hello Bert, > I could add something like: > > Existing: > > > NEW: > Or rather NEW: Maybe that's what you meant. > but locked-node will not appear anywhere else in the XSD (lock-id > does). This would not even show that lock-id is included once while > locked-node can be included multiple times. This is just how XSD works (you could argue that rfc4741 should have used a substitutionGroup for the reply as well. but it didn't). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 04:17:56 2008 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 28F123A695F; Tue, 9 Sep 2008 04:17:56 -0700 (PDT) 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 4CAD43A68F4 for ; Tue, 9 Sep 2008 04:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.250, 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 9WgN6y+P+fpd for ; Tue, 9 Sep 2008 04:17:54 -0700 (PDT) Received: from mail.tail-f.com (de-0316.d.ipeer.se [213.180.79.212]) by core3.amsl.com (Postfix) with ESMTP id 6E0743A67B6 for ; Tue, 9 Sep 2008 04:17:54 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8B9D476C326; Tue, 9 Sep 2008 13:17:57 +0200 (CEST) Date: Tue, 09 Sep 2008 13:18:25 +0200 (CEST) Message-Id: <20080909.131825.211162657.mbj@tail-f.com> To: balazs.lengyel@ericsson.com From: Martin Bjorklund In-Reply-To: <48C65520.3040609@ericsson.com> References: <48C63F1A.8070906@ericsson.com> <48C65520.3040609@ericsson.com> X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] evaluation of the partial-lock document 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 Balazs Lengyel wrote: > Hello Bert, > I could add something like: > > Existing: > > > NEW: > Or rather NEW: Maybe that's what you meant. > but locked-node will not appear anywhere else in the XSD (lock-id > does). This would not even show that lock-id is included once while > locked-node can be included multiple times. This is just how XSD works (you could argue that rfc4741 should have used a substitutionGroup for the reply as well. but it didn't). /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 9 04:36:28 2008 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 3EBD53A6C7C; Tue, 9 Sep 2008 04:36:28 -0700 (PDT) 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 010703A6C7C for ; Tue, 9 Sep 2008 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=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 VADQ8-ppnrW7 for ; Tue, 9 Sep 2008 04:36:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3613D3A6ACF for ; Tue, 9 Sep 2008 04:36:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m89BaMKD003142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 13:36:22 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m89BaLUu024679; Tue, 9 Sep 2008 13:36:22 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 13:36:20 +0200 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_01C91270.4668D332" Date: Tue, 9 Sep 2008 13:36:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] evaluation of the partial-lock document Thread-Index: AckRxDgJq1qey0RQRgK3qVR046esUQAq7ANQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "ext Bert Wijnen (IETF)" X-OriginalArrivalTime: 09 Sep 2008 11:36:20.0207 (UTC) FILETIME=[478167F0:01C91270] Cc: netconf@ietf.org Subject: [Netconf] FW: evaluation of the partial-lock document 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_01C91270.4668D332 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Balazs, All, the Partial Lock schema in the attached draft seems=20 to be valid with one exception. rpcOperationTargetType is defined as a complex type=20 in netconf.xsd, but the PL schema is using it as an=20 element in rpcOperationType. Hence the XML validation gives an error message that=20 it must refer to an existing _element_ (i.e. not compex type). Cheers,=20 Mehmet=20 -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Balazs Lengyel Sent: Monday, September 08, 2008 5:04 PM To: Wes Hardaker; Bert Wijnen - IETF; netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document Hello Wes, Bert, Thanks for the review. Please see the answers for Wes below! If you have a look of the attached version, you can see that I also included Bert's comments. I=20 basically accepted them all e.g. I added a list of locked-nodes to the rpc-reply. Please indicate if you still have problems with some of the issues. Balazs Wes Hardaker wrote: > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... >=20 >=20 > Netconf WG last call report on partial lock > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Author: Wes Hardaker > Date: 2008-08-26 16:50:09 PDT >=20 > Table of Contents > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1 General Notes > 2 Thoughts on: Partial locks don't cover non-existing nodes > 3 section 2.1: "Note:" wording > 4 section 2.1, starting with "As with most locking..." > 5 Question about multiple locks from the same session... > 6 Section 2.4.1.1: target: > 7 Section 2.4.1.1: text change > 8 Section 2.4.1.1: first example > 9 Side thought: netconf documents all assume a particular data model > 10 Section 2.4.1.1: 2nd to last paragraph: > 11 Section 2.4.2: > 12 Section 2.4.2, negative response: > 13 Section 2.5 > 14 Section 3, second paragraph: first sentence needs ()s or commas > 15 Comparison of xpath evaluated partial lock vs locked nodes >=20 >=20 >=20 > 1 General Notes > --------------- > * Document is very well layed out and easy to understand. > It flows well and is easy to read. > * But... The English grammar could use some polishing in a few > more places than I've listed here. > + I'd recommend the authors hand it to someone that hasn't > been involved in editing for a simple polishing pass. [BALAZS]: Will try. > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... >=20 > 2 Thoughts on: Partial locks don't cover non-existing nodes > ----------------------------------------------------------- > * (Section 2.4.1-ish) > * note: can't lock a tree part that doesn't exist yet > * There exists odd an usage case when a tree doesn't yet exist > (empty configuration). E.G., I can't lock the users tree until > at least 1 users/user exists. If I try to lock when > no subelement exists then I believe I get an error back (I'm > not even positive about this). Section 2.4.1 seems to > indicate that it'll fail since at least one of the select sets > MUST be non-empty. > + The result is that you *must* create a single before > you can lock the table, for example. IE a manager > is expected to be able to perform and understand why it's > doing the following odd sequence: > - partial-lock =3D> failure because it's empty. > - create a joe > - partial-lock =3D> success > - Edit users > - unlock > + This is just an odd error handling case that manegers will > have to cope with and it only exists because of the > inability to lock an empty tree. > * Section 2.4.1.2 discusses this aspect of partial-locking, but > the security implications may be that you don't have > permission to lock a parent node of for exmaple. IE, > You shouldn't have to take out lock on just because you > want to lock (and you shouldn't have to create a user > before you can lock the table). [BALAZS]: I am not sure I fully understand your comment, but here is what I think is the answer (in YANG to makes think simpler :-) If you have a data model: container USERS { list user { ... } } Here you CAN lock the container USERS even if there are no user nodes below it. The select will return the USERS node, so it will not be empty. In this case no one else can touch any of the user nodes or create a new user. >=20 > 3 section 2.1: "Note:" wording > ------------------------------ > * First sentence isn't a complete sentence > * I'd argue this isn't just a "Note" but an interaction with > another capability and probably should be spelled out more > importantly than just as a "Note:" that implies it's just > additional information. [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / Candidate Configuration Capability >=20 > 4 section 2.1, starting with "As with most locking..." > ------------------------------------------------------ > * Change: > * "parts of the configuration become dead-locked" =3D> > * "parts of the configuration *could* become dead-locked" [BALAZS]: OK >=20 > 5 Question about multiple locks from the same session... > -------------------------------------------------------- > * Is it allowed? Doesn't say one way or another...=20 > * Consider: > 1. lock with one partial nodes A and B > 2. and then with another try to lock B and C > 3. Do I get an error because B is locked (by me in this session)? > 4. or now do I have multiple locks covering A, B and C? > * I *think* I get an error? > * If I do have A, B and C locked: > + and then I release the lock > + do I still have B and C locked with the second or just C > (I'd assume B and C)? > * The document discusses this ramification for but not > really well for > * It sort of implies an error further in 2.4.1.1 "If a lock is > already held on any node..." [BALAZS]: It is allowed to have multiple locks from the same session. In 2.4.1.1 will be reworded to indicate this. In 2.1 it is stated that: "A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock." Indicating that a session might have multiple locks. I will also add to 2.4.1: A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of the locks are released. >=20 > 6 Section 2.4.1.1: target: > -------------------------- > * Wouldn't it be best to state directly: "a may > only have one parameter?" [BALAZS]: OK >=20 > 7 Section 2.4.1.1: text change > ------------------------------ > * "If the device supports the :xpath capability as well any valid" = =3D> > * "If the device supports the :xpath capability *then* any valid" [BALAZS]: OK >=20 > 8 Section 2.4.1.1: first example > -------------------------------- > * Shouldn't be within a scope? > * The schema seems to indicate no > * But it should (IMHO) if nothing else to match usage > which does have a parameter. > + (if memory serves this was discussed early on in netconf and > it was agreed that all targets should be directly specified > inside a named or similar parameter tag) [BALAZS]: OK >=20 > 9 Side thought: netconf documents all assume a particular data model > -------------------------------------------------------------------- > * Is it just me, or should all the netconf documents be replaced > once a real data model exists with real example nodes to use? > * Right now all the examples give the impression that the example > RPCs will work, when in actuality they won't match the real > world data models. > + EG: /interfaces/interface[Id=3D'eth1'] [BALAZS]: This is just an example no more. IMHO we simply can not avoid assuming some data model for now. I agree, it would be nice to later include real examples from standard modules; whether we will have the time for that? >=20 > 10 Section 2.4.1.1: 2nd to last paragraph: > ------------------------------------------ > * Explicitly spelling out an xpath failure is nice to > understand. But in reality this should be more generic in > order to handle failing on future select type expressions > (xpath2) or other syntax errors. Maybe something like "search > expression type not supported"? [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later we will anyway have to update the RFC, and I don't see how that update would cause problems for a management system. Once it gets the error it will anyway know it failed. > + What type of error do I get back for /users/user[name=3D'Joe [BALAZS]: Tag: invalid-value >=20 > 11 Section 2.4.2: > ----------------- > * Nit: Replace "Example: Unlock" with "Example: Unlock a > previously created lock" > + or just remove: "Unlock" > + The title just looks a touch odd as is (incomplete). [BALAZS]: OK >=20 > 12 Section 2.4.2, negative response: > ------------------------------------ > * So there is no way to break a lock from a different session? > Then what happens if a TCP connection drops according to the > client (or is forced to drop) but the server hasn't realized > it's closed? > + Looks like kill-session is the solution based on later reading, > but I'd suggest spelling it out here. > + Requires access to the kill-session command to release a > hung-lock. Possibly worth mentioning in the security > expectations. [BALAZS}: OK >=20 > 13 Section 2.5 > -------------- > * I'd spell out in no uncertain terms that any command that > modifies a datastore will be blocked, and that "includes" the > current list. The wording as is could be easily > misinterpreted to read that the current list is all you need > to worry about (which I know wasn't the intent). [BALAZS}: OK >=20 > 14 Section 3, second paragraph: first sentence needs ()s or commas > ------------------------------------------------------------------ > around the lock types. [BALAZS}: OK >=20 > 15 Comparison of xpath evaluated partial lock vs locked nodes > ------------------------------------------------------------- > * I'm not personally convienced still that locking existing > nodes only is the best solution for partial locking. I know > it's been debated a bunch in the past but I'm not even > convienced there is consusus on the subject. I suspect that > if you counted the number of folks that started an argument > about it the numbers wouldn't point clearly to a consensus. > Many of the arguments came at different times, which makes it > hard to count. > + That being said, letting this one go forward doesn't > prohibit a different later solution. [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad to see that you can still live with this solution. > + I'm not convienced that locking nodes is cheaper to > implement or execute than evaluating edits based on a > memorized xpath solution. > * Comparison: > * XPATH eval: > + easier to list in a "list of outstanding locks" table > + storage cost is very small (a list of xpaths) > + CPU usage is higher (An eval on every command is required) > + I think it's more intuitive... There isn't an unknown "it's > no longer locked because you deleted it" sudden surprise. > * locking a list of nodes with a eval-once: > + Lower CPU usage since it's a single xpath eval > - Higher memory cost (need to memorize every locked node > either through a list or a flag) > - Usage complexity is much higher > - Can't lock empty parent nodes > - security ramifications require parent nodes for *everything* > - deleted nodes can be recreated > * This is most critical when manipulating ordered lists of > things like access rules (eg, firewall rules) > * I've seen real-world current discussions surrounding the need > to put in a parent tree for all nodes *just* because of the > partial-lock inability to lock a common set of nodes. The > result of this type of partical lock means either: > + data models will add extra tree nodes everywhere > + Or they wont' and it'll turn out later they should have > because of opreational needs for locking all the subnodes > and it can't be done. > - IE, it becomes critical to create a node to > surround a list of firewall nodes. > + I think it's worth spelling out this issue in the security > considerations so that every data model ever created gets a > otherwise-empty top node added above it so that it can be locked. [BALAZS}: In my eyes the deciding factor is avoiding surprises. XPATH surprise 1: I have a user: John OConnor. I lock him based on his name. Later I correct his name to John O'Connor. Whoops suddenly he is not locked. (The name might not even be the key attribute/leaf). XPATH surprise 2: We use XPATH: and "preceding-sibling::*". I modify some data in my locked nodes. The order of the nodes might be modified by the modifying their content in the datastore (e.g. modifying a leaf called "priority"). Due to the change in priority some nodes that were previously locked suddenly become unlocked. XPATH surprise 3: I know I have 3 users: Jack and Jill and John. I store my users in alphabetical order. I want to lock John so I use from XPATH: "position() =3D 3" Now another = operator comes and adds user Blaise. Suddenly I am locking Jill instead of John. XPATH surprise 4: Using an XPATH that includes state data or any configuration data that is not itself locked is just asking for disaster. Probably a many more strange XPATH expressions could be designed. regards Balazs ------_=_NextPart_001_01C91270.4668D332 Content-Type: text/plain; name="draft-ietf-netconf-partial-lock-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-netconf-partial-lock-04.txt Content-Disposition: inline; filename="draft-ietf-netconf-partial-lock-04.txt" DQoNCg0KTkVUQ09ORiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCLiBMZW5neWVsDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkNCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIEJqb3JrbHVuZA0K RXhwaXJlczogTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRhaWwtZiBTeXN0ZW1zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMDgsIDIwMDgNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORg0KICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtbmV0Y29uZi1wYXJ0aWFsLWxvY2stMDQNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQog ICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2Vu dHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Yg d2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9z ZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUg ZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0 aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBj dXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJu ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBNYXJjaCAxMiwgMjAwOS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhlIE5F VENPTkYgcHJvdG9jb2wgZGVmaW5lcyB0aGUgbG9jayBhbmQgdW5sb2NrIFJQQ3MgdGhhdCBsb2Nr DQogICBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiAgSW4gc29tZSBzaXR1YXRpb25z LCBhIHdheSB0byBsb2NrDQogICBvbmx5IHBhcnRzIG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmUgaXMgcmVxdWlyZWQuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIGEgY2FwYWJpbGl0eS1i YXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgZm9yDQogICBsb2NraW5nIHBv cnRpb25zIG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuDQoNCg0KDQoNCg0KTGVuZ3llbCAm IEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgIFtQ YWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVU Q09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDMNCiAgICAgMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFBhcnRpYWwgTG9ja2luZyBDYXBh YmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDIuMS4g IE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgICAgMi4yLiAgRGVwZW5kZW5jaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAyLjMuICBDYXBhYmlsaXR5IElkZW50aWZpZXIg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIuNC4gIE5ldyBP cGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQN CiAgICAgICAyLjQuMS4gIDxwYXJ0aWFsLWxvY2s+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNA0KICAgICAgIDIuNC4yLiAgPHBhcnRpYWwtdW5sb2NrPiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDIuNS4gIE1vZGlmaWNhdGlv bnMgdG8gRXhpc3RpbmcgT3BlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAg Mi42LiAgSW50ZXJhY3Rpb25zIHdpdGggT3RoZXIgQ2FwYWJpbGl0aWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOQ0KICAgICAgIDIuNi4xLiAgV3JpdGFibGUtUnVubmluZyBDYXBhYmlsaXR5ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAgMi42LjIuICBDYW5kaWRhdGUgQ29u ZmlndXJhdGlvbiBDYXBhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgICAyLjYu My4gIERpc3RpbmN0IFN0YXJ0dXAgQ2FwYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMA0KICAgMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICA0LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgIDUuICBBcHBlbmRpeCBB ICAtICBYTUwgU2NoZW1hIGZvciBQYXJ0aWFsIExvY2tpbmcgIChub3JtYXRpdmUpIC4gLiAxMg0K ICAgNi4gIEFwcGVuZGl4IEIgIC0gWUFORyBNb2R1bGUgZm9yIFBhcnRpYWwgTG9ja2luZw0KICAg ICAgIChub24tbm9ybWF0aXZlKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE0DQogICA3LiAgQXBwZW5kaXggQyAgLSAgQ2hhbmdlIExvZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNy4xLiAgMDMtMDQgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICA3LjIu ICAwMi0wMyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE2DQogICAgIDcuMy4gIDAxLTAyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNy40LiAgMDAtMDEgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICA3LjUuICAtMDAg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2 DQogICA4LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTcNCiAgIDkuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICA5LjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAg IDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTgNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJl cyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIg MjAwOA0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIE5FVENPTkYgcHJvdG9jb2wgW05F VENPTkZdIGRlc2NyaWJlcyB0aGUgbG9jayBhbmQgdW5sb2NrIFJQQ3MNCiAgIHRoYXQgb3BlcmF0 ZSBvbiBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiAgT2Z0ZW4sIG11bHRpcGxlDQog ICBtYW5hZ2VtZW50IHNlc3Npb25zIG5lZWQgdG8gYmUgYWJsZSB0byBtb2RpZnkgdGhlIGNvbmZp Z3VyYXRpb24gb2YgYQ0KICAgbWFuYWdlZCBkZXZpY2UgaW4gcGFyYWxsZWwuICBJbiB0aGVzZSBj YXNlcywgbG9ja2luZyBvbmx5IHBhcnRzIG9mIGENCiAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IGlzIG5lZWRlZC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbg0KICAgZXh0ZW5zaW9uIHRvIHRo ZSBORVRDT05GIHByb3RvY29sIHRvIGFsbG93IHRoaXMuDQoNCiAgIFRoZSBtZWNoYW5pc20gZm9y IHBhcnRpYWwgbG9ja2luZyBpcyBiYXNlZCBvbiB0aGUgZXhpc3RpbmcgWFBhdGgNCiAgIGZpbHRl cmluZyBtZWNoYW5pc21zLg0KDQogICBQYXJ0aWFsIGxvY2tpbmcgaXMgZGVmaW5lZCBhcyBhIGNh cGFiaWxpdHkgdG8gTkVUQ09ORi4NCg0KMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcw0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9U IFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZA0KICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gQkNQDQogICAxNCwgW1JGQzIx MTldLg0KDQoNCjIuICBQYXJ0aWFsIExvY2tpbmcgQ2FwYWJpbGl0eQ0KDQoyLjEuICBPdmVydmll dw0KDQogICBUaGUgOnBhcnRpYWwtbG9jayBjYXBhYmlsaXR5IGluZGljYXRlcyB0aGF0IHRoZSBk ZXZpY2Ugc3VwcG9ydHMgdGhlDQogICBsb2NraW5nIG9mIGl0cyBjb25maWd1cmF0aW9uIHdpdGgg YSBzY29wZSBzbWFsbGVyIHRoZW4gYSBjb21wbGV0ZQ0KICAgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmUuICBUaGUgc2NvcGUgdG8gYmUgbG9ja2VkIGlzIHNwZWNpZmllZCBieQ0KICAgdXNpbmcgcmVz dHJpY3RlZCBvciBmdWxsIFhQYXRoIGV4cHJlc3Npb25zLiAgUGFydGlhbCBsb2NraW5nIGNvdmVy cw0KICAgY29uZmlndXJhdGlvbiBkYXRhLCBidXQgbm90IHN0YXRlIGRhdGEuDQoNCiAgIFRoZSBz eXN0ZW0gTVVTVCBlbnN1cmUgdGhhdCBjb25maWd1cmF0aW9uIHJlc291cmNlcyBjb3ZlcmVkIGJ5 IHRoZQ0KICAgbG9jayBhcmUgbm90IG1vZGlmaWVkIGJ5IG90aGVyIE5FVENPTkYgb3Igbm9uLU5F VENPTkYgbWFuYWdlbWVudA0KICAgb3BlcmF0aW9ucyBzdWNoIGFzIFNOTVAgYW5kIHRoZSBDTEku DQoNCiAgIFRoZSBkdXJhdGlvbiBvZiB0aGUgcGFydGlhbCBsb2NrIGlzIGRlZmluZWQgYXMgYmVn aW5uaW5nIHdoZW4gdGhlDQogICBwYXJ0aWFsIGxvY2sgaXMgZ3JhbnRlZC4gIFRoZSBwYXJ0aWFs IGxvY2sgbGFzdHMgdW50aWwgZWl0aGVyIHRoZQ0KICAgY29ycmVzcG9uZGluZyA8cGFydGlhbC11 bmxvY2s+IG9wZXJhdGlvbiBzdWNjZWVkcyBvciB0aGUgTkVUQ09ORg0KICAgc2Vzc2lvbiB0ZXJt aW5hdGVzLg0KDQogICBBIE5FVENPTkYgc2Vzc2lvbiBNQVkgaGF2ZSBtdWx0aXBsZSBwYXJ0cyBv ZiBvbmUgb3IgbW9yZSBkYXRhc3RvcmVzDQogICAocnVubmluZywgY2FuZGlkYXRlLHN0YXJ0dXAp IGxvY2tlZCB1c2luZyBwYXJ0aWFsIGxvY2sgb3BlcmF0aW9ucy4NCiAgIFRoZSA8cGFydGlhbC1s b2NrPiBvcGVyYXRpb24gcmV0dXJucyBhIGxvY2staWQgdG8gaWRlbnRpZnkgZWFjaA0KICAgc3Vj Y2Vzc2Z1bGx5IGFjcXVpcmVkIGxvY2suDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5k ICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAg ICBTZXB0ZW1iZXIgMjAwOA0KDQoNCjIuMi4gIERlcGVuZGVuY2llcw0KDQogICBUaGUgZGV2aWNl IE1VU1Qgc3VwcG9ydCB0aGUgcmVzdHJpY3RlZCBYUGF0aCBleHByZXNzaW9ucyBpbiB0aGUNCiAg IHNlbGVjdCBlbGVtZW50LCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQuMS4gIElmIG9wdGlv bmFsbHkgdGhlDQogICA6eHBhdGggY2FwYWJpbGl0eSBpcyBhbHNvIHN1cHBvcnRlZCwgdGhlIGRl dmljZSBNVVNUIGFsc28gc3VwcG9ydCB0aGUNCiAgIHVzYWdlIG9mIGFueSBYUGF0aCAxLjAgZXhw cmVzc2lvbiBpbiB0aGUgc2VsZWN0IGVsZW1lbnQuDQoNCjIuMy4gIENhcGFiaWxpdHkgSWRlbnRp Zmllcg0KDQogICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5OnBhcnRpYWwtbG9j azoxLjANCg0KMi40LiAgTmV3IE9wZXJhdGlvbnMNCg0KMi40LjEuICA8cGFydGlhbC1sb2NrPg0K DQogICBUaGUgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uIGFsbG93cyB0aGUgY2xpZW50IHRvIGxv Y2sgYSBwb3J0aW9uIG9mIGENCiAgIGRhdGEgc3RvcmUuICBUaGUgcG9ydGlvbiB0byBsb2NrIGlz IHNwZWNpZmllZCBieSB1c2luZyBYUGF0aA0KICAgZXhwcmVzc2lvbnMgaW4gdGhlIHNlbGVjdCBl bGVtZW50cyBvZiB0aGUgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uLg0KICAgRWFjaCBYUGF0aCBl eHByZXNzaW9uIE1VU1QgcmV0dXJuIGEgbm9kZSBzZXQuICBMb2NraW5nIGEgbm9kZQ0KICAgcHJv dGVjdHMgdGhlIGNvbXBsZXRlIHN1YnRyZWUgdW5kZXIgaXQgZnJvbSBtb2RpZmljYXRpb24gYnkg b3RoZXJzLg0KDQogICBUaGUgc2VsZWN0IFhQYXRoIGV4cHJlc3Npb25zIGFyZSBldmFsdWF0ZWQg b25seSBvbmNlIGF0IGxvY2sgdGltZSwNCiAgIHRoZXJlYWZ0ZXIgdGhlIHNjb3BlIG9mIHRoZSBs b2NrIGlzIG1haW50YWluZWQgYXMgYSBzZXQgb2Ygbm9kZXMuICBJZg0KICAgdGhlIGNvbmZpZ3Vy YXRpb24gZGF0YSBpcyBsYXRlciBhbHRlcmVkIGluIGEgd2F5IHRoYXQgd291bGQgbWFrZSB0aGUN CiAgIG9yaWdpbmFsIHNlbGVjdCBYUGF0aCBleHByZXNzaW9ucyBldmFsdWF0ZSB0byBhIGRpZmZl cmVudCBzZXQgb2YNCiAgIG5vZGVzLCB0aGlzIGRvZXMgbm90IGFmZmVjdCB0aGUgc2NvcGUgb2Yg dGhlIHBhcnRpYWwgbG9jay4NCg0KICAgWFBhdGggaXMgb25seSB1c2VkIGZvciB0aGUgY3JlYXRp b24gb2YgdGhlIHBhcnRpYWwgbG9jay4NCiAgIENvbmNlcHR1YWxseSB0aGUgc2NvcGUgb2YgdGhl IGxvY2sgaXMgZGVmaW5lZCBieSB0aGUgcmV0dXJuZWQgbm9kZQ0KICAgc2V0IGFuZCBub3QgYnkg dGhlIFhQYXRoIGV4cHJlc3Npb24uDQoNCiAgIEEgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uIE1V U1QgYmUgaGFuZGxlZCBhdG9taWNhbGx5IGJ5IHRoZSBORVRDT05GDQogICBzZXJ2ZXIuICBUaGUg c2VydmVyIGVpdGhlciBsb2NrcyBhbGwgcmVxdWVzdGVkIHBhcnRzIG9mIHRoZSBkYXRhDQogICBz dG9yZSBvciBub25lOyBJLmUuIGlmIGR1cmluZyB0aGUgb3BlcmF0aW9uIG9uZSBvZiB0aGUgcmVx dWVzdGVkDQogICBwYXJ0cyBjYW5ub3QgYmUgbG9ja2VkIHRoZSBzZXJ2ZXIgTVVTVCB1bmxvY2sg YWxsIHBhcnRzIHRoYXQgaGF2ZQ0KICAgYmVlbiBhbHJlYWR5IGxvY2tlZCBkdXJpbmcgdGhhdCBv cGVyYXRpb24uDQoNCiAgIElmIGEgbm9kZSBpcyBsb2NrZWQgYnkgYSBzZXNzaW9uLCBvbmx5IHRo YXQgc2FtZSBzZXNzaW9uIGlzIGFibGUgdG8NCiAgIG1vZGlmeSB0aGF0IG5vZGUgb3IgYW55IG5v ZGUgaW4gdGhlIHN1YnRyZWUgdW5kZXJuZWF0aCBpdC4NCg0KICAgSWYgYSB0b3AgbGV2ZWwgbm9k ZSBvZiBhIGxvY2tlZCBzdWJ0cmVlIGlzIGRlbGV0ZWQsIGFueSBvdGhlciBzZXNzaW9uDQogICBj YW4gcmVjcmVhdGUgaXQsIGFzIGl0IGlzIG5vdCBjb3ZlcmVkIGJ5IHRoZSBsb2NrIGFueW1vcmUu ICBJZiBhbGwNCiAgIHRvcCBsZXZlbCBub2RlcyBhcmUgZGVsZXRlZCwgdGhlIGxvY2sgd2lsbCBz dGlsbCBiZSBwcmVzZW50LCBob3dldmVyDQogICBpdCdzIHNjb3BlIHdpbGwgYmVjb21lIG5pbCBp LmUuIGl0IHdpbGwgbm90IGNvdmVyIGFueSBub2Rlcy4NCg0KICAgQSBORVRDT05GIHNlcnZlciBN VVNUIGJlIGFibGUgdG8gZ3JhbnQgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIHBhcnRpYWwNCiAgIGxv Y2tzIHRvIGEgc2luZ2xlIE5FVENPTkYgc2Vzc2lvbi4gIElmIHRoZSBzY29wZSBvZiB0aGUgaW5k aXZpZHVhbA0KICAgbG9ja3Mgb3ZlcmxhcCwgbm9kZXMgaW4gdGhlIGNvbW1vbiBhcmVhIE1VU1Qg YmUgbG9ja2VkIHVudGlsIGFsbCBvZg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4 cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVt YmVyIDIwMDgNCg0KDQogICB0aGUgbG9ja3MgYXJlIHJlbGVhc2VkLg0KDQogICBBIHBhcnRpYWwg bG9jayBvcGVyYXRpb24gTVVTVCBmYWlsIGlmOg0KDQogICBvICBBbnkgTkVUQ09ORiBzZXNzaW9u IChpbmNsdWRpbmcgdGhlIGN1cnJlbnQgc2Vzc2lvbikgb3ducyB0aGUNCiAgICAgIGdsb2JhbCBs b2NrIG9uIHRoZSBkYXRhc3RvcmUuDQoNCiAgIG8gIEFueSBwYXJ0IG9mIHRoZSBzY29wZSB0byBi ZSBsb2NrZWQgaXMgYWxyZWFkeSBsb2NrZWQgYnkgYW5vdGhlcg0KICAgICAgbWFuYWdlbWVudCBz ZXNzaW9uL3Byb3RvY29sLCBpbmNsdWRpbmcgb3RoZXIgTkVUQ09ORiBzZXNzaW9ucw0KICAgICAg dXNpbmcgdGhlIDxwYXJ0aWFsLWxvY2s+IG9yIGFueSBvdGhlciBub24tTkVUQ09ORiBtYW5hZ2Vt ZW50DQogICAgICBtZXRob2QuDQoNCiAgIG8gIFRoZSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRz IGFjY2VzcyBjb250cm9sIGFuZCB0aGUgbG9ja2luZyB1c2VyDQogICAgICBkb2VzIG5vdCBoYXZl IHN1ZmZpY2llbnQgcHJpdmlsZWdlcywgdG8gYWxsIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmUNCiAg ICAgIHNlY3Rpb24gdG8gYmUgbG9ja2VkLiAgVGhlIGV4YWN0IGhhbmRsaW5nIG9mIGFjY2VzcyBy aWdodHMgaXMNCiAgICAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIGJ1dCBp dCBpcyBhc3N1bWVkIHRoYXQgdGhlcmUNCiAgICAgIGlzIGFuIGFjY2VzcyBjb250cm9sIHN5c3Rl bSB0aGF0IE1BWSBkZW55IG9yIGFsbG93IHRoZSBwYXJ0aWFsDQogICAgICBsb2NrIG9wZXJhdGlv bi4NCg0KICAgTm90ZTogSWYgcGFydGlhbCBsb2NrIGlzIHJlcXVlc3RlZCBmb3IgdGhlIHJ1bm5p bmcgZGF0YXN0b3JlLCBhbmQgdGhlDQogICBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRzIHRoZSA6 Y29uZmlybWVkLWNvbW1pdCBjYXBhYmlsaXR5LCBhbmQgdGhlcmUNCiAgIHdhcyBhIHJlY2VudCBj b25maXJtZWQgPGNvbW1pdD4gb3BlcmF0aW9uLCB3aGVyZSB0aGUgY29uZmlybWluZw0KICAgPGNv bW1pdD4gb3BlcmF0aW9uIGhhcyBub3QgYmVlbiByZWNlaXZlZC4gIEluIHRoaXMgY2FzZSB0aGUg bG9jayBNVVNUDQogICBiZSBkZW5pZWQsIGJlY2F1c2UgaWYgdGhlIGNvbmZpcm1hdGlvbiBkb2Vz IG5vdCBhcnJpdmUsIHRoZSBydW5uaW5nDQogICBkYXRhc3RvcmUgTVVTVCBiZSByb2xsZWQgYmFj ayB0byBpdHMgc3RhdGUgYmVmb3JlIHRoZSBjb21taXQsIHRodXMNCiAgIHRoZSBORVRDT05GIHNl cnZlciBtaWdodCBuZWVkIHRvIG1vZGlmeSB0aGUgY29uZmlndXJhdGlvbi4NCg0KICAgQXMgd2l0 aCBtb3N0IGxvY2tpbmcgc3lzdGVtcywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGF0IHR3bw0K ICAgbWFuYWdlbWVudCBzZXNzaW9ucyB0cnlpbmcgdG8gbG9jayBkaWZmZXJlbnQgcGFydHMgb2Yg dGhlDQogICBjb25maWd1cmF0aW9uIGNvdWxkIGJlY29tZSBkZWFkLWxvY2tlZC4gIFRvIGF2b2lk IHRoaXMgc2l0dWF0aW9uLA0KICAgY2xpZW50cyBTSE9VTEQgbG9jayBldmVyeXRoaW5nIHRoZXkg bmVlZCBpbiBvbmUgb3BlcmF0aW9uLiAgSWYgdGhhdA0KICAgb3BlcmF0aW9uIHN0aWxsIGZhaWxz LCB0aGUgY2xpZW50IFNIT1VMRCBiYWNrIGRvd24sIHJlbGVhc2UgYW55DQogICBhbHJlYWR5IGFj cXVpcmVkIGxvY2tzLCBhbmQgcmV0cnkgdGhlIHByb2NlZHVyZSBhZnRlciBzb21lIHRpbWUNCiAg IGludGVydmFsLiAgVGhlIGxlbmd0aCBvZiB0aGUgaW50ZXJ2YWwgc2hvdWxkIHByZWZlcmFibHkg YmUgcmFuZG9tIHRvDQogICBhdm9pZCByZXBlYXRlZCBkZWFkLWxvY2tzIHdoZW4gYm90aCAob3Ig YWxsKSBjbGllbnRzIGJhY2sgZG93biBhbmQNCiAgIHRoZW4gcmVwZWF0IGxvY2tpbmcuDQoNCiAg IEl0IGlzIHRoZSBpbnRlbnRpb24gdG8ga2VlcCBwYXJ0aWFsLWxvY2tpbmcgc2ltcGxlLCBzbyB3 aGVuIGEgcGFydGlhbA0KICAgbG9jayBpcyBleGVjdXRlZCB5b3UgZ2V0IHdoYXQgeW91IGFza2Vk IGZvcjogYSBzZXQgb2Ygbm9kZXMgdGhhdCBhcmUNCiAgIGxvY2tlZCBmb3Igd3JpdGluZy4gIFRo ZXJlIGFyZSBzb21lIG90aGVyIGlzc3VlcyB0aGF0IGFyZQ0KICAgaW50ZW50aW9uYWxseSBub3Qg YWRkcmVzc2VkIGZvciB0aGUgc2FrZSBvZiBzaW1wbGljaXR5Og0KDQogICBvICBMb2NraW5nIGRv ZXMgbm90IGFmZmVjdCByZWFkIG9wZXJhdGlvbnMuDQoNCiAgIG8gIElmIGEgcGFydCBvZiBhIGRh dGFzdG9yZSBpcyBsb2NrZWQsIHRoaXMgaGFzIG5vIGVmZmVjdCBvbiBhbnkNCiAgICAgIHVubG9j a2VkIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmUuICBJZiB0aGlzIGlzIGEgcHJvYmxlbSBlLmcuIHRo ZQ0KICAgICAgb3BlcmF0b3IncyBjaGFuZ2VzIGRlcGVuZCBvbiBkYXRhIHZhbHVlcyBpbiB0aGUg dW5sb2NrZWQgcGFydCBvZg0KICAgICAgdGhlIGRhdGFzdG9yZSwgdGhlIG9wZXJhdG9yIHNob3Vs ZCBpbmNsdWRlIHRoZXNlIHZhbHVlcyBpbiB0aGUNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQg ICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAg IFNlcHRlbWJlciAyMDA4DQoNCg0KICAgICAgc2NvcGUgb2YgdGhlIGxvY2suDQoNCiAgIG8gIEFu IG9wZXJhdG9yIGlzIGFsbG93ZWQgdG8gZWRpdCB0aGUgY29uZmlndXJhdGlvbiBib3RoIGluc2lk ZSBhbmQNCiAgICAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEgbG9jay4gIEl0IGlzIHRoZSBvcGVy YXRvcidzIHJlc3BvbnNpYmlsaXR5DQogICAgICB0byBsb2NrIGFsbCBwYXJ0cyBvZiB0aGUgZGF0 YXN0b3JlIHRoYXQgYXJlIGNydWNpYWwgZm9yIGEgc3BlY2lmaWMNCiAgICAgIG1hbmFnZW1lbnQg YWN0aW9uLg0KDQoNCiAgIE5vdGU6IFRoZSA8cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gZG9lcyBu b3QgbW9kaWZ5IHRoZSBnbG9iYWwgPGxvY2s+DQogICBvcGVyYXRpb24gZGVmaW5lZCBpbiB0aGUg YmFzZSBORVRDT05GIFByb3RvY29sIFtORVRDT05GXS4gIElmIHBhcnQgb2YNCiAgIGEgZGF0YXN0 b3JlIGlzIGFscmVhZHkgbG9ja2VkIGJ5IDxwYXJ0aWFsLWxvY2s+LCB0aGVuIGEgZ2xvYmFsIGxv Y2sNCiAgIGZvciB0aGF0IGRhdGFzdG9yZSBmYWlscyBldmVuIGlmIHRoZSBnbG9iYWwgbG9jayBp cyBhdHRlbXB0ZWQgYnkgdGhlDQogICBzYW1lIE5FVENPTkYgc2Vzc2lvbiB3aGljaCBvd25zIHRo ZSBwYXJ0aWFsLWxvY2suDQoNCjIuNC4xLjEuICBQYXJhbWV0ZXJzLCBSZXN1bHQsIEV4YW1wbGVz DQoNCiAgIFBhcmFtZXRlcnM6DQoNCiAgIHRhcmdldDogIE5hbWUgb2YgdGhlIGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlIG9mIHdoaWNoIGEgcGFydCBzaGFsbCBiZQ0KICAgICAgIGxvY2tlZC4gIE9u ZSA8cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gY2FuIGFmZmVjdCBvbmx5IG9uZSBvZiB0aGUNCiAg ICAgICBkYXRhc3RvcmVzLCBzbyBvbmx5IG9uZSA8dGFyZ2V0PiBwYXJhbWV0ZXIgaXMgYWxsb3dl ZC4gIFVSTHMgYXJlDQogICAgICAgbm90IGFjY2VwdGVkLg0KDQogICBzZWxlY3Q6ICBPbmUgb3Ig bW9yZSAnc2VsZWN0JyBlbGVtZW50cyBlYWNoIGNvbnRhaW5pbmcgYW4gWFBhdGgNCiAgICAgICBl eHByZXNzaW9uLiAgVGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIGluIGEgY29udGV4 dCB3aGVyZQ0KICAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3Qgb2YgdGhlIHNlcnZl cidzIGNvbmNlcHR1YWwgZGF0YQ0KICAgICAgIG1vZGVsLCBhbmQgdGhlIHNldCBvZiBuYW1lc3Bh Y2UgZGVjbGFyYXRpb25zIGFyZSB0aG9zZSBpbiBzY29wZQ0KICAgICAgIG9uIHRoZSBzZWxlY3Qg ZWxlbWVudC4NCg0KICAgICAgIFRoZSBzZWxlY3QgZXhwcmVzc2lvbnMgTVVTVCBlYWNoIHJldHVy biBhIG5vZGUgc2V0LCBhbmQgYXQgbGVhc3QNCiAgICAgICBvbmUgb2YgdGhlIG5vZGUgc2V0cyBt dXN0IGJlIG5vbi1lbXB0eS4NCg0KICAgICAgIElmIHRoZSBkZXZpY2Ugc3VwcG9ydHMgdGhlIDp4 cGF0aCBjYXBhYmlsaXR5IHRoZW4gYW55IHZhbGlkIFhQYXRoDQogICAgICAgMS4wIGV4cHJlc3Np b24gY2FuIGJlIHVzZWQsIGlmIG5vdCwgdGhlIFhQYXRoIGV4cHJlc3Npb24gTVVTVCBiZQ0KICAg ICAgIGxpbWl0ZWQgdG8gYW4gSW5zdGFuY2UgSWRlbnRpZmllciBleHByZXNzaW9uLiAgQW4gSW5z dGFuY2UNCiAgICAgICBJZGVudGlmaWVyIGlzIGFuIGFic29sdXRlIHBhdGggZXhwcmVzc2lvbiBp biBhYmJyZXZpYXRlZCBzeW50YXgsDQogICAgICAgd2hlcmUgcHJlZGljYXRlcyBhcmUgdXNlZCBv bmx5IHRvIHNwZWNpZnkgdmFsdWVzIGZvciBub2Rlcw0KICAgICAgIGRlZmluZWQgYXMga2V5cyB0 byBkaXN0aW5ndWlzaCBtdWx0aXBsZSBpbnN0YW5jZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9j ayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAgRXhhbXBsZTog TG9jayB2aXJ0dWFsIHJvdXRlciAxIGFuZCBpbnRlcmZhY2UgZXRoMQ0KDQoNCiAgICAgICA8bmM6 cnBjDQogICAgICAgICB4bWxuczpuYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJh c2U6MS4wIg0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpw YXJ0aWFsLWxvY2s6MS4wIg0KICAgICAgICAgbmM6bWVzc2FnZS1pZD0iMTM1Ij4NCiAgICAgICAg ICAgPHBhcnRpYWwtbG9jaz4NCiAgICAgICAgICAgICAgIDxuYzp0YXJnZXQ+DQogICAgICAgICAg ICAgICAgICAgPG5jOnJ1bm5pbmcvPg0KICAgICAgICAgICAgICAgPC9uYzp0YXJnZXQ+DQogICAg ICAgICAgICAgICA8c2VsZWN0IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvcm91dGUiPg0K ICAgICAgICAgICAgICAgICAgIC9yb3V0aW5nL3ZpcnR1YWxSb3V0ZXJbcm91dGVyTmFtZT0ncm91 dGVyMSddDQogICAgICAgICAgICAgICA8L3NlbGVjdD4NCiAgICAgICAgICAgICAgIDxzZWxlY3Qg eG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pbnRlcmZhY2UiPg0KICAgICAgICAgICAgICAg ICAgIC9pbnRlcmZhY2VzL2ludGVyZmFjZVtpZD0nZXRoMSddDQogICAgICAgICAgICAgICAgPC9z ZWxlY3Q+DQogICAgICAgICAgICA8L3BhcnRpYWwtbG9jaz4NCiAgICAgICA8L25jOnJwYz4NCg0K ICAgICAgIDxuYzpycGMtcmVwbHkNCiAgICAgICAgIHhtbG5zOm5jPSJ1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiDQogICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazoxLjAiDQogICAgICAgICBuYzptZXNzYWdlLWlk PSIxMzUiPg0KICAgICAgICAgICA8bmM6ZGF0YT4NCiAgICAgICAgICAgICAgIDxsb2NrLWlkPjEy NzwvbG9jay1pZD4NCiAgICAgICAgICAgICAgIDxsb2NrZWQtbm9kZSB4bWxucz0iaHR0cDovL2V4 YW1wbGUuY29tL25zL3JvdXRlIj4NCiAgICAgICAgICAgICAgICAgICAvcm91dGluZy92aXJ0dWFs Um91dGVyW3JvdXRlck5hbWU9J3JvdXRlcjEnXQ0KICAgICAgICAgICAgICAgPC9sb2NrZWQtbm9k ZT4NCiAgICAgICAgICAgICAgIDxsb2NrZWQtbm9kZSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29t L25zL2ludGVyZmFjZSI+DQogICAgICAgICAgICAgICAgICAgL2ludGVyZmFjZXMvaW50ZXJmYWNl W2lkPSdldGgxJ10NCiAgICAgICAgICAgICAgIDwvbG9ja2VkLW5vZGU+DQogICAgICAgICAgIDwv bmM6ZGF0YT4NCiAgICAgICA8L25jOnJwYy1yZXBseT4NCg0KDQogICBQb3NpdGl2ZSBSZXNwb25z ZToNCg0KICAgSWYgdGhlIGRldmljZSB3YXMgYWJsZSB0byBzYXRpc2Z5IHRoZSByZXF1ZXN0LCBh biA8cnBjLXJlcGx5PiBpcyBzZW50DQogICB3aXRoIGEgPGxvY2staWQ+IGVsZW1lbnQgKGxvY2sg aWRlbnRpZmllcikgaW4gdGhlIDxkYXRhPiBlbGVtZW50LiAgQQ0KICAgbGlzdCBvZiBsb2NrZWQt bm9kZXMgaXMgYWxzbyByZXR1cm5lZC4NCg0KICAgTmVnYXRpdmUgUmVzcG9uc2U6DQoNCiAgIElm IGEgbG9jayBpcyBhbHJlYWR5IGhlbGQgYnkgYW5vdGhlciBzZXNzaW9uIG9uIGFueSBub2RlIHdp dGhpbiB0aGUNCiAgIHN1YnRyZWVzIHRvIGJlIGxvY2tlZCwgdGhlIDxlcnJvci10YWc+IGVsZW1l bnQgaXMgJ2xvY2stZGVuaWVkJyBhbmQNCiAgIHRoZSA8ZXJyb3ItaW5mbz4gZWxlbWVudCBpbmNs dWRlcyB0aGUgPHNlc3Npb24taWQ+IG9mIHRoZSBsb2NrIG93bmVyLg0KICAgSWYgdGhlIGxvY2sg aXMgaGVsZCBieSBhIG5vbi1ORVRDT05GIHNlc3Npb24sIGEgPHNlc3Npb24taWQ+IG9mIDANCg0K DQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAg ICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9j ayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAgKHplcm8pIGlz IGluY2x1ZGVkLiAgSWYgbmVlZGVkIHRoZSByZXR1cm5lZCBzZXNzaW9uLWlkIG1heSBiZSB1c2Vk IHRvDQogICA8a2lsbD4gdGhlIE5FVENPTkYgc2Vzc2lvbiBob2xkaW5nIHRoZSBsb2NrLiAgVGhl IHNhbWUgZXJyb3IgcmVzcG9uc2UNCiAgIGlzIHJldHVybmVkIGlmIHRoZSByZXF1ZXN0aW5nIHNl c3Npb24gYWxyZWFkeSBob2xkcyB0aGUgKGdsb2JhbCkgbG9jaw0KICAgZm9yIHRoZSBzYW1lIGRh dGFzdG9yZS4NCg0KICAgSWYgdGhlIHNlbGVjdCBleHByZXNzaW9ucyByZXR1cm4gYW4gZW1wdHkg bm9kZSBzZXQsIHRoZSA8ZXJyb3ItdGFnPg0KICAgaXMgJ29wZXJhdGlvbi1mYWlsZWQnLCBhbmQg dGhlIDxlcnJvci1hcHAtdGFnPiBpcyAnbm8tbWF0Y2hlcycuDQoNCiAgIElmIGFueSBzZWxlY3Qg ZXhwcmVzc2lvbiByZXR1cm5zIGFueXRoaW5nIGJ1dCBhIG5vZGUgc2V0LCB0aGUgPGVycm9yLQ0K ICAgdGFnPiBpcyAnaW52YWxpZC12YWx1ZScsIHRoZSA8ZXJyb3ItYXBwLXRhZz4gaXMgJ1hQYXRo IGRvZXMgbm90DQogICByZXR1cm4gYSBub2RlIHNldCcuDQoNCiAgIElmIHRoZSA6eHBhdGggY2Fw YWJpbGl0eSBpcyBub3Qgc3VwcG9ydGVkIGFuZCB0aGUgWFBhdGggZXhwcmVzc2lvbiBpcw0KICAg bm90IGFuIEluc3RhbmNlIElkZW50aWZpZXIsIHRoZSA8ZXJyb3ItdGFnPiBpcyAnaW52YWxpZC12 YWx1ZScsIHRoZQ0KICAgPGVycm9yLWFwcC10YWc+IGlzICc6eHBhdGggY2FwYWJpbGl0eSBub3Qg c3VwcG9ydGVkJy4NCg0KICAgSWYgYWNjZXNzIGNvbnRyb2wgZGVuaWVzIHRoZSBwYXJ0aWFsIGxv Y2ssIHRoZSA8ZXJyb3ItdGFnPiBpcw0KICAgJ2FjY2Vzcy1kZW5pZWQnLg0KDQoNCjIuNC4xLjIu ICBSZXNlcnZpbmcgbW9kZWwgc2VjdGlvbnMgZm9yIGZ1dHVyZSB3b3JrDQoNCiAgIFBhcnRpYWwg bG9jayBjYW4gbm90IGJlIHVzZWQgdG8gbG9jayBub24tZXhpc3Rpbmcgbm9kZXMsIGVmZmVjdGl2 ZWx5DQogICByZXNlcnZpbmcgdGhlbSBmb3IgZnV0dXJlIHVzZS4gIFRvIG1ha2Ugc3VyZSB0aGF0 IGEgbm9kZSBjYW5ub3QgYmUNCiAgIGNyZWF0ZWQgYnkgc29tZSBvdGhlciBzZXNzaW9uLCB0aGUg cGFyZW50IG5vZGUgc2hvdWxkIGJlIGxvY2tlZCwgdGhlDQogICB0b3AgbGV2ZWwgbm9kZSBvZiB0 aGUgbmV3IHNlY3Rpb24gY3JlYXRlZCwgYW5kIHRoZW4gbG9ja2VkIHdpdGgNCiAgIGFub3RoZXIg PHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uLiAgQWZ0ZXIgdGhpcyB0aGUgbG9jayBvbiB0aGUgcGFy ZW50DQogICBub2RlIHNob3VsZCBiZSByZW1vdmVkLg0KDQoyLjQuMi4gIDxwYXJ0aWFsLXVubG9j az4NCg0KICAgVGhlIG9wZXJhdGlvbiB1bmxvY2tzIGEgcGFydCBvZiBhIGRhdGFzdG9yZSB0aGF0 IHdhcyBwcmV2aW91c2x5DQogICBsb2NrZWQgdXNpbmcgPHBhcnRpYWwtbG9jaz4gZHVyaW5nIHRo ZSBzYW1lIHNlc3Npb24uDQoNCiAgIFBhcmFtZXRlcnM6DQoNCiAgIGxvY2staWQ6ICBMb2NrIGlk ZW50aWZpZXIgdG8gdW5sb2NrOyB0YWtlbiBmcm9tIGEgcmVwbHkgdG8gYSBwcmV2aW91cw0KICAg ICAgIDxwYXJ0aWFsLWxvY2s+IG9wZXJhdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K TGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQ QyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQogICBFeGFtcGxlOiBVbmxv Y2sgYSBwcmV2aW91c2x5IGNyZWF0ZWQgbG9jaw0KDQoNCiAgIDxuYzpycGMgeG1sbnM6bmM9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCINCiAgICAgICB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazoxLjAiDQogICAgICAgbmM6 bWVzc2FnZS1pZD0iMTM2Ij4NCiAgICAgICA8cGFydGlhbC11bmxvY2s+DQogICAgICAgICAgIDxs b2NrLWlkPjEyNzwvbG9jay1pZD4NCiAgICAgICA8L3BhcnRpYWwtdW5sb2NrPg0KICAgPC9uYzpy cGM+DQoNCiAgIFBvc2l0aXZlIFJlc3BvbnNlOg0KDQogICBJZiB0aGUgZGV2aWNlIHdhcyBhYmxl IHRvIHNhdGlzZnkgdGhlIHJlcXVlc3QsIGFuIDxycGMtcmVwbHk+IGlzIHNlbnQNCiAgIHRoYXQg Y29udGFpbnMgYW4gPG9rPiBlbGVtZW50LiAgQSBwb3NpdGl2ZSByZXNwb25zZSBNVVNUIGJlIHNl bnQgZXZlbg0KICAgaWYgYWxsIG9mIHRoZSBsb2NrZWQgcGFydCBvZiB0aGUgZGF0YXN0b3JlIGhh cyBhbHJlYWR5IGJlZW4gZGVsZXRlZC4NCg0KICAgTmVnYXRpdmUgUmVzcG9uc2U6DQoNCiAgIElm IHRoZSA8bG9jay1pZD4gcGFyYW1ldGVyIGRvZXMgbm90IGlkZW50aWZ5IGEgbG9jayB3aGljaCBp cyBvd25lZCBieQ0KICAgdGhlIHNlc3Npb24sIGFuICdpbnZhbGlkLXZhbHVlJyBlcnJvciBpcyBy ZXR1cm5lZC4NCg0KMi41LiAgTW9kaWZpY2F0aW9ucyB0byBFeGlzdGluZyBPcGVyYXRpb25zDQoN CiAgIEEgZ3JhbnRlZCBwYXJ0aWFsLWxvY2sgd2lsbCBjYXVzZSBhbm90aGVyIG9wZXJhdGlvbiB0 byBmYWlsLCBpZiBpdA0KICAgdHJpZXMgdG8gbW9kaWZ5IHRoZSBsb2NrZWQgYXJlYSBhbmQgaXMg ZXhlY3V0ZWQgaW4gYSBORVRDT05GIHNlc3Npb24NCiAgIG90aGVyIHRoZW4gdGhlIG9uZSB0aGF0 IG93bnMgdGhlIGxvY2suICBBbGwgb3BlcmF0aW9ucyB0aGF0IG1vZGlmeQ0KICAgdGhlIGRhdGFz dG9yZSBhcmUgYWZmZWN0ZWQgaW5jbHVkaW5nOiA8ZWRpdC1jb25maWc+LCA8Y29weS1jb25maWc+ LA0KICAgPGRlbGV0ZS1jb25maWc+LCA8Y29tbWl0PiBhbmQgPGRpc2NhcmQtY2hhbmdlcz4uICBB IGdyYW50ZWQgcGFydGlhbC0NCiAgIGxvY2sgd2lsbCBhbHNvIGNhdXNlIHRoZSAoZ2xvYmFsKSA8 bG9jaz4gb3BlcmF0aW9uIHRvIGZhaWwuICBBbGwgb2YNCiAgIHRoZXNlIG9wZXJhdGlvbnMgYXJl IGFmZmVjdGVkIG9ubHkgaWYgdGhleSBhcmUgZm9yIHRoZSBzYW1lDQogICBkYXRhc3RvcmUuDQoN CjIuNi4gIEludGVyYWN0aW9ucyB3aXRoIE90aGVyIENhcGFiaWxpdGllcw0KDQoyLjYuMS4gIFdy aXRhYmxlLVJ1bm5pbmcgQ2FwYWJpbGl0eQ0KDQogICBQYXJ0aWFsIGxvY2tpbmcgb2YgdGhlIHJ1 bm5pbmcgZGF0YXN0b3JlIGNhbiBvbmx5IGJlIGRvbmUgaWYgdGhlDQogICA6d3JpdGFibGUtcnVu bmluZyBjYXBhYmlsaXR5IGlzIHN1cHBvcnRlZCBieSB0aGUgZGV2aWNlLg0KDQoyLjYuMi4gIENh bmRpZGF0ZSBDb25maWd1cmF0aW9uIENhcGFiaWxpdHkNCg0KICAgUGFydGlhbCBsb2NraW5nIG9m IHRoZSBjYW5kaWRhdGUgZGF0YXN0b3JlIGNhbiBvbmx5IGJlIGRvbmUgaWYgdGhlDQogICA6Y2Fu ZGlkYXRlIGNhcGFiaWxpdHkgaXMgc3VwcG9ydGVkIGJ5IHRoZSBkZXZpY2UuICBUaGUgcGFydGlh bA0KICAgbG9ja2luZyBvZiB0aGUgY2FuZGlkYXRlIGRhdGFzdG9yZSBkb2VzIG5vdCBkZXBlbmQg b24gd2hldGhlciB0aGUNCiAgIGRhdGFzdG9yZSB3YXMgbW9kaWZpZWQgb3Igbm90Lg0KDQogICBJ ZiBwYXJ0aWFsIGxvY2sgaXMgcmVxdWVzdGVkIGZvciB0aGUgcnVubmluZyBkYXRhc3RvcmUsIGFu ZCB0aGUNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAy MDA5ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBh cnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAg TkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50cyB0aGUgOmNvbmZpcm1lZC1jb21taXQgY2FwYWJpbGl0 eSwgYW5kIHRoZXJlDQogICB3YXMgYSByZWNlbnQgY29uZmlybWVkIDxjb21taXQ+IG9wZXJhdGlv biwgd2hlcmUgdGhlIGNvbmZpcm1pbmcNCiAgIDxjb21taXQ+IG9wZXJhdGlvbiBoYXMgbm90IGJl ZW4gcmVjZWl2ZWQsIGluIHRoaXMgY2FzZSB0aGUgbG9jayBNVVNUDQogICBiZSBkZW5pZWQsIGJl Y2F1c2UgaWYgdGhlIGNvbmZpcm1hdGlvbiBkb2VzIG5vdCBhcnJpdmUsIHRoZSBydW5uaW5nDQog ICBkYXRhc3RvcmUgTVVTVCBiZSByb2xsZWQgYmFjayB0byBpdHMgc3RhdGUgYmVmb3JlIHRoZSBj b21taXQsIHRodXMNCiAgIHRoZSBORVRDT05GIHNlcnZlciBtaWdodCBuZWVkIHRvIG1vZGlmeSB0 aGUgY29uZmlndXJhdGlvbi4NCg0KMi42LjMuICBEaXN0aW5jdCBTdGFydHVwIENhcGFiaWxpdHkN Cg0KICAgUGFydGlhbCBsb2NraW5nIG9mIHRoZSBzdGFydHVwIGRhdGFzdG9yZSBjYW4gb25seSBi ZSBkb25lIGlmIHRoZQ0KICAgOnN0YXJ0dXAgY2FwYWJpbGl0eSBpcyBzdXBwb3J0ZWQgYnkgdGhl IGRldmljZS4NCg0KDQozLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIHNhbWUg Y29uc2lkZXJhdGlvbnMgYXMgZm9yIHRoZSBiYXNlIE5FVENPTkYgUHJvdG9jb2wgW05FVENPTkZd DQogICBhcmUgdmFsaWQuICBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIDxwYXJ0aWFsLWxvY2s+IGFu ZCA8cGFydGlhbC0NCiAgIHVubG9jaz4gUlBDcyBhcmUgb25seSBhbGxvd2VkIGZvciBhbiBhdXRo ZW50aWNhdGVkIHVzZXIgYWZ0ZXIgcGFzc2luZw0KICAgc29tZSBhY2Nlc3MgY29udHJvbCBtZWNo YW5pc20uDQoNCiAgIEEgbG9jayAoYSBwYXJ0aWFsLWxvY2sgb3IgYSBnbG9iYWwgbG9jaykgbWln aHQgcHJldmVudCBvdGhlciB1c2Vycw0KICAgZnJvbSBjb25maWd1cmluZyB0aGUgc3lzdGVtLiAg VGhlIGZvbGxvd2luZyBtZWNoYW5pc21zIGFyZSBpbiBwbGFjZQ0KICAgdG8gcHJldmVudCB0aGUg bWlzdXNlIG9mIHRoaXMgcG9zc2liaWxpdHk6DQoNCiAgICAgIE9ubHkgYW4gYXV0aGVudGljYXRl ZCB1c2VyIGFmdGVyIHBhc3NpbmcgYWNjZXNzIGNvbnRyb2wgY2FuDQogICAgICByZXF1ZXN0IGEg cGFydGlhbC1sb2NrLg0KDQogICAgICBUaGUgcGFydGlhbC1sb2NrIGlzIGF1dG9tYXRpY2FsbHkg cmVsZWFzZWQgd2hlbiBhIHNlc3Npb24gaXMNCiAgICAgIHRlcm1pbmF0ZWQgaXJyZXNwZWN0aXZl IG9mIHRoZSBtYW5uZXIgdGhlIHNlc3Npb24gZW5kcy4NCg0KICAgICAgVGhlIDxraWxsLXNlc3Np b24+IG9wZXJhdGlvbiBhbGxvd3MgdGVybWluYXRpbmcgb3RoZXIgdXNlcnMNCiAgICAgIHNlc3Np b25zLg0KDQogICAgICBUaGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IGxvZyBwYXJ0aWFsLWxvY2sgcmVx dWVzdHMgaW4gYW4gYXVkaXQNCiAgICAgIHRyYWlsLg0KDQoNCg0KICAgQSBsb2NrIHRoYXQgaXMg aGFuZ2luZyBmb3IgYW55IHJlYXNvbiwgZS5nLiBhIGJyb2tlbiBUQ1AgY29ubmVjdGlvbg0KICAg dGhhdCB0aGUgc2VydmVyIGhhcyBub3QgeWV0IHJlY29nbmlzZWQsIGNhbiBiZSByZWxlYXNlZCBm cm9tIGFub3RoZXINCiAgIE5FVENPTkYgc2Vzc2lvbiBieSBleHBsaWNpdGx5IGtpbGxpbmcgdGhl IHNlc3Npb24gb3duaW5nIHRoYXQgbG9jaw0KICAgdXNpbmcgdGhlIDxraWxsPiBvcGVyYXRpb24u DQoNCiAgIFBhcnRpYWwgbG9ja2luZyBpcyBOT1QgYW4gYXV0aG9yaXphdGlvbiBtZWNoYW5pc20s IGl0IHNob3VsZCBub3QgYmUNCiAgIHVzZWQgdG8gcHJvdmlkZSBzZWN1cml0eSBvciBhY2Nlc3Mg Y29udHJvbC4gIFBhcnRpYWwgbG9ja2luZyBzaG91bGQNCiAgIG9ubHkgYmUgdXNlZCBhcyBhIG1l Y2hhbmlzbSB0byBwcm92aWRlIGNvbnNpc3RlbmN5IGluIGNhc2Ugb2YNCiAgIG11bHRpcGxlIG1h bmFnZXJzIHRyeWluZyB0byBjb25maWd1cmUgdGhlIG5vZGUuICBJdCBpcyB2aXRhbCB0aGF0IHRo ZQ0KICAgb3BlcmF0b3IgY2FuIGVhc2lseSB1bmRlcnN0YW5kIHRoZSBleGFjdCBzY29wZSBvZiBh IGxvY2ssIGZvciB0aGlzDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBN YXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAw OA0KDQoNCiAgIHJlYXNvbiB0aGUgc2NvcGUgaXMgZGV0ZXJtaW5lZCB3aGVuIGdyYW50aW5nIGEg bG9jayBhbmQgaXMgbm90DQogICBtb2RpZmllZCBkeW5hbWljYWxseSBsYXRlci4NCg0KDQo0LiAg SUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0d28gVVJJ cyBmb3IgdGhlIE5FVENPTkYgWE1MIG5hbWVzcGFjZSBpbiB0aGUNCiAgIElFVEYgWE1MIHJlZ2lz dHJ5IFtSRkMzNjg4XS4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSBVUk4gaXMNCiAgIGNvbXBs aWFudCB0byBbTkVUQ09ORl0gc2VjdGlvbiAxMC4zLg0KDQogICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwg SW5kZXggICAgICAgICB8IENhcGFiaWxpdHkgSWRlbnRpZmllciAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IDpwYXJ0aWFsLWxvY2sgfCB1cm46aWV0 ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5OnBhcnRpYWwtbG9jazoxIHwNCiAgIHwgICAgICAg ICAgICAgICB8IC4wICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOnBhcnRpYWwtbG9jazoxLjANCg0KICAgUmVnaXN0cmFudCBDb250YWN0OiBUaGUgSUVT Ry4NCg0KICAgWE1MOiBOL0EsIHRoZSByZXF1ZXN0ZWQgVVJJIGlzIGFuIFhNTCBuYW1lc3BhY2Uu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAg ICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2Nr IFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo1LiAgQXBwZW5kaXgg QSAgLSAgWE1MIFNjaGVtYSBmb3IgUGFydGlhbCBMb2NraW5nICAobm9ybWF0aXZlKQ0KDQogICBU aGUgZm9sbG93aW5nIFhNTCBTY2hlbWEgZGVmaW5lcyB0aGUgPHBhcnRpYWwtbG9jaz4gYW5kIDxw YXJ0aWFsLQ0KICAgdW5sb2NrPiBvcGVyYXRpb25zOg0KDQogPD94bWwgdmVyc2lvbj0iMS4wIiBl bmNvZGluZz0iVVRGLTgiPz4NCiA8eHM6c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAxL1hNTFNjaGVtYSINCiAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6cGFydGlhbC1sb2NrOjEuMCINCiAgIHhtbG5zOm5jPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAiDQogICB0YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpwYXJ0aWFsLWxvY2s6MS4wIg0KICAgZWxlbWVudEZvcm1EZWZhdWx0PSJx dWFsaWZpZWQiIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+DQoNCiAgIDx4czph bm5vdGF0aW9uPg0KICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgIFNjaGVtYSBkZWZp bmluZyB0aGUgcGFydGlhbC1sb2NrIGFuZCB1bmxvY2sgb3BlcmF0aW9ucy4NCiAgICAgICAgIG9y Z2FuaXphdGlvbiAiSUVURiBORVRDT05GIFdvcmtpbmcgR3JvdXAiDQogICAgICAgICBjb250YWN0 DQogICAgICAgICAgICAgIkJhbGF6cyBMZW5neWVsDQogICAgICAgICAgICAgIEVyaWNzc29uIEh1 bmdhcnksIEluYy4NCiAgICAgICAgICAgICAgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIg0K ICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgPC94czphbm5vdGF0aW9uPg0KDQogICA8eHM6 aW1wb3J0IG5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4w Ig0KICAgICBzY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLz4NCg0KICAgPHhzOmNvbXBsZXhU eXBlIG5hbWU9InBhcnRpYWxMb2NrVHlwZSI+DQogICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAg IDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAgICAgQSBORVRDT05GIG9wZXJhdGlvbiB0aGF0IGxv Y2tzIHBhcnQgb2YgYSBkYXRhc3RvcmUuDQogICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAg ICA8L3hzOmFubm90YXRpb24+DQogICAgIDx4czpjb21wbGV4Q29udGVudD4NCiAgICAgICA8eHM6 ZXh0ZW5zaW9uIGJhc2U9Im5jOnJwY09wZXJhdGlvblR5cGUiPg0KICAgICAgICAgPHhzOnNlcXVl bmNlPg0KICAgICAgICAgICA8eHM6ZWxlbWVudCByZWY9Im5jOnJwY09wZXJhdGlvblRhcmdldFR5 cGUiLz4NCiAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ic2VsZWN0IiB0eXBlPSJ4czpzdHJp bmciDQogICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPg0KICAgICAgICAgICAgIDx4 czphbm5vdGF0aW9uPg0KICAgICAgICAgICAgICAgPHhzOmRvY3VtZW50YXRpb24+DQogICAgICAg ICAgICAgICAgIFhQYXRoIGV4cHJlc3Npb24gdGhhdCBzcGVjaWZpZXMgdGhlIHNjb3BlIG9mIHRo ZSBsb2NrLg0KICAgICAgICAgICAgICAgICBBbiBJbnN0YW5jZSBJZGVudGlmaWVyIGV4cHJlc3Np b24gbXVzdCBiZSB1c2VkIHVubGVzcw0KICAgICAgICAgICAgICAgICB0aGUgOnhwYXRoIGNhcGFi aWxpdHkgaXMgc3VwcG9ydGVkIGluIHdoaWNoIGNhc2UgYW55DQogICAgICAgICAgICAgICAgIFhQ YXRoIDEuMCBleHByZXNzaW9uIGlzIGFsbG93ZWQuDQogICAgICAgICAgICAgICA8L3hzOmRvY3Vt ZW50YXRpb24+DQogICAgICAgICAgICAgPC94czphbm5vdGF0aW9uPg0KICAgICAgICAgICA8L3hz OmVsZW1lbnQ+DQogICAgICAgICA8L3hzOnNlcXVlbmNlPg0KDQoNCg0KTGVuZ3llbCAmIEJqb3Jr bHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMTJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAg ICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQogICAgICAgPC94czpleHRlbnNpb24+DQogICAgIDwv eHM6Y29tcGxleENvbnRlbnQ+DQogICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogICA8eHM6Y29tcGxl eFR5cGUgbmFtZT0icGFydGlhbFVuTG9ja1R5cGUiPg0KICAgICA8eHM6YW5ub3RhdGlvbj4NCiAg ICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgIEEgTkVUQ09ORiBvcGVyYXRpb24gdGhh dCByZWxlYXNlcyBhIHByZXZpb3VzbHkgYWNxdWlyZWQNCiAgICAgICAgIHBhcnRpYWwtbG9jay4N CiAgICAgICA8L3hzOmRvY3VtZW50YXRpb24+DQogICAgIDwveHM6YW5ub3RhdGlvbj4NCiAgICAg PHhzOmNvbXBsZXhDb250ZW50Pg0KICAgICAgIDx4czpleHRlbnNpb24gYmFzZT0ibmM6cnBjT3Bl cmF0aW9uVHlwZSI+DQogICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAgIDx4czplbGVt ZW50IG5hbWU9ImxvY2staWQiIHR5cGU9InhzOnVuc2lnbmVkSW50Ij4NCiAgICAgICAgICAgICA8 eHM6YW5ub3RhdGlvbj4NCiAgICAgICAgICAgICAgIDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAg ICAgICAgICAgICBJZGVudGlmaWVzIHRoZSBsb2NrIHRvIGJlIHJlbGVhc2VkLiBNdXN0IGJlIHRo ZSB2YWx1ZQ0KICAgICAgICAgICAgICAgICByZWNlaXZlZCBpbiB0aGUgcmVzcG9uc2UgdG8gdGhl IHBhcnRpYWwtbG9jayBvcGVyYXRpb24uDQogICAgICAgICAgICAgICA8L3hzOmRvY3VtZW50YXRp b24+DQogICAgICAgICAgICAgPC94czphbm5vdGF0aW9uPg0KICAgICAgICAgICA8L3hzOmVsZW1l bnQ+DQogICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgIDwveHM6ZXh0ZW5zaW9uPg0KICAg ICA8L3hzOmNvbXBsZXhDb250ZW50Pg0KICAgPC94czpjb21wbGV4VHlwZT4NCg0KICAgPCEtLSA8 cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJwYXJ0aWFs LWxvY2siIHR5cGU9InBhcnRpYWxMb2NrVHlwZSINCiAgICAgICAgICAgICAgIHN1YnN0aXR1dGlv bkdyb3VwPSJuYzpycGNPcGVyYXRpb24iLz4NCg0KICAgPCEtLSA8cGFydGlhbC11bmxvY2s+IG9w ZXJhdGlvbiAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9InBhcnRpYWwtdW5sb2NrIiB0eXBlPSJw YXJ0aWFsVW5Mb2NrVHlwZSINCiAgICAgICAgICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuYzpy cGNPcGVyYXRpb24iLz4NCg0KICAgPCEtLSByZXBseSB0byA8cGFydGlhbC1sb2NrPiAtLT4NCiAg IDx4czplbGVtZW50IG5hbWU9ImxvY2staWQiIHR5cGU9InhzOnVuc2lnbmVkSW50Ii8+DQoNCiA8 L3hzOnNjaGVtYT4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQg ICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAg IFNlcHRlbWJlciAyMDA4DQoNCg0KNi4gIEFwcGVuZGl4IEIgIC0gWUFORyBNb2R1bGUgZm9yIFBh cnRpYWwgTG9ja2luZyAobm9uLW5vcm1hdGl2ZSkNCg0KICAgVGhlIGZvbGxvd2luZyBZQU5HIG1v ZHVsZSBkZWZpbmVzIHRoZSA8cGFydGlhbC1sb2NrPiBhbmQgPHBhcnRpYWwtDQogICB1bmxvY2s+ IG9wZXJhdGlvbnMuICBUaGUgWUFORyBsYW5ndWFnZSBpcyBkZWZpbmVkIGluDQogICBbSS1ELmll dGYtbmV0bW9kLXlhbmddLg0KDQogIG1vZHVsZSBuZXRjb25mLXBhcnRpYWwtbG9jayB7DQoNCiAg ICBuYW1lc3BhY2UgdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazox LjA7DQogICAgcHJlZml4IHBsOw0KDQogICAgb3JnYW5pemF0aW9uICJJRVRGIE5FVENPTkYgV29y a2luZyBHcm91cCI7DQoNCiAgICBjb250YWN0DQogICAgICAiQmFsYXpzIExlbmd5ZWwNCiAgICAg ICBFcmljc3NvbiBIdW5nYXJ5LCBJbmMuDQogICAgICAgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24u Y29tIjsNCg0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiVGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVz IHRoZSA8cGFydGlhbC1sb2NrPiBhbmQNCiAgICAgICA8cGFydGlhbC11bmxvY2s+IG9wZXJhdGlv bnMuIjsNCg0KICAgIHJldmlzaW9uIDIwMDgtMDYtMDYgew0KICAgICAgZGVzY3JpcHRpb24gIklu aXRpYWwgdmVyc2lvbi4iOw0KICAgIH0NCg0KICAgIGdyb3VwaW5nIGNvbmZpZ05hbWUgew0KICAg ICAgY29udGFpbmVyIHRhcmdldCB7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgIkEgY2hvaWNlIHRvIGxpc3QgdGhlIGRhdGFzdG9yZSBuYW1lcyBmb3IgTkVUQ09ORi4iOw0K ICAgICAgICAgIGNob2ljZSBjb25maWdOYW1lVHlwZSB7DQogICAgICAgICAgICBsZWFmIHJ1bm5p bmcgICB7IHR5cGUgZW1wdHk7IH0NCiAgICAgICAgICAgIGxlYWYgY2FuZGlkYXRlIHsgdHlwZSBl bXB0eTsgfQ0KICAgICAgICAgICAgbGVhZiBzdGFydHVwICAgeyB0eXBlIGVtcHR5OyB9DQogICAg ICAgICAgfQ0KICAgICAgIH0NCiAgICB9DQoNCiAgICBycGMgcGFydGlhbC1sb2NrIHsNCiAgICAg IGRlc2NyaXB0aW9uICJBIE5FVENPTkYgb3BlcmF0aW9uIHRoYXQgbG9ja3MgcGFydCBvZiBhIGRh dGFzdG9yZS4iOw0KICAgICAgaW5wdXQgew0KICAgICAgICB1c2VzIGNvbmZpZ05hbWU7DQogICAg ICAgIGxlYWYtbGlzdCBzZWxlY3Qgew0KICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAg ICAiWFBhdGggZXhwcmVzc2lvbiB0aGF0IHNwZWNpZmllcyB0aGUgc2NvcGUgb2YgdGhlIGxvY2su DQogICAgICAgICAgICBBbiBJbnN0YW5jZSBJZGVudGlmaWVyIGV4cHJlc3Npb24gbXVzdCBiZSB1 c2VkIHVubGVzcyB0aGUNCiAgICAgICAgICAgIDp4cGF0aCBjYXBhYmlsaXR5IGlzIHN1cHBvcnRl ZCBpbiB3aGljaCBjYXNlIGFueSBYUGF0aCAxLjANCiAgICAgICAgICAgIGV4cHJlc3Npb24gaXMg YWxsb3dlZC4iOw0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2gg MTIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0K DQogICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgbWluLWVsZW1lbnRzIDE7DQogICAg ICAgIH0NCiAgICAgIH0NCiAgICAgIG91dHB1dCB7DQogICAgICAgIGxlYWYgbG9jay1pZCB7DQog ICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBsb2NrLCBp ZiBncmFudGVkLiBUaGUgbG9jay1pZCBtdXN0IGJlDQogICAgICAgICAgICAgdXNlZCBpbiB0aGUg cGFydGlhbC11bmxvY2sgcnBjLiI7DQogICAgICAgICAgdHlwZSB1aW50MzI7DQogICAgICAgIH0N CiAgICAgICAgbGVhZi1saXN0IGxvY2tlZC1ub2RlIHsNCiAgICAgICAgICAgIGRlc2NyaXB0aW9u ICJMaXN0IG9mIGxvY2tlZC1ub2RlcyI7DQogICAgICAgICAgICB0eXBlIGluc3RhbmNlLWlkZW50 aWZpZXI7DQogICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQoNCiAgICBycGMgcGFydGlhbC11bmxv Y2sgew0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIkEgTkVUQ09ORiBvcGVyYXRpb24gdGhh dCByZWxlYXNlcyBhIHByZXZpb3VzbHkgYWNxdWlyZWQNCiAgICAgICAgcGFydGlhbC1sb2NrLiI7 DQogICAgICBpbnB1dCB7DQogICAgICAgIGxlYWYgbG9jay1pZCB7DQogICAgICAgICAgZGVzY3Jp cHRpb24NCiAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBsb2NrIHRvIGJlIHJlbGVhc2VkLiBN dXN0IGJlIHRoZSB2YWx1ZQ0KICAgICAgICAgICAgcmVjZWl2ZWQgaW4gdGhlIHJlc3BvbnNlIHRv IHRoZSBwYXJ0aWFsLWxvY2sgb3BlcmF0aW9uLiI7DQogICAgICAgICAgdHlwZSB1aW50MzI7DQog ICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQogIH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIw MDkgICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFy dGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo3LiAg QXBwZW5kaXggQyAgLSAgQ2hhbmdlIExvZw0KDQo3LjEuICAwMy0wNA0KDQogICBNaW5vciBjbGFy aWZpY2F0aW9ucw0KDQogICBBZGRlZCBsaXN0IG9mIGxvY2tlZC1ub2RlcyB0byB0aGUgb3V0cHV0 IG9mIHBhcnRpYWwtbG9jay4NCg0KICAgQWRkZWQgPHRhcmdldD4gd3JhcHBlciBhcm91bmQgZGF0 YXN0b3JlIG5hbWUuDQoNCjcuMi4gIDAyLTAzDQoNCiAgIE1pbm9yIGNsYXJpZmljYXRpb25zDQoN CiAgIFNhbWUgZGVzY3JpcHRpb25zIGluIFhTRCBhbmQgWUFORy4NCg0KNy4zLiAgMDEtMDINCg0K ICAgTWFkZSBYU0Qgbm9ybWF0aXZlDQoNCiAgIENsYXJpZmllZCB0aGF0IG5vIHNwZWNpZmljIGFj Y2VzcyBjb250cm9sIGlzIGFzc3VtZWQuDQoNCiAgIENsYXJpZmllZCB0aGF0IG5vbi1leGlzdGlu ZyBub2RlcyBhcmUgTk9UIGNvdmVyZWQgYnkgdGhlIGxvY2ssIGV2ZW4NCiAgIGlmIHRoZXkgd2hl cmUgZXhpc3RpbmcgYW5kIGNvdmVyZWQgYnkgdGhlIGxvY2sgd2hlbiBpdCB3YXMgb3JpZ2luYWxs eQ0KICAgZ3JhbnRlZC4NCg0KICAgU29tZSByZXdvcmRpbmcNCg0KICAgQWRkZWQgYXBwLXRhZ3Mg Zm9yIHR3byBvZiB0aGUgZXJyb3IgY2FzZXMuDQoNCiAgIE1hZGUgWUFORyBhbiBpbmZvcm1hdGl2 ZSByZWZlcmVuY2UNCg0KICAgRW5oYW5jZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCjcu NC4gIDAwLTAxDQoNCiAgIEFkZGVkIFlBTkcgbW9kdWxlLg0KDQo3LjUuICAtMDANCg0KICAgQ3Jl YXRlZCBmcm9tIGRyYWZ0LWxlbmd5ZWwtbmdvLXBhcnRpYWwtbG9jay0wMS50eHQNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIw MDkgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFy dGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo4LiAg QWNrbm93bGVkZ2VtZW50cw0KDQogICBUaGFua3MgdG8gQW5keSBCaWVybWFuLCBTaGFyb24gQ2hp c2hvbG0sIFBoaWwgU2hhZmVyICwgRGF2aWQNCiAgIEhhcnJpbmd0b24sIE1laG1ldCBFcnN1ZSBh bmQgbWFueSBvdGhlciBtZW1iZXJzIG9mIHRoZSBORVRDT05GIFdHIGZvcg0KICAgcHJvdmlkaW5n IGltcG9ydGFudCBpbnB1dCB0byB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwg MjAwOSAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQ YXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCjku ICBSZWZlcmVuY2VzDQoNCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtORVRDT05G XSAgRW5ucywgUi4sICJORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wiLCBSRkMgNDc0MSwN CiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNi4NCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAg W1JGQzM2ODhdICBNZWFsbGluZywgTS4sICJUaGUgSUVURiBYTUwgUmVnaXN0cnkiLCBCQ1AgODEs IFJGQyAzNjg4LA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQuDQoNCjkuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW0ktRC5pZXRmLW5ldG1vZC15YW5nXQ0KICAgICAgICAgICAg ICBCam9ya2x1bmQsIE0uLCAiWUFORyAtIEEgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBmb3INCiAg ICAgICAgICAgICAgTkVUQ09ORiIsIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctMDAgKHdvcmsgaW4g cHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBNYXkgMjAwOC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpv cmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAx OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05G ICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBCYWxh enMgTGVuZ3llbA0KICAgRXJpY3Nzb24gSHVuZ2FyeQ0KDQogICBFbWFpbDogYmFsYXpzLmxlbmd5 ZWxAZXJpY3Nzb24uY29tDQoNCg0KICAgTWFydGluIEJqb3JrbHVuZA0KICAgVGFpbC1mIFN5c3Rl bXMNCg0KICAgRW1haWw6IG1iakB0YWlsLWYuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5n eWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAg ICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZv ciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRl bWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmlj dGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRo ZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhp cyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3Zp ZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdB TklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0KICAgVEhFIElOVEVS TkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MNCiAgIE9SIElNUEFrom netconf-bounces@ietf.org Tue Sep 9 04:36:28 2008 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 3EBD53A6C7C; Tue, 9 Sep 2008 04:36:28 -0700 (PDT) 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 010703A6C7C for ; Tue, 9 Sep 2008 04:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=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 VADQ8-ppnrW7 for ; Tue, 9 Sep 2008 04:36:23 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 3613D3A6ACF for ; Tue, 9 Sep 2008 04:36:22 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m89BaMKD003142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 13:36:22 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m89BaLUu024679; Tue, 9 Sep 2008 13:36:22 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 13:36:20 +0200 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_01C91270.4668D332" Date: Tue, 9 Sep 2008 13:36:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Netconf] evaluation of the partial-lock document Thread-Index: AckRxDgJq1qey0RQRgK3qVR046esUQAq7ANQ From: "Ersue, Mehmet (NSN - DE/Munich)" To: , "ext Bert Wijnen (IETF)" X-OriginalArrivalTime: 09 Sep 2008 11:36:20.0207 (UTC) FILETIME=[478167F0:01C91270] Cc: netconf@ietf.org Subject: [Netconf] FW: evaluation of the partial-lock document 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_01C91270.4668D332 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Balazs, All, the Partial Lock schema in the attached draft seems=20 to be valid with one exception. rpcOperationTargetType is defined as a complex type=20 in netconf.xsd, but the PL schema is using it as an=20 element in rpcOperationType. Hence the XML validation gives an error message that=20 it must refer to an existing _element_ (i.e. not compex type). Cheers,=20 Mehmet=20 -----Original Message----- From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of ext Balazs Lengyel Sent: Monday, September 08, 2008 5:04 PM To: Wes Hardaker; Bert Wijnen - IETF; netconf mailing list Subject: Re: [Netconf] evaluation of the partial-lock document Hello Wes, Bert, Thanks for the review. PleasexJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJB TlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJ TkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRl bGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJk aW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5k ZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAg b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRz IGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJ UFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBh c3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGlt cGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRh aW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRz IG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMg dGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8g dGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdtZW50DQoN CiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRo ZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4NCg0KDQoN Cg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAg ICAgICAgICAgICBbUGFnZSAyMF0NCgwNCg0K ------_=_NextPart_001_01C91270.4668D332 Content-Type: text/plain; name="ATT5860428.txt" Content-Transfer-Encoding: base64 Content-Description: ATT5860428.txt Content-Disposition: attachment; filename="ATT5860428.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== ------_=_NextPart_001_01C91270.4668D332 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_01C91270.4668D332-- see the answers for Wes below! If you have a look of the attached version, you can see that I also included Bert's comments. I=20 basically accepted them all e.g. I added a list of locked-nodes to the rpc-reply. Please indicate if you still have problems with some of the issues. Balazs Wes Hardaker wrote: > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... >=20 >=20 > Netconf WG last call report on partial lock > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Author: Wes Hardaker > Date: 2008-08-26 16:50:09 PDT >=20 > Table of Contents > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 1 General Notes > 2 Thoughts on: Partial locks don't cover non-existing nodes > 3 section 2.1: "Note:" wording > 4 section 2.1, starting with "As with most locking..." > 5 Question about multiple locks from the same session... > 6 Section 2.4.1.1: target: > 7 Section 2.4.1.1: text change > 8 Section 2.4.1.1: first example > 9 Side thought: netconf documents all assume a particular data model > 10 Section 2.4.1.1: 2nd to last paragraph: > 11 Section 2.4.2: > 12 Section 2.4.2, negative response: > 13 Section 2.5 > 14 Section 3, second paragraph: first sentence needs ()s or commas > 15 Comparison of xpath evaluated partial lock vs locked nodes >=20 >=20 >=20 > 1 General Notes > --------------- > * Document is very well layed out and easy to understand. > It flows well and is easy to read. > * But... The English grammar could use some polishing in a few > more places than I've listed here. > + I'd recommend the authors hand it to someone that hasn't > been involved in editing for a simple polishing pass. [BALAZS]: Will try. > * My final thoughts and concerns on the partial-lock feature as > a whole are in the last section of this... >=20 > 2 Thoughts on: Partial locks don't cover non-existing nodes > ----------------------------------------------------------- > * (Section 2.4.1-ish) > * note: can't lock a tree part that doesn't exist yet > * There exists odd an usage case when a tree doesn't yet exist > (empty configuration). E.G., I can't lock the users tree until > at least 1 users/user exists. If I try to lock when > no subelement exists then I believe I get an error back (I'm > not even positive about this). Section 2.4.1 seems to > indicate that it'll fail since at least one of the select sets > MUST be non-empty. > + The result is that you *must* create a single before > you can lock the table, for example. IE a manager > is expected to be able to perform and understand why it's > doing the following odd sequence: > - partial-lock =3D> failure because it's empty. > - create a joe > - partial-lock =3D> success > - Edit users > - unlock > + This is just an odd error handling case that manegers will > have to cope with and it only exists because of the > inability to lock an empty tree. > * Section 2.4.1.2 discusses this aspect of partial-locking, but > the security implications may be that you don't have > permission to lock a parent node of for exmaple. IE, > You shouldn't have to take out lock on just because you > want to lock (and you shouldn't have to create a user > before you can lock the table). [BALAZS]: I am not sure I fully understand your comment, but here is what I think is the answer (in YANG to makes think simpler :-) If you have a data model: container USERS { list user { ... } } Here you CAN lock the container USERS even if there are no user nodes below it. The select will return the USERS node, so it will not be empty. In this case no one else can touch any of the user nodes or create a new user. >=20 > 3 section 2.1: "Note:" wording > ------------------------------ > * First sentence isn't a complete sentence > * I'd argue this isn't just a "Note" but an interaction with > another capability and probably should be spelled out more > importantly than just as a "Note:" that implies it's just > additional information. [BALAZS]: OK, moved it to 2.6.2 Interactions with Other Capabilities / Candidate Configuration Capability >=20 > 4 section 2.1, starting with "As with most locking..." > ------------------------------------------------------ > * Change: > * "parts of the configuration become dead-locked" =3D> > * "parts of the configuration *could* become dead-locked" [BALAZS]: OK >=20 > 5 Question about multiple locks from the same session... > -------------------------------------------------------- > * Is it allowed? Doesn't say one way or another...=20 > * Consider: > 1. lock with one partial nodes A and B > 2. and then with another try to lock B and C > 3. Do I get an error because B is locked (by me in this session)? > 4. or now do I have multiple locks covering A, B and C? > * I *think* I get an error? > * If I do have A, B and C locked: > + and then I release the lock > + do I still have B and C locked with the second or just C > (I'd assume B and C)? > * The document discusses this ramification for but not > really well for > * It sort of implies an error further in 2.4.1.1 "If a lock is > already held on any node..." [BALAZS]: It is allowed to have multiple locks from the same session. In 2.4.1.1 will be reworded to indicate this. In 2.1 it is stated that: "A NETCONF session MAY have multiple parts of one or more datastores (running, candidate,startup) locked using partial lock operations. The operation returns a lock-id to identify each successfully acquired lock." Indicating that a session might have multiple locks. I will also add to 2.4.1: A NETCONF server MUST be able to grant multiple simultaneous partial locks to a single NETCONF session. If the scope of the individual locks overlap, nodes in the common area MUST be locked until all of the locks are released. >=20 > 6 Section 2.4.1.1: target: > -------------------------- > * Wouldn't it be best to state directly: "a may > only have one parameter?" [BALAZS]: OK >=20 > 7 Section 2.4.1.1: text change > ------------------------------ > * "If the device supports the :xpath capability as well any valid" = =3D> > * "If the device supports the :xpath capability *then* any valid" [BALAZS]: OK >=20 > 8 Section 2.4.1.1: first example > -------------------------------- > * Shouldn't be within a scope? > * The schema seems to indicate no > * But it should (IMHO) if nothing else to match usage > which does have a parameter. > + (if memory serves this was discussed early on in netconf and > it was agreed that all targets should be directly specified > inside a named or similar parameter tag) [BALAZS]: OK >=20 > 9 Side thought: netconf documents all assume a particular data model > -------------------------------------------------------------------- > * Is it just me, or should all the netconf documents be replaced > once a real data model exists with real example nodes to use? > * Right now all the examples give the impression that the example > RPCs will work, when in actuality they won't match the real > world data models. > + EG: /interfaces/interface[Id=3D'eth1'] [BALAZS]: This is just an example no more. IMHO we simply can not avoid assuming some data model for now. I agree, it would be nice to later include real examples from standard modules; whether we will have the time for that? >=20 > 10 Section 2.4.1.1: 2nd to last paragraph: > ------------------------------------------ > * Explicitly spelling out an xpath failure is nice to > understand. But in reality this should be more generic in > order to handle failing on future select type expressions > (xpath2) or other syntax errors. Maybe something like "search > expression type not supported"? [BALAZS]: I would like to be explicit here. If we introduce Xpath2 later we will anyway have to update the RFC, and I don't see how that update would cause problems for a management system. Once it gets the error it will anyway know it failed. > + What type of error do I get back for /users/user[name=3D'Joe [BALAZS]: Tag: invalid-value >=20 > 11 Section 2.4.2: > ----------------- > * Nit: Replace "Example: Unlock" with "Example: Unlock a > previously created lock" > + or just remove: "Unlock" > + The title just looks a touch odd as is (incomplete). [BALAZS]: OK >=20 > 12 Section 2.4.2, negative response: > ------------------------------------ > * So there is no way to break a lock from a different session? > Then what happens if a TCP connection drops according to the > client (or is forced to drop) but the server hasn't realized > it's closed? > + Looks like kill-session is the solution based on later reading, > but I'd suggest spelling it out here. > + Requires access to the kill-session command to release a > hung-lock. Possibly worth mentioning in the security > expectations. [BALAZS}: OK >=20 > 13 Section 2.5 > -------------- > * I'd spell out in no uncertain terms that any command that > modifies a datastore will be blocked, and that "includes" the > current list. The wording as is could be easily > misinterpreted to read that the current list is all you need > to worry about (which I know wasn't the intent). [BALAZS}: OK >=20 > 14 Section 3, second paragraph: first sentence needs ()s or commas > ------------------------------------------------------------------ > around the lock types. [BALAZS}: OK >=20 > 15 Comparison of xpath evaluated partial lock vs locked nodes > ------------------------------------------------------------- > * I'm not personally convienced still that locking existing > nodes only is the best solution for partial locking. I know > it's been debated a bunch in the past but I'm not even > convienced there is consusus on the subject. I suspect that > if you counted the number of folks that started an argument > about it the numbers wouldn't point clearly to a consensus. > Many of the arguments came at different times, which makes it > hard to count. > + That being said, letting this one go forward doesn't > prohibit a different later solution. [BALAZS}: IMHO we did reach consensus on the issue, but anyway I am glad to see that you can still live with this solution. > + I'm not convienced that locking nodes is cheaper to > implement or execute than evaluating edits based on a > memorized xpath solution. > * Comparison: > * XPATH eval: > + easier to list in a "list of outstanding locks" table > + storage cost is very small (a list of xpaths) > + CPU usage is higher (An eval on every command is required) > + I think it's more intuitive... There isn't an unknown "it's > no longer locked because you deleted it" sudden surprise. > * locking a list of nodes with a eval-once: > + Lower CPU usage since it's a single xpath eval > - Higher memory cost (need to memorize every locked node > either through a list or a flag) > - Usage complexity is much higher > - Can't lock empty parent nodes > - security ramifications require parent nodes for *everything* > - deleted nodes can be recreated > * This is most critical when manipulating ordered lists of > things like access rules (eg, firewall rules) > * I've seen real-world current discussions surrounding the need > to put in a parent tree for all nodes *just* because of the > partial-lock inability to lock a common set of nodes. The > result of this type of partical lock means either: > + data models will add extra tree nodes everywhere > + Or they wont' and it'll turn out later they should have > because of opreational needs for locking all the subnodes > and it can't be done. > - IE, it becomes critical to create a node to > surround a list of firewall nodes. > + I think it's worth spelling out this issue in the security > considerations so that every data model ever created gets a > otherwise-empty top node added above it so that it can be locked. [BALAZS}: In my eyes the deciding factor is avoiding surprises. XPATH surprise 1: I have a user: John OConnor. I lock him based on his name. Later I correct his name to John O'Connor. Whoops suddenly he is not locked. (The name might not even be the key attribute/leaf). XPATH surprise 2: We use XPATH: and "preceding-sibling::*". I modify some data in my locked nodes. The order of the nodes might be modified by the modifying their content in the datastore (e.g. modifying a leaf called "priority"). Due to the change in priority some nodes that were previously locked suddenly become unlocked. XPATH surprise 3: I know I have 3 users: Jack and Jill and John. I store my users in alphabetical order. I want to lock John so I use from XPATH: "position() =3D 3" Now another = operator comes and adds user Blaise. Suddenly I am locking Jill instead of John. XPATH surprise 4: Using an XPATH that includes state data or any configuration data that is not itself locked is just asking for disaster. Probably a many more strange XPATH expressions could be designed. regards Balazs ------_=_NextPart_001_01C91270.4668D332 Content-Type: text/plain; name="draft-ietf-netconf-partial-lock-04.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-netconf-partial-lock-04.txt Content-Disposition: inline; filename="draft-ietf-netconf-partial-lock-04.txt" DQoNCg0KTkVUQ09ORiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBCLiBMZW5neWVsDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkNCkludGVuZGVkIHN0YXR1czog U3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgIE0uIEJqb3JrbHVuZA0K RXhwaXJlczogTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFRhaWwtZiBTeXN0ZW1zDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTZXB0ZW1iZXIgMDgsIDIwMDgNCg0KDQogICAgICAgICAgICAgICAgICAg ICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORg0KICAgICAgICAgICAgICAgICAgIGRyYWZ0 LWlldGYtbmV0Y29uZi1wYXJ0aWFsLWxvY2stMDQNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQog ICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2Vu dHMgdGhhdCBhbnkNCiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Yg d2hpY2ggaGUgb3Igc2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9z ZWQsIGFuZCBhbnkgb2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUg ZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAg SW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5n aW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRl IHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5l dC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBt b250aHMNCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv dGhlciBkb2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1 c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0 aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBj dXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJu ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxs IGV4cGlyZSBvbiBNYXJjaCAxMiwgMjAwOS4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICBDb3B5 cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4NCg0KQWJzdHJhY3QNCg0KICAgVGhlIE5F VENPTkYgcHJvdG9jb2wgZGVmaW5lcyB0aGUgbG9jayBhbmQgdW5sb2NrIFJQQ3MgdGhhdCBsb2Nr DQogICBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiAgSW4gc29tZSBzaXR1YXRpb25z LCBhIHdheSB0byBsb2NrDQogICBvbmx5IHBhcnRzIG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmUgaXMgcmVxdWlyZWQuICBUaGlzIGRvY3VtZW50DQogICBkZWZpbmVzIGEgY2FwYWJpbGl0eS1i YXNlZCBleHRlbnNpb24gdG8gdGhlIE5FVENPTkYgcHJvdG9jb2wgZm9yDQogICBsb2NraW5nIHBv cnRpb25zIG9mIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUuDQoNCg0KDQoNCg0KTGVuZ3llbCAm IEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgIFtQ YWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVU Q09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQpUYWJsZSBvZiBDb250ZW50cw0KDQogICAx LiAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDMNCiAgICAgMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFBhcnRpYWwgTG9ja2luZyBDYXBh YmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDIuMS4g IE92ZXJ2aWV3IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgICAgMi4yLiAgRGVwZW5kZW5jaWVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgICAyLjMuICBDYXBhYmlsaXR5IElkZW50aWZpZXIg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAgIDIuNC4gIE5ldyBP cGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQN CiAgICAgICAyLjQuMS4gIDxwYXJ0aWFsLWxvY2s+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNA0KICAgICAgIDIuNC4yLiAgPHBhcnRpYWwtdW5sb2NrPiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDIuNS4gIE1vZGlmaWNhdGlv bnMgdG8gRXhpc3RpbmcgT3BlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAg Mi42LiAgSW50ZXJhY3Rpb25zIHdpdGggT3RoZXIgQ2FwYWJpbGl0aWVzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgOQ0KICAgICAgIDIuNi4xLiAgV3JpdGFibGUtUnVubmluZyBDYXBhYmlsaXR5ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgICAgMi42LjIuICBDYW5kaWRhdGUgQ29u ZmlndXJhdGlvbiBDYXBhYmlsaXR5IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgICAyLjYu My4gIERpc3RpbmN0IFN0YXJ0dXAgQ2FwYWJpbGl0eSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAxMA0KICAgMy4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICA0LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgIDUuICBBcHBlbmRpeCBB ICAtICBYTUwgU2NoZW1hIGZvciBQYXJ0aWFsIExvY2tpbmcgIChub3JtYXRpdmUpIC4gLiAxMg0K ICAgNi4gIEFwcGVuZGl4IEIgIC0gWUFORyBNb2R1bGUgZm9yIFBhcnRpYWwgTG9ja2luZw0KICAg ICAgIChub24tbm9ybWF0aXZlKSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE0DQogICA3LiAgQXBwZW5kaXggQyAgLSAgQ2hhbmdlIExvZyAgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNy4xLiAgMDMtMDQgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICA3LjIu ICAwMi0wMyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDE2DQogICAgIDcuMy4gIDAxLTAyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCiAgICAgNy40LiAgMDAtMDEgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgICA3LjUuICAtMDAg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE2 DQogICA4LiAgQWNrbm93bGVkZ2VtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMTcNCiAgIDkuICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgICA5LjEuICBOb3JtYXRpdmUg UmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE4DQogICAg IDkuMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTgNCiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0KICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IGFu ZCBDb3B5cmlnaHQgU3RhdGVtZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJl cyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIg MjAwOA0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhlIE5FVENPTkYgcHJvdG9jb2wgW05F VENPTkZdIGRlc2NyaWJlcyB0aGUgbG9jayBhbmQgdW5sb2NrIFJQQ3MNCiAgIHRoYXQgb3BlcmF0 ZSBvbiBlbnRpcmUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLiAgT2Z0ZW4sIG11bHRpcGxlDQog ICBtYW5hZ2VtZW50IHNlc3Npb25zIG5lZWQgdG8gYmUgYWJsZSB0byBtb2RpZnkgdGhlIGNvbmZp Z3VyYXRpb24gb2YgYQ0KICAgbWFuYWdlZCBkZXZpY2UgaW4gcGFyYWxsZWwuICBJbiB0aGVzZSBj YXNlcywgbG9ja2luZyBvbmx5IHBhcnRzIG9mIGENCiAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl IGlzIG5lZWRlZC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhbg0KICAgZXh0ZW5zaW9uIHRvIHRo ZSBORVRDT05GIHByb3RvY29sIHRvIGFsbG93IHRoaXMuDQoNCiAgIFRoZSBtZWNoYW5pc20gZm9y IHBhcnRpYWwgbG9ja2luZyBpcyBiYXNlZCBvbiB0aGUgZXhpc3RpbmcgWFBhdGgNCiAgIGZpbHRl cmluZyBtZWNoYW5pc21zLg0KDQogICBQYXJ0aWFsIGxvY2tpbmcgaXMgZGVmaW5lZCBhcyBhIGNh cGFiaWxpdHkgdG8gTkVUQ09ORi4NCg0KMS4xLiAgRGVmaW5pdGlvbiBvZiBUZXJtcw0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9U IFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZA0KICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gQkNQDQogICAxNCwgW1JGQzIx MTldLg0KDQoNCjIuICBQYXJ0aWFsIExvY2tpbmcgQ2FwYWJpbGl0eQ0KDQoyLjEuICBPdmVydmll dw0KDQogICBUaGUgOnBhcnRpYWwtbG9jayBjYXBhYmlsaXR5IGluZGljYXRlcyB0aGF0IHRoZSBk ZXZpY2Ugc3VwcG9ydHMgdGhlDQogICBsb2NraW5nIG9mIGl0cyBjb25maWd1cmF0aW9uIHdpdGgg YSBzY29wZSBzbWFsbGVyIHRoZW4gYSBjb21wbGV0ZQ0KICAgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmUuICBUaGUgc2NvcGUgdG8gYmUgbG9ja2VkIGlzIHNwZWNpZmllZCBieQ0KICAgdXNpbmcgcmVz dHJpY3RlZCBvciBmdWxsIFhQYXRoIGV4cHJlc3Npb25zLiAgUGFydGlhbCBsb2NraW5nIGNvdmVy cw0KICAgY29uZmlndXJhdGlvbiBkYXRhLCBidXQgbm90IHN0YXRlIGRhdGEuDQoNCiAgIFRoZSBz eXN0ZW0gTVVTVCBlbnN1cmUgdGhhdCBjb25maWd1cmF0aW9uIHJlc291cmNlcyBjb3ZlcmVkIGJ5 IHRoZQ0KICAgbG9jayBhcmUgbm90IG1vZGlmaWVkIGJ5IG90aGVyIE5FVENPTkYgb3Igbm9uLU5F VENPTkYgbWFuYWdlbWVudA0KICAgb3BlcmF0aW9ucyBzdWNoIGFzIFNOTVAgYW5kIHRoZSBDTEku DQoNCiAgIFRoZSBkdXJhdGlvbiBvZiB0aGUgcGFydGlhbCBsb2NrIGlzIGRlZmluZWQgYXMgYmVn aW5uaW5nIHdoZW4gdGhlDQogICBwYXJ0aWFsIGxvY2sgaXMgZ3JhbnRlZC4gIFRoZSBwYXJ0aWFs IGxvY2sgbGFzdHMgdW50aWwgZWl0aGVyIHRoZQ0KICAgY29ycmVzcG9uZGluZyA8cGFydGlhbC11 bmxvY2s+IG9wZXJhdGlvbiBzdWNjZWVkcyBvciB0aGUgTkVUQ09ORg0KICAgc2Vzc2lvbiB0ZXJt aW5hdGVzLg0KDQogICBBIE5FVENPTkYgc2Vzc2lvbiBNQVkgaGF2ZSBtdWx0aXBsZSBwYXJ0cyBv ZiBvbmUgb3IgbW9yZSBkYXRhc3RvcmVzDQogICAocnVubmluZywgY2FuZGlkYXRlLHN0YXJ0dXAp IGxvY2tlZCB1c2luZyBwYXJ0aWFsIGxvY2sgb3BlcmF0aW9ucy4NCiAgIFRoZSA8cGFydGlhbC1s b2NrPiBvcGVyYXRpb24gcmV0dXJucyBhIGxvY2staWQgdG8gaWRlbnRpZnkgZWFjaA0KICAgc3Vj Y2Vzc2Z1bGx5IGFjcXVpcmVkIGxvY2suDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5k ICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICAgW1BhZ2UgM10NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAg ICBTZXB0ZW1iZXIgMjAwOA0KDQoNCjIuMi4gIERlcGVuZGVuY2llcw0KDQogICBUaGUgZGV2aWNl IE1VU1Qgc3VwcG9ydCB0aGUgcmVzdHJpY3RlZCBYUGF0aCBleHByZXNzaW9ucyBpbiB0aGUNCiAg IHNlbGVjdCBlbGVtZW50LCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjQuMS4gIElmIG9wdGlv bmFsbHkgdGhlDQogICA6eHBhdGggY2FwYWJpbGl0eSBpcyBhbHNvIHN1cHBvcnRlZCwgdGhlIGRl dmljZSBNVVNUIGFsc28gc3VwcG9ydCB0aGUNCiAgIHVzYWdlIG9mIGFueSBYUGF0aCAxLjAgZXhw cmVzc2lvbiBpbiB0aGUgc2VsZWN0IGVsZW1lbnQuDQoNCjIuMy4gIENhcGFiaWxpdHkgSWRlbnRp Zmllcg0KDQogICB1cm46aWV0ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5OnBhcnRpYWwtbG9j azoxLjANCg0KMi40LiAgTmV3IE9wZXJhdGlvbnMNCg0KMi40LjEuICA8cGFydGlhbC1sb2NrPg0K DQogICBUaGUgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uIGFsbG93cyB0aGUgY2xpZW50IHRvIGxv Y2sgYSBwb3J0aW9uIG9mIGENCiAgIGRhdGEgc3RvcmUuICBUaGUgcG9ydGlvbiB0byBsb2NrIGlz IHNwZWNpZmllZCBieSB1c2luZyBYUGF0aA0KICAgZXhwcmVzc2lvbnMgaW4gdGhlIHNlbGVjdCBl bGVtZW50cyBvZiB0aGUgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uLg0KICAgRWFjaCBYUGF0aCBl eHByZXNzaW9uIE1VU1QgcmV0dXJuIGEgbm9kZSBzZXQuICBMb2NraW5nIGEgbm9kZQ0KICAgcHJv dGVjdHMgdGhlIGNvbXBsZXRlIHN1YnRyZWUgdW5kZXIgaXQgZnJvbSBtb2RpZmljYXRpb24gYnkg b3RoZXJzLg0KDQogICBUaGUgc2VsZWN0IFhQYXRoIGV4cHJlc3Npb25zIGFyZSBldmFsdWF0ZWQg b25seSBvbmNlIGF0IGxvY2sgdGltZSwNCiAgIHRoZXJlYWZ0ZXIgdGhlIHNjb3BlIG9mIHRoZSBs b2NrIGlzIG1haW50YWluZWQgYXMgYSBzZXQgb2Ygbm9kZXMuICBJZg0KICAgdGhlIGNvbmZpZ3Vy YXRpb24gZGF0YSBpcyBsYXRlciBhbHRlcmVkIGluIGEgd2F5IHRoYXQgd291bGQgbWFrZSB0aGUN CiAgIG9yaWdpbmFsIHNlbGVjdCBYUGF0aCBleHByZXNzaW9ucyBldmFsdWF0ZSB0byBhIGRpZmZl cmVudCBzZXQgb2YNCiAgIG5vZGVzLCB0aGlzIGRvZXMgbm90IGFmZmVjdCB0aGUgc2NvcGUgb2Yg dGhlIHBhcnRpYWwgbG9jay4NCg0KICAgWFBhdGggaXMgb25seSB1c2VkIGZvciB0aGUgY3JlYXRp b24gb2YgdGhlIHBhcnRpYWwgbG9jay4NCiAgIENvbmNlcHR1YWxseSB0aGUgc2NvcGUgb2YgdGhl IGxvY2sgaXMgZGVmaW5lZCBieSB0aGUgcmV0dXJuZWQgbm9kZQ0KICAgc2V0IGFuZCBub3QgYnkg dGhlIFhQYXRoIGV4cHJlc3Npb24uDQoNCiAgIEEgPHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uIE1V U1QgYmUgaGFuZGxlZCBhdG9taWNhbGx5IGJ5IHRoZSBORVRDT05GDQogICBzZXJ2ZXIuICBUaGUg c2VydmVyIGVpdGhlciBsb2NrcyBhbGwgcmVxdWVzdGVkIHBhcnRzIG9mIHRoZSBkYXRhDQogICBz dG9yZSBvciBub25lOyBJLmUuIGlmIGR1cmluZyB0aGUgb3BlcmF0aW9uIG9uZSBvZiB0aGUgcmVx dWVzdGVkDQogICBwYXJ0cyBjYW5ub3QgYmUgbG9ja2VkIHRoZSBzZXJ2ZXIgTVVTVCB1bmxvY2sg YWxsIHBhcnRzIHRoYXQgaGF2ZQ0KICAgYmVlbiBhbHJlYWR5IGxvY2tlZCBkdXJpbmcgdGhhdCBv cGVyYXRpb24uDQoNCiAgIElmIGEgbm9kZSBpcyBsb2NrZWQgYnkgYSBzZXNzaW9uLCBvbmx5IHRo YXQgc2FtZSBzZXNzaW9uIGlzIGFibGUgdG8NCiAgIG1vZGlmeSB0aGF0IG5vZGUgb3IgYW55IG5v ZGUgaW4gdGhlIHN1YnRyZWUgdW5kZXJuZWF0aCBpdC4NCg0KICAgSWYgYSB0b3AgbGV2ZWwgbm9k ZSBvZiBhIGxvY2tlZCBzdWJ0cmVlIGlzIGRlbGV0ZWQsIGFueSBvdGhlciBzZXNzaW9uDQogICBj YW4gcmVjcmVhdGUgaXQsIGFzIGl0IGlzIG5vdCBjb3ZlcmVkIGJ5IHRoZSBsb2NrIGFueW1vcmUu ICBJZiBhbGwNCiAgIHRvcCBsZXZlbCBub2RlcyBhcmUgZGVsZXRlZCwgdGhlIGxvY2sgd2lsbCBz dGlsbCBiZSBwcmVzZW50LCBob3dldmVyDQogICBpdCdzIHNjb3BlIHdpbGwgYmVjb21lIG5pbCBp LmUuIGl0IHdpbGwgbm90IGNvdmVyIGFueSBub2Rlcy4NCg0KICAgQSBORVRDT05GIHNlcnZlciBN VVNUIGJlIGFibGUgdG8gZ3JhbnQgbXVsdGlwbGUgc2ltdWx0YW5lb3VzIHBhcnRpYWwNCiAgIGxv Y2tzIHRvIGEgc2luZ2xlIE5FVENPTkYgc2Vzc2lvbi4gIElmIHRoZSBzY29wZSBvZiB0aGUgaW5k aXZpZHVhbA0KICAgbG9ja3Mgb3ZlcmxhcCwgbm9kZXMgaW4gdGhlIGNvbW1vbiBhcmVhIE1VU1Qg YmUgbG9ja2VkIHVudGlsIGFsbCBvZg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4 cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVt YmVyIDIwMDgNCg0KDQogICB0aGUgbG9ja3MgYXJlIHJlbGVhc2VkLg0KDQogICBBIHBhcnRpYWwg bG9jayBvcGVyYXRpb24gTVVTVCBmYWlsIGlmOg0KDQogICBvICBBbnkgTkVUQ09ORiBzZXNzaW9u IChpbmNsdWRpbmcgdGhlIGN1cnJlbnQgc2Vzc2lvbikgb3ducyB0aGUNCiAgICAgIGdsb2JhbCBs b2NrIG9uIHRoZSBkYXRhc3RvcmUuDQoNCiAgIG8gIEFueSBwYXJ0IG9mIHRoZSBzY29wZSB0byBi ZSBsb2NrZWQgaXMgYWxyZWFkeSBsb2NrZWQgYnkgYW5vdGhlcg0KICAgICAgbWFuYWdlbWVudCBz ZXNzaW9uL3Byb3RvY29sLCBpbmNsdWRpbmcgb3RoZXIgTkVUQ09ORiBzZXNzaW9ucw0KICAgICAg dXNpbmcgdGhlIDxwYXJ0aWFsLWxvY2s+IG9yIGFueSBvdGhlciBub24tTkVUQ09ORiBtYW5hZ2Vt ZW50DQogICAgICBtZXRob2QuDQoNCiAgIG8gIFRoZSBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRz IGFjY2VzcyBjb250cm9sIGFuZCB0aGUgbG9ja2luZyB1c2VyDQogICAgICBkb2VzIG5vdCBoYXZl IHN1ZmZpY2llbnQgcHJpdmlsZWdlcywgdG8gYWxsIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmUNCiAg ICAgIHNlY3Rpb24gdG8gYmUgbG9ja2VkLiAgVGhlIGV4YWN0IGhhbmRsaW5nIG9mIGFjY2VzcyBy aWdodHMgaXMNCiAgICAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIGJ1dCBp dCBpcyBhc3N1bWVkIHRoYXQgdGhlcmUNCiAgICAgIGlzIGFuIGFjY2VzcyBjb250cm9sIHN5c3Rl bSB0aGF0IE1BWSBkZW55IG9yIGFsbG93IHRoZSBwYXJ0aWFsDQogICAgICBsb2NrIG9wZXJhdGlv bi4NCg0KICAgTm90ZTogSWYgcGFydGlhbCBsb2NrIGlzIHJlcXVlc3RlZCBmb3IgdGhlIHJ1bm5p bmcgZGF0YXN0b3JlLCBhbmQgdGhlDQogICBORVRDT05GIHNlcnZlciBpbXBsZW1lbnRzIHRoZSA6 Y29uZmlybWVkLWNvbW1pdCBjYXBhYmlsaXR5LCBhbmQgdGhlcmUNCiAgIHdhcyBhIHJlY2VudCBj b25maXJtZWQgPGNvbW1pdD4gb3BlcmF0aW9uLCB3aGVyZSB0aGUgY29uZmlybWluZw0KICAgPGNv bW1pdD4gb3BlcmF0aW9uIGhhcyBub3QgYmVlbiByZWNlaXZlZC4gIEluIHRoaXMgY2FzZSB0aGUg bG9jayBNVVNUDQogICBiZSBkZW5pZWQsIGJlY2F1c2UgaWYgdGhlIGNvbmZpcm1hdGlvbiBkb2Vz IG5vdCBhcnJpdmUsIHRoZSBydW5uaW5nDQogICBkYXRhc3RvcmUgTVVTVCBiZSByb2xsZWQgYmFj ayB0byBpdHMgc3RhdGUgYmVmb3JlIHRoZSBjb21taXQsIHRodXMNCiAgIHRoZSBORVRDT05GIHNl cnZlciBtaWdodCBuZWVkIHRvIG1vZGlmeSB0aGUgY29uZmlndXJhdGlvbi4NCg0KICAgQXMgd2l0 aCBtb3N0IGxvY2tpbmcgc3lzdGVtcywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0eSB0aGF0IHR3bw0K ICAgbWFuYWdlbWVudCBzZXNzaW9ucyB0cnlpbmcgdG8gbG9jayBkaWZmZXJlbnQgcGFydHMgb2Yg dGhlDQogICBjb25maWd1cmF0aW9uIGNvdWxkIGJlY29tZSBkZWFkLWxvY2tlZC4gIFRvIGF2b2lk IHRoaXMgc2l0dWF0aW9uLA0KICAgY2xpZW50cyBTSE9VTEQgbG9jayBldmVyeXRoaW5nIHRoZXkg bmVlZCBpbiBvbmUgb3BlcmF0aW9uLiAgSWYgdGhhdA0KICAgb3BlcmF0aW9uIHN0aWxsIGZhaWxz LCB0aGUgY2xpZW50IFNIT1VMRCBiYWNrIGRvd24sIHJlbGVhc2UgYW55DQogICBhbHJlYWR5IGFj cXVpcmVkIGxvY2tzLCBhbmQgcmV0cnkgdGhlIHByb2NlZHVyZSBhZnRlciBzb21lIHRpbWUNCiAg IGludGVydmFsLiAgVGhlIGxlbmd0aCBvZiB0aGUgaW50ZXJ2YWwgc2hvdWxkIHByZWZlcmFibHkg YmUgcmFuZG9tIHRvDQogICBhdm9pZCByZXBlYXRlZCBkZWFkLWxvY2tzIHdoZW4gYm90aCAob3Ig YWxsKSBjbGllbnRzIGJhY2sgZG93biBhbmQNCiAgIHRoZW4gcmVwZWF0IGxvY2tpbmcuDQoNCiAg IEl0IGlzIHRoZSBpbnRlbnRpb24gdG8ga2VlcCBwYXJ0aWFsLWxvY2tpbmcgc2ltcGxlLCBzbyB3 aGVuIGEgcGFydGlhbA0KICAgbG9jayBpcyBleGVjdXRlZCB5b3UgZ2V0IHdoYXQgeW91IGFza2Vk IGZvcjogYSBzZXQgb2Ygbm9kZXMgdGhhdCBhcmUNCiAgIGxvY2tlZCBmb3Igd3JpdGluZy4gIFRo ZXJlIGFyZSBzb21lIG90aGVyIGlzc3VlcyB0aGF0IGFyZQ0KICAgaW50ZW50aW9uYWxseSBub3Qg YWRkcmVzc2VkIGZvciB0aGUgc2FrZSBvZiBzaW1wbGljaXR5Og0KDQogICBvICBMb2NraW5nIGRv ZXMgbm90IGFmZmVjdCByZWFkIG9wZXJhdGlvbnMuDQoNCiAgIG8gIElmIGEgcGFydCBvZiBhIGRh dGFzdG9yZSBpcyBsb2NrZWQsIHRoaXMgaGFzIG5vIGVmZmVjdCBvbiBhbnkNCiAgICAgIHVubG9j a2VkIHBhcnRzIG9mIHRoZSBkYXRhc3RvcmUuICBJZiB0aGlzIGlzIGEgcHJvYmxlbSBlLmcuIHRo ZQ0KICAgICAgb3BlcmF0b3IncyBjaGFuZ2VzIGRlcGVuZCBvbiBkYXRhIHZhbHVlcyBpbiB0aGUg dW5sb2NrZWQgcGFydCBvZg0KICAgICAgdGhlIGRhdGFzdG9yZSwgdGhlIG9wZXJhdG9yIHNob3Vs ZCBpbmNsdWRlIHRoZXNlIHZhbHVlcyBpbiB0aGUNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQg ICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAg IFNlcHRlbWJlciAyMDA4DQoNCg0KICAgICAgc2NvcGUgb2YgdGhlIGxvY2suDQoNCiAgIG8gIEFu IG9wZXJhdG9yIGlzIGFsbG93ZWQgdG8gZWRpdCB0aGUgY29uZmlndXJhdGlvbiBib3RoIGluc2lk ZSBhbmQNCiAgICAgIG91dHNpZGUgdGhlIHNjb3BlIG9mIGEgbG9jay4gIEl0IGlzIHRoZSBvcGVy YXRvcidzIHJlc3BvbnNpYmlsaXR5DQogICAgICB0byBsb2NrIGFsbCBwYXJ0cyBvZiB0aGUgZGF0 YXN0b3JlIHRoYXQgYXJlIGNydWNpYWwgZm9yIGEgc3BlY2lmaWMNCiAgICAgIG1hbmFnZW1lbnQg YWN0aW9uLg0KDQoNCiAgIE5vdGU6IFRoZSA8cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gZG9lcyBu b3QgbW9kaWZ5IHRoZSBnbG9iYWwgPGxvY2s+DQogICBvcGVyYXRpb24gZGVmaW5lZCBpbiB0aGUg YmFzZSBORVRDT05GIFByb3RvY29sIFtORVRDT05GXS4gIElmIHBhcnQgb2YNCiAgIGEgZGF0YXN0 b3JlIGlzIGFscmVhZHkgbG9ja2VkIGJ5IDxwYXJ0aWFsLWxvY2s+LCB0aGVuIGEgZ2xvYmFsIGxv Y2sNCiAgIGZvciB0aGF0IGRhdGFzdG9yZSBmYWlscyBldmVuIGlmIHRoZSBnbG9iYWwgbG9jayBp cyBhdHRlbXB0ZWQgYnkgdGhlDQogICBzYW1lIE5FVENPTkYgc2Vzc2lvbiB3aGljaCBvd25zIHRo ZSBwYXJ0aWFsLWxvY2suDQoNCjIuNC4xLjEuICBQYXJhbWV0ZXJzLCBSZXN1bHQsIEV4YW1wbGVz DQoNCiAgIFBhcmFtZXRlcnM6DQoNCiAgIHRhcmdldDogIE5hbWUgb2YgdGhlIGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlIG9mIHdoaWNoIGEgcGFydCBzaGFsbCBiZQ0KICAgICAgIGxvY2tlZC4gIE9u ZSA8cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gY2FuIGFmZmVjdCBvbmx5IG9uZSBvZiB0aGUNCiAg ICAgICBkYXRhc3RvcmVzLCBzbyBvbmx5IG9uZSA8dGFyZ2V0PiBwYXJhbWV0ZXIgaXMgYWxsb3dl ZC4gIFVSTHMgYXJlDQogICAgICAgbm90IGFjY2VwdGVkLg0KDQogICBzZWxlY3Q6ICBPbmUgb3Ig bW9yZSAnc2VsZWN0JyBlbGVtZW50cyBlYWNoIGNvbnRhaW5pbmcgYW4gWFBhdGgNCiAgICAgICBl eHByZXNzaW9uLiAgVGhlIFhQYXRoIGV4cHJlc3Npb24gaXMgZXZhbHVhdGVkIGluIGEgY29udGV4 dCB3aGVyZQ0KICAgICAgIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIHJvb3Qgb2YgdGhlIHNlcnZl cidzIGNvbmNlcHR1YWwgZGF0YQ0KICAgICAgIG1vZGVsLCBhbmQgdGhlIHNldCBvZiBuYW1lc3Bh Y2UgZGVjbGFyYXRpb25zIGFyZSB0aG9zZSBpbiBzY29wZQ0KICAgICAgIG9uIHRoZSBzZWxlY3Qg ZWxlbWVudC4NCg0KICAgICAgIFRoZSBzZWxlY3QgZXhwcmVzc2lvbnMgTVVTVCBlYWNoIHJldHVy biBhIG5vZGUgc2V0LCBhbmQgYXQgbGVhc3QNCiAgICAgICBvbmUgb2YgdGhlIG5vZGUgc2V0cyBt dXN0IGJlIG5vbi1lbXB0eS4NCg0KICAgICAgIElmIHRoZSBkZXZpY2Ugc3VwcG9ydHMgdGhlIDp4 cGF0aCBjYXBhYmlsaXR5IHRoZW4gYW55IHZhbGlkIFhQYXRoDQogICAgICAgMS4wIGV4cHJlc3Np b24gY2FuIGJlIHVzZWQsIGlmIG5vdCwgdGhlIFhQYXRoIGV4cHJlc3Npb24gTVVTVCBiZQ0KICAg ICAgIGxpbWl0ZWQgdG8gYW4gSW5zdGFuY2UgSWRlbnRpZmllciBleHByZXNzaW9uLiAgQW4gSW5z dGFuY2UNCiAgICAgICBJZGVudGlmaWVyIGlzIGFuIGFic29sdXRlIHBhdGggZXhwcmVzc2lvbiBp biBhYmJyZXZpYXRlZCBzeW50YXgsDQogICAgICAgd2hlcmUgcHJlZGljYXRlcyBhcmUgdXNlZCBv bmx5IHRvIHNwZWNpZnkgdmFsdWVzIGZvciBub2Rlcw0KICAgICAgIGRlZmluZWQgYXMga2V5cyB0 byBkaXN0aW5ndWlzaCBtdWx0aXBsZSBpbnN0YW5jZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9j ayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAgRXhhbXBsZTog TG9jayB2aXJ0dWFsIHJvdXRlciAxIGFuZCBpbnRlcmZhY2UgZXRoMQ0KDQoNCiAgICAgICA8bmM6 cnBjDQogICAgICAgICB4bWxuczpuYz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJh c2U6MS4wIg0KICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpw YXJ0aWFsLWxvY2s6MS4wIg0KICAgICAgICAgbmM6bWVzc2FnZS1pZD0iMTM1Ij4NCiAgICAgICAg ICAgPHBhcnRpYWwtbG9jaz4NCiAgICAgICAgICAgICAgIDxuYzp0YXJnZXQ+DQogICAgICAgICAg ICAgICAgICAgPG5jOnJ1bm5pbmcvPg0KICAgICAgICAgICAgICAgPC9uYzp0YXJnZXQ+DQogICAg ICAgICAgICAgICA8c2VsZWN0IHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vbnMvcm91dGUiPg0K ICAgICAgICAgICAgICAgICAgIC9yb3V0aW5nL3ZpcnR1YWxSb3V0ZXJbcm91dGVyTmFtZT0ncm91 dGVyMSddDQogICAgICAgICAgICAgICA8L3NlbGVjdD4NCiAgICAgICAgICAgICAgIDxzZWxlY3Qg eG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9pbnRlcmZhY2UiPg0KICAgICAgICAgICAgICAg ICAgIC9pbnRlcmZhY2VzL2ludGVyZmFjZVtpZD0nZXRoMSddDQogICAgICAgICAgICAgICAgPC9z ZWxlY3Q+DQogICAgICAgICAgICA8L3BhcnRpYWwtbG9jaz4NCiAgICAgICA8L25jOnJwYz4NCg0K ICAgICAgIDxuYzpycGMtcmVwbHkNCiAgICAgICAgIHhtbG5zOm5jPSJ1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiDQogICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazoxLjAiDQogICAgICAgICBuYzptZXNzYWdlLWlk PSIxMzUiPg0KICAgICAgICAgICA8bmM6ZGF0YT4NCiAgICAgICAgICAgICAgIDxsb2NrLWlkPjEy NzwvbG9jay1pZD4NCiAgICAgICAgICAgICAgIDxsb2NrZWQtbm9kZSB4bWxucz0iaHR0cDovL2V4 YW1wbGUuY29tL25zL3JvdXRlIj4NCiAgICAgICAgICAgICAgICAgICAvcm91dGluZy92aXJ0dWFs Um91dGVyW3JvdXRlck5hbWU9J3JvdXRlcjEnXQ0KICAgICAgICAgICAgICAgPC9sb2NrZWQtbm9k ZT4NCiAgICAgICAgICAgICAgIDxsb2NrZWQtbm9kZSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29t L25zL2ludGVyZmFjZSI+DQogICAgICAgICAgICAgICAgICAgL2ludGVyZmFjZXMvaW50ZXJmYWNl W2lkPSdldGgxJ10NCiAgICAgICAgICAgICAgIDwvbG9ja2VkLW5vZGU+DQogICAgICAgICAgIDwv bmM6ZGF0YT4NCiAgICAgICA8L25jOnJwYy1yZXBseT4NCg0KDQogICBQb3NpdGl2ZSBSZXNwb25z ZToNCg0KICAgSWYgdGhlIGRldmljZSB3YXMgYWJsZSB0byBzYXRpc2Z5IHRoZSByZXF1ZXN0LCBh biA8cnBjLXJlcGx5PiBpcyBzZW50DQogICB3aXRoIGEgPGxvY2staWQ+IGVsZW1lbnQgKGxvY2sg aWRlbnRpZmllcikgaW4gdGhlIDxkYXRhPiBlbGVtZW50LiAgQQ0KICAgbGlzdCBvZiBsb2NrZWQt bm9kZXMgaXMgYWxzbyByZXR1cm5lZC4NCg0KICAgTmVnYXRpdmUgUmVzcG9uc2U6DQoNCiAgIElm IGEgbG9jayBpcyBhbHJlYWR5IGhlbGQgYnkgYW5vdGhlciBzZXNzaW9uIG9uIGFueSBub2RlIHdp dGhpbiB0aGUNCiAgIHN1YnRyZWVzIHRvIGJlIGxvY2tlZCwgdGhlIDxlcnJvci10YWc+IGVsZW1l bnQgaXMgJ2xvY2stZGVuaWVkJyBhbmQNCiAgIHRoZSA8ZXJyb3ItaW5mbz4gZWxlbWVudCBpbmNs dWRlcyB0aGUgPHNlc3Npb24taWQ+IG9mIHRoZSBsb2NrIG93bmVyLg0KICAgSWYgdGhlIGxvY2sg aXMgaGVsZCBieSBhIG5vbi1ORVRDT05GIHNlc3Npb24sIGEgPHNlc3Npb24taWQ+IG9mIDANCg0K DQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAg ICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9j ayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAgKHplcm8pIGlz IGluY2x1ZGVkLiAgSWYgbmVlZGVkIHRoZSByZXR1cm5lZCBzZXNzaW9uLWlkIG1heSBiZSB1c2Vk IHRvDQogICA8a2lsbD4gdGhlIE5FVENPTkYgc2Vzc2lvbiBob2xkaW5nIHRoZSBsb2NrLiAgVGhl IHNhbWUgZXJyb3IgcmVzcG9uc2UNCiAgIGlzIHJldHVybmVkIGlmIHRoZSByZXF1ZXN0aW5nIHNl c3Npb24gYWxyZWFkeSBob2xkcyB0aGUgKGdsb2JhbCkgbG9jaw0KICAgZm9yIHRoZSBzYW1lIGRh dGFzdG9yZS4NCg0KICAgSWYgdGhlIHNlbGVjdCBleHByZXNzaW9ucyByZXR1cm4gYW4gZW1wdHkg bm9kZSBzZXQsIHRoZSA8ZXJyb3ItdGFnPg0KICAgaXMgJ29wZXJhdGlvbi1mYWlsZWQnLCBhbmQg dGhlIDxlcnJvci1hcHAtdGFnPiBpcyAnbm8tbWF0Y2hlcycuDQoNCiAgIElmIGFueSBzZWxlY3Qg ZXhwcmVzc2lvbiByZXR1cm5zIGFueXRoaW5nIGJ1dCBhIG5vZGUgc2V0LCB0aGUgPGVycm9yLQ0K ICAgdGFnPiBpcyAnaW52YWxpZC12YWx1ZScsIHRoZSA8ZXJyb3ItYXBwLXRhZz4gaXMgJ1hQYXRo IGRvZXMgbm90DQogICByZXR1cm4gYSBub2RlIHNldCcuDQoNCiAgIElmIHRoZSA6eHBhdGggY2Fw YWJpbGl0eSBpcyBub3Qgc3VwcG9ydGVkIGFuZCB0aGUgWFBhdGggZXhwcmVzc2lvbiBpcw0KICAg bm90IGFuIEluc3RhbmNlIElkZW50aWZpZXIsIHRoZSA8ZXJyb3ItdGFnPiBpcyAnaW52YWxpZC12 YWx1ZScsIHRoZQ0KICAgPGVycm9yLWFwcC10YWc+IGlzICc6eHBhdGggY2FwYWJpbGl0eSBub3Qg c3VwcG9ydGVkJy4NCg0KICAgSWYgYWNjZXNzIGNvbnRyb2wgZGVuaWVzIHRoZSBwYXJ0aWFsIGxv Y2ssIHRoZSA8ZXJyb3ItdGFnPiBpcw0KICAgJ2FjY2Vzcy1kZW5pZWQnLg0KDQoNCjIuNC4xLjIu ICBSZXNlcnZpbmcgbW9kZWwgc2VjdGlvbnMgZm9yIGZ1dHVyZSB3b3JrDQoNCiAgIFBhcnRpYWwg bG9jayBjYW4gbm90IGJlIHVzZWQgdG8gbG9jayBub24tZXhpc3Rpbmcgbm9kZXMsIGVmZmVjdGl2 ZWx5DQogICByZXNlcnZpbmcgdGhlbSBmb3IgZnV0dXJlIHVzZS4gIFRvIG1ha2Ugc3VyZSB0aGF0 IGEgbm9kZSBjYW5ub3QgYmUNCiAgIGNyZWF0ZWQgYnkgc29tZSBvdGhlciBzZXNzaW9uLCB0aGUg cGFyZW50IG5vZGUgc2hvdWxkIGJlIGxvY2tlZCwgdGhlDQogICB0b3AgbGV2ZWwgbm9kZSBvZiB0 aGUgbmV3IHNlY3Rpb24gY3JlYXRlZCwgYW5kIHRoZW4gbG9ja2VkIHdpdGgNCiAgIGFub3RoZXIg PHBhcnRpYWwtbG9jaz4gb3BlcmF0aW9uLiAgQWZ0ZXIgdGhpcyB0aGUgbG9jayBvbiB0aGUgcGFy ZW50DQogICBub2RlIHNob3VsZCBiZSByZW1vdmVkLg0KDQoyLjQuMi4gIDxwYXJ0aWFsLXVubG9j az4NCg0KICAgVGhlIG9wZXJhdGlvbiB1bmxvY2tzIGEgcGFydCBvZiBhIGRhdGFzdG9yZSB0aGF0 IHdhcyBwcmV2aW91c2x5DQogICBsb2NrZWQgdXNpbmcgPHBhcnRpYWwtbG9jaz4gZHVyaW5nIHRo ZSBzYW1lIHNlc3Npb24uDQoNCiAgIFBhcmFtZXRlcnM6DQoNCiAgIGxvY2staWQ6ICBMb2NrIGlk ZW50aWZpZXIgdG8gdW5sb2NrOyB0YWtlbiBmcm9tIGEgcmVwbHkgdG8gYSBwcmV2aW91cw0KICAg ICAgIDxwYXJ0aWFsLWxvY2s+IG9wZXJhdGlvbi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K TGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQ QyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQogICBFeGFtcGxlOiBVbmxv Y2sgYSBwcmV2aW91c2x5IGNyZWF0ZWQgbG9jaw0KDQoNCiAgIDxuYzpycGMgeG1sbnM6bmM9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCINCiAgICAgICB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazoxLjAiDQogICAgICAgbmM6 bWVzc2FnZS1pZD0iMTM2Ij4NCiAgICAgICA8cGFydGlhbC11bmxvY2s+DQogICAgICAgICAgIDxs b2NrLWlkPjEyNzwvbG9jay1pZD4NCiAgICAgICA8L3BhcnRpYWwtdW5sb2NrPg0KICAgPC9uYzpy cGM+DQoNCiAgIFBvc2l0aXZlIFJlc3BvbnNlOg0KDQogICBJZiB0aGUgZGV2aWNlIHdhcyBhYmxl IHRvIHNhdGlzZnkgdGhlIHJlcXVlc3QsIGFuIDxycGMtcmVwbHk+IGlzIHNlbnQNCiAgIHRoYXQg Y29udGFpbnMgYW4gPG9rPiBlbGVtZW50LiAgQSBwb3NpdGl2ZSByZXNwb25zZSBNVVNUIGJlIHNl bnQgZXZlbg0KICAgaWYgYWxsIG9mIHRoZSBsb2NrZWQgcGFydCBvZiB0aGUgZGF0YXN0b3JlIGhh cyBhbHJlYWR5IGJlZW4gZGVsZXRlZC4NCg0KICAgTmVnYXRpdmUgUmVzcG9uc2U6DQoNCiAgIElm IHRoZSA8bG9jay1pZD4gcGFyYW1ldGVyIGRvZXMgbm90IGlkZW50aWZ5IGEgbG9jayB3aGljaCBp cyBvd25lZCBieQ0KICAgdGhlIHNlc3Npb24sIGFuICdpbnZhbGlkLXZhbHVlJyBlcnJvciBpcyBy ZXR1cm5lZC4NCg0KMi41LiAgTW9kaWZpY2F0aW9ucyB0byBFeGlzdGluZyBPcGVyYXRpb25zDQoN CiAgIEEgZ3JhbnRlZCBwYXJ0aWFsLWxvY2sgd2lsbCBjYXVzZSBhbm90aGVyIG9wZXJhdGlvbiB0 byBmYWlsLCBpZiBpdA0KICAgdHJpZXMgdG8gbW9kaWZ5IHRoZSBsb2NrZWQgYXJlYSBhbmQgaXMg ZXhlY3V0ZWQgaW4gYSBORVRDT05GIHNlc3Npb24NCiAgIG90aGVyIHRoZW4gdGhlIG9uZSB0aGF0 IG93bnMgdGhlIGxvY2suICBBbGwgb3BlcmF0aW9ucyB0aGF0IG1vZGlmeQ0KICAgdGhlIGRhdGFz dG9yZSBhcmUgYWZmZWN0ZWQgaW5jbHVkaW5nOiA8ZWRpdC1jb25maWc+LCA8Y29weS1jb25maWc+ LA0KICAgPGRlbGV0ZS1jb25maWc+LCA8Y29tbWl0PiBhbmQgPGRpc2NhcmQtY2hhbmdlcz4uICBB IGdyYW50ZWQgcGFydGlhbC0NCiAgIGxvY2sgd2lsbCBhbHNvIGNhdXNlIHRoZSAoZ2xvYmFsKSA8 bG9jaz4gb3BlcmF0aW9uIHRvIGZhaWwuICBBbGwgb2YNCiAgIHRoZXNlIG9wZXJhdGlvbnMgYXJl IGFmZmVjdGVkIG9ubHkgaWYgdGhleSBhcmUgZm9yIHRoZSBzYW1lDQogICBkYXRhc3RvcmUuDQoN CjIuNi4gIEludGVyYWN0aW9ucyB3aXRoIE90aGVyIENhcGFiaWxpdGllcw0KDQoyLjYuMS4gIFdy aXRhYmxlLVJ1bm5pbmcgQ2FwYWJpbGl0eQ0KDQogICBQYXJ0aWFsIGxvY2tpbmcgb2YgdGhlIHJ1 bm5pbmcgZGF0YXN0b3JlIGNhbiBvbmx5IGJlIGRvbmUgaWYgdGhlDQogICA6d3JpdGFibGUtcnVu bmluZyBjYXBhYmlsaXR5IGlzIHN1cHBvcnRlZCBieSB0aGUgZGV2aWNlLg0KDQoyLjYuMi4gIENh bmRpZGF0ZSBDb25maWd1cmF0aW9uIENhcGFiaWxpdHkNCg0KICAgUGFydGlhbCBsb2NraW5nIG9m IHRoZSBjYW5kaWRhdGUgZGF0YXN0b3JlIGNhbiBvbmx5IGJlIGRvbmUgaWYgdGhlDQogICA6Y2Fu ZGlkYXRlIGNhcGFiaWxpdHkgaXMgc3VwcG9ydGVkIGJ5IHRoZSBkZXZpY2UuICBUaGUgcGFydGlh bA0KICAgbG9ja2luZyBvZiB0aGUgY2FuZGlkYXRlIGRhdGFzdG9yZSBkb2VzIG5vdCBkZXBlbmQg b24gd2hldGhlciB0aGUNCiAgIGRhdGFzdG9yZSB3YXMgbW9kaWZpZWQgb3Igbm90Lg0KDQogICBJ ZiBwYXJ0aWFsIGxvY2sgaXMgcmVxdWVzdGVkIGZvciB0aGUgcnVubmluZyBkYXRhc3RvcmUsIGFu ZCB0aGUNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQgICAgICBFeHBpcmVzIE1hcmNoIDEyLCAy MDA5ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFBh cnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAgIFNlcHRlbWJlciAyMDA4DQoNCg0KICAg TkVUQ09ORiBzZXJ2ZXIgaW1wbGVtZW50cyB0aGUgOmNvbmZpcm1lZC1jb21taXQgY2FwYWJpbGl0 eSwgYW5kIHRoZXJlDQogICB3YXMgYSByZWNlbnQgY29uZmlybWVkIDxjb21taXQ+IG9wZXJhdGlv biwgd2hlcmUgdGhlIGNvbmZpcm1pbmcNCiAgIDxjb21taXQ+IG9wZXJhdGlvbiBoYXMgbm90IGJl ZW4gcmVjZWl2ZWQsIGluIHRoaXMgY2FzZSB0aGUgbG9jayBNVVNUDQogICBiZSBkZW5pZWQsIGJl Y2F1c2UgaWYgdGhlIGNvbmZpcm1hdGlvbiBkb2VzIG5vdCBhcnJpdmUsIHRoZSBydW5uaW5nDQog ICBkYXRhc3RvcmUgTVVTVCBiZSByb2xsZWQgYmFjayB0byBpdHMgc3RhdGUgYmVmb3JlIHRoZSBj b21taXQsIHRodXMNCiAgIHRoZSBORVRDT05GIHNlcnZlciBtaWdodCBuZWVkIHRvIG1vZGlmeSB0 aGUgY29uZmlndXJhdGlvbi4NCg0KMi42LjMuICBEaXN0aW5jdCBTdGFydHVwIENhcGFiaWxpdHkN Cg0KICAgUGFydGlhbCBsb2NraW5nIG9mIHRoZSBzdGFydHVwIGRhdGFzdG9yZSBjYW4gb25seSBi ZSBkb25lIGlmIHRoZQ0KICAgOnN0YXJ0dXAgY2FwYWJpbGl0eSBpcyBzdXBwb3J0ZWQgYnkgdGhl IGRldmljZS4NCg0KDQozLiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhlIHNhbWUg Y29uc2lkZXJhdGlvbnMgYXMgZm9yIHRoZSBiYXNlIE5FVENPTkYgUHJvdG9jb2wgW05FVENPTkZd DQogICBhcmUgdmFsaWQuICBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIDxwYXJ0aWFsLWxvY2s+IGFu ZCA8cGFydGlhbC0NCiAgIHVubG9jaz4gUlBDcyBhcmUgb25seSBhbGxvd2VkIGZvciBhbiBhdXRo ZW50aWNhdGVkIHVzZXIgYWZ0ZXIgcGFzc2luZw0KICAgc29tZSBhY2Nlc3MgY29udHJvbCBtZWNo YW5pc20uDQoNCiAgIEEgbG9jayAoYSBwYXJ0aWFsLWxvY2sgb3IgYSBnbG9iYWwgbG9jaykgbWln aHQgcHJldmVudCBvdGhlciB1c2Vycw0KICAgZnJvbSBjb25maWd1cmluZyB0aGUgc3lzdGVtLiAg VGhlIGZvbGxvd2luZyBtZWNoYW5pc21zIGFyZSBpbiBwbGFjZQ0KICAgdG8gcHJldmVudCB0aGUg bWlzdXNlIG9mIHRoaXMgcG9zc2liaWxpdHk6DQoNCiAgICAgIE9ubHkgYW4gYXV0aGVudGljYXRl ZCB1c2VyIGFmdGVyIHBhc3NpbmcgYWNjZXNzIGNvbnRyb2wgY2FuDQogICAgICByZXF1ZXN0IGEg cGFydGlhbC1sb2NrLg0KDQogICAgICBUaGUgcGFydGlhbC1sb2NrIGlzIGF1dG9tYXRpY2FsbHkg cmVsZWFzZWQgd2hlbiBhIHNlc3Npb24gaXMNCiAgICAgIHRlcm1pbmF0ZWQgaXJyZXNwZWN0aXZl IG9mIHRoZSBtYW5uZXIgdGhlIHNlc3Npb24gZW5kcy4NCg0KICAgICAgVGhlIDxraWxsLXNlc3Np b24+IG9wZXJhdGlvbiBhbGxvd3MgdGVybWluYXRpbmcgb3RoZXIgdXNlcnMNCiAgICAgIHNlc3Np b25zLg0KDQogICAgICBUaGUgTkVUQ09ORiBzZXJ2ZXIgbWF5IGxvZyBwYXJ0aWFsLWxvY2sgcmVx dWVzdHMgaW4gYW4gYXVkaXQNCiAgICAgIHRyYWlsLg0KDQoNCg0KICAgQSBsb2NrIHRoYXQgaXMg aGFuZ2luZyBmb3IgYW55IHJlYXNvbiwgZS5nLiBhIGJyb2tlbiBUQ1AgY29ubmVjdGlvbg0KICAg dGhhdCB0aGUgc2VydmVyIGhhcyBub3QgeWV0IHJlY29nbmlzZWQsIGNhbiBiZSByZWxlYXNlZCBm cm9tIGFub3RoZXINCiAgIE5FVENPTkYgc2Vzc2lvbiBieSBleHBsaWNpdGx5IGtpbGxpbmcgdGhl IHNlc3Npb24gb3duaW5nIHRoYXQgbG9jaw0KICAgdXNpbmcgdGhlIDxraWxsPiBvcGVyYXRpb24u DQoNCiAgIFBhcnRpYWwgbG9ja2luZyBpcyBOT1QgYW4gYXV0aG9yaXphdGlvbiBtZWNoYW5pc20s IGl0IHNob3VsZCBub3QgYmUNCiAgIHVzZWQgdG8gcHJvdmlkZSBzZWN1cml0eSBvciBhY2Nlc3Mg Y29udHJvbC4gIFBhcnRpYWwgbG9ja2luZyBzaG91bGQNCiAgIG9ubHkgYmUgdXNlZCBhcyBhIG1l Y2hhbmlzbSB0byBwcm92aWRlIGNvbnNpc3RlbmN5IGluIGNhc2Ugb2YNCiAgIG11bHRpcGxlIG1h bmFnZXJzIHRyeWluZyB0byBjb25maWd1cmUgdGhlIG5vZGUuICBJdCBpcyB2aXRhbCB0aGF0IHRo ZQ0KICAgb3BlcmF0b3IgY2FuIGVhc2lseSB1bmRlcnN0YW5kIHRoZSBleGFjdCBzY29wZSBvZiBh IGxvY2ssIGZvciB0aGlzDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBN YXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAw OA0KDQoNCiAgIHJlYXNvbiB0aGUgc2NvcGUgaXMgZGV0ZXJtaW5lZCB3aGVuIGdyYW50aW5nIGEg bG9jayBhbmQgaXMgbm90DQogICBtb2RpZmllZCBkeW5hbWljYWxseSBsYXRlci4NCg0KDQo0LiAg SUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0d28gVVJJ cyBmb3IgdGhlIE5FVENPTkYgWE1MIG5hbWVzcGFjZSBpbiB0aGUNCiAgIElFVEYgWE1MIHJlZ2lz dHJ5IFtSRkMzNjg4XS4gIE5vdGUgdGhhdCB0aGUgY2FwYWJpbGl0eSBVUk4gaXMNCiAgIGNvbXBs aWFudCB0byBbTkVUQ09ORl0gc2VjdGlvbiAxMC4zLg0KDQogICArLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwg SW5kZXggICAgICAgICB8IENhcGFiaWxpdHkgSWRlbnRpZmllciAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8IDpwYXJ0aWFsLWxvY2sgfCB1cm46aWV0 ZjpwYXJhbXM6bmV0Y29uZjpjYXBhYmlsaXR5OnBhcnRpYWwtbG9jazoxIHwNCiAgIHwgICAgICAg ICAgICAgICB8IC4wICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgIFVSSTogdXJuOmlldGY6cGFyYW1zOnhtbDpuczpu ZXRjb25mOnBhcnRpYWwtbG9jazoxLjANCg0KICAgUmVnaXN0cmFudCBDb250YWN0OiBUaGUgSUVT Ry4NCg0KICAgWE1MOiBOL0EsIHRoZSByZXF1ZXN0ZWQgVVJJIGlzIGFuIFhNTCBuYW1lc3BhY2Uu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAg ICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2Nr IFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo1LiAgQXBwZW5kaXgg QSAgLSAgWE1MIFNjaGVtYSBmb3IgUGFydGlhbCBMb2NraW5nICAobm9ybWF0aXZlKQ0KDQogICBU aGUgZm9sbG93aW5nIFhNTCBTY2hlbWEgZGVmaW5lcyB0aGUgPHBhcnRpYWwtbG9jaz4gYW5kIDxw YXJ0aWFsLQ0KICAgdW5sb2NrPiBvcGVyYXRpb25zOg0KDQogPD94bWwgdmVyc2lvbj0iMS4wIiBl bmNvZGluZz0iVVRGLTgiPz4NCiA8eHM6c2NoZW1hIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9y Zy8yMDAxL1hNTFNjaGVtYSINCiAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNv bmY6cGFydGlhbC1sb2NrOjEuMCINCiAgIHhtbG5zOm5jPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAiDQogICB0YXJnZXROYW1lc3BhY2U9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpwYXJ0aWFsLWxvY2s6MS4wIg0KICAgZWxlbWVudEZvcm1EZWZhdWx0PSJx dWFsaWZpZWQiIGF0dHJpYnV0ZUZvcm1EZWZhdWx0PSJ1bnF1YWxpZmllZCI+DQoNCiAgIDx4czph bm5vdGF0aW9uPg0KICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgIFNjaGVtYSBkZWZp bmluZyB0aGUgcGFydGlhbC1sb2NrIGFuZCB1bmxvY2sgb3BlcmF0aW9ucy4NCiAgICAgICAgIG9y Z2FuaXphdGlvbiAiSUVURiBORVRDT05GIFdvcmtpbmcgR3JvdXAiDQogICAgICAgICBjb250YWN0 DQogICAgICAgICAgICAgIkJhbGF6cyBMZW5neWVsDQogICAgICAgICAgICAgIEVyaWNzc29uIEh1 bmdhcnksIEluYy4NCiAgICAgICAgICAgICAgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIg0K ICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAgPC94czphbm5vdGF0aW9uPg0KDQogICA8eHM6 aW1wb3J0IG5hbWVzcGFjZT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4w Ig0KICAgICBzY2hlbWFMb2NhdGlvbj0ibmV0Y29uZi54c2QiLz4NCg0KICAgPHhzOmNvbXBsZXhU eXBlIG5hbWU9InBhcnRpYWxMb2NrVHlwZSI+DQogICAgIDx4czphbm5vdGF0aW9uPg0KICAgICAg IDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAgICAgQSBORVRDT05GIG9wZXJhdGlvbiB0aGF0IGxv Y2tzIHBhcnQgb2YgYSBkYXRhc3RvcmUuDQogICAgICAgPC94czpkb2N1bWVudGF0aW9uPg0KICAg ICA8L3hzOmFubm90YXRpb24+DQogICAgIDx4czpjb21wbGV4Q29udGVudD4NCiAgICAgICA8eHM6 ZXh0ZW5zaW9uIGJhc2U9Im5jOnJwY09wZXJhdGlvblR5cGUiPg0KICAgICAgICAgPHhzOnNlcXVl bmNlPg0KICAgICAgICAgICA8eHM6ZWxlbWVudCByZWY9Im5jOnJwY09wZXJhdGlvblRhcmdldFR5 cGUiLz4NCiAgICAgICAgICAgPHhzOmVsZW1lbnQgbmFtZT0ic2VsZWN0IiB0eXBlPSJ4czpzdHJp bmciDQogICAgICAgICAgICAgbWF4T2NjdXJzPSJ1bmJvdW5kZWQiPg0KICAgICAgICAgICAgIDx4 czphbm5vdGF0aW9uPg0KICAgICAgICAgICAgICAgPHhzOmRvY3VtZW50YXRpb24+DQogICAgICAg ICAgICAgICAgIFhQYXRoIGV4cHJlc3Npb24gdGhhdCBzcGVjaWZpZXMgdGhlIHNjb3BlIG9mIHRo ZSBsb2NrLg0KICAgICAgICAgICAgICAgICBBbiBJbnN0YW5jZSBJZGVudGlmaWVyIGV4cHJlc3Np b24gbXVzdCBiZSB1c2VkIHVubGVzcw0KICAgICAgICAgICAgICAgICB0aGUgOnhwYXRoIGNhcGFi aWxpdHkgaXMgc3VwcG9ydGVkIGluIHdoaWNoIGNhc2UgYW55DQogICAgICAgICAgICAgICAgIFhQ YXRoIDEuMCBleHByZXNzaW9uIGlzIGFsbG93ZWQuDQogICAgICAgICAgICAgICA8L3hzOmRvY3Vt ZW50YXRpb24+DQogICAgICAgICAgICAgPC94czphbm5vdGF0aW9uPg0KICAgICAgICAgICA8L3hz OmVsZW1lbnQ+DQogICAgICAgICA8L3hzOnNlcXVlbmNlPg0KDQoNCg0KTGVuZ3llbCAmIEJqb3Jr bHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMTJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAg ICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQogICAgICAgPC94czpleHRlbnNpb24+DQogICAgIDwv eHM6Y29tcGxleENvbnRlbnQ+DQogICA8L3hzOmNvbXBsZXhUeXBlPg0KDQogICA8eHM6Y29tcGxl eFR5cGUgbmFtZT0icGFydGlhbFVuTG9ja1R5cGUiPg0KICAgICA8eHM6YW5ub3RhdGlvbj4NCiAg ICAgICA8eHM6ZG9jdW1lbnRhdGlvbj4NCiAgICAgICAgIEEgTkVUQ09ORiBvcGVyYXRpb24gdGhh dCByZWxlYXNlcyBhIHByZXZpb3VzbHkgYWNxdWlyZWQNCiAgICAgICAgIHBhcnRpYWwtbG9jay4N CiAgICAgICA8L3hzOmRvY3VtZW50YXRpb24+DQogICAgIDwveHM6YW5ub3RhdGlvbj4NCiAgICAg PHhzOmNvbXBsZXhDb250ZW50Pg0KICAgICAgIDx4czpleHRlbnNpb24gYmFzZT0ibmM6cnBjT3Bl cmF0aW9uVHlwZSI+DQogICAgICAgICA8eHM6c2VxdWVuY2U+DQogICAgICAgICAgIDx4czplbGVt ZW50IG5hbWU9ImxvY2staWQiIHR5cGU9InhzOnVuc2lnbmVkSW50Ij4NCiAgICAgICAgICAgICA8 eHM6YW5ub3RhdGlvbj4NCiAgICAgICAgICAgICAgIDx4czpkb2N1bWVudGF0aW9uPg0KICAgICAg ICAgICAgICAgICBJZGVudGlmaWVzIHRoZSBsb2NrIHRvIGJlIHJlbGVhc2VkLiBNdXN0IGJlIHRo ZSB2YWx1ZQ0KICAgICAgICAgICAgICAgICByZWNlaXZlZCBpbiB0aGUgcmVzcG9uc2UgdG8gdGhl IHBhcnRpYWwtbG9jayBvcGVyYXRpb24uDQogICAgICAgICAgICAgICA8L3hzOmRvY3VtZW50YXRp b24+DQogICAgICAgICAgICAgPC94czphbm5vdGF0aW9uPg0KICAgICAgICAgICA8L3hzOmVsZW1l bnQ+DQogICAgICAgICA8L3hzOnNlcXVlbmNlPg0KICAgICAgIDwveHM6ZXh0ZW5zaW9uPg0KICAg ICA8L3hzOmNvbXBsZXhDb250ZW50Pg0KICAgPC94czpjb21wbGV4VHlwZT4NCg0KICAgPCEtLSA8 cGFydGlhbC1sb2NrPiBvcGVyYXRpb24gLS0+DQogICA8eHM6ZWxlbWVudCBuYW1lPSJwYXJ0aWFs LWxvY2siIHR5cGU9InBhcnRpYWxMb2NrVHlwZSINCiAgICAgICAgICAgICAgIHN1YnN0aXR1dGlv bkdyb3VwPSJuYzpycGNPcGVyYXRpb24iLz4NCg0KICAgPCEtLSA8cGFydGlhbC11bmxvY2s+IG9w ZXJhdGlvbiAtLT4NCiAgIDx4czplbGVtZW50IG5hbWU9InBhcnRpYWwtdW5sb2NrIiB0eXBlPSJw YXJ0aWFsVW5Mb2NrVHlwZSINCiAgICAgICAgICAgICAgIHN1YnN0aXR1dGlvbkdyb3VwPSJuYzpy cGNPcGVyYXRpb24iLz4NCg0KICAgPCEtLSByZXBseSB0byA8cGFydGlhbC1sb2NrPiAtLT4NCiAg IDx4czplbGVtZW50IG5hbWU9ImxvY2staWQiIHR5cGU9InhzOnVuc2lnbmVkSW50Ii8+DQoNCiA8 L3hzOnNjaGVtYT4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkxlbmd5ZWwgJiBCam9ya2x1bmQg ICAgICBFeHBpcmVzIE1hcmNoIDEyLCAyMDA5ICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgIFBhcnRpYWwgTG9jayBSUEMgZm9yIE5FVENPTkYgICAgICAg IFNlcHRlbWJlciAyMDA4DQoNCg0KNi4gIEFwcGVuZGl4IEIgIC0gWUFORyBNb2R1bGUgZm9yIFBh cnRpYWwgTG9ja2luZyAobm9uLW5vcm1hdGl2ZSkNCg0KICAgVGhlIGZvbGxvd2luZyBZQU5HIG1v ZHVsZSBkZWZpbmVzIHRoZSA8cGFydGlhbC1sb2NrPiBhbmQgPHBhcnRpYWwtDQogICB1bmxvY2s+ IG9wZXJhdGlvbnMuICBUaGUgWUFORyBsYW5ndWFnZSBpcyBkZWZpbmVkIGluDQogICBbSS1ELmll dGYtbmV0bW9kLXlhbmddLg0KDQogIG1vZHVsZSBuZXRjb25mLXBhcnRpYWwtbG9jayB7DQoNCiAg ICBuYW1lc3BhY2UgdXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOnBhcnRpYWwtbG9jazox LjA7DQogICAgcHJlZml4IHBsOw0KDQogICAgb3JnYW5pemF0aW9uICJJRVRGIE5FVENPTkYgV29y a2luZyBHcm91cCI7DQoNCiAgICBjb250YWN0DQogICAgICAiQmFsYXpzIExlbmd5ZWwNCiAgICAg ICBFcmljc3NvbiBIdW5nYXJ5LCBJbmMuDQogICAgICAgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24u Y29tIjsNCg0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiVGhpcyBZQU5HIG1vZHVsZSBkZWZpbmVz IHRoZSA8cGFydGlhbC1sb2NrPiBhbmQNCiAgICAgICA8cGFydGlhbC11bmxvY2s+IG9wZXJhdGlv bnMuIjsNCg0KICAgIHJldmlzaW9uIDIwMDgtMDYtMDYgew0KICAgICAgZGVzY3JpcHRpb24gIklu aXRpYWwgdmVyc2lvbi4iOw0KICAgIH0NCg0KICAgIGdyb3VwaW5nIGNvbmZpZ05hbWUgew0KICAg ICAgY29udGFpbmVyIHRhcmdldCB7DQogICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgIkEgY2hvaWNlIHRvIGxpc3QgdGhlIGRhdGFzdG9yZSBuYW1lcyBmb3IgTkVUQ09ORi4iOw0K ICAgICAgICAgIGNob2ljZSBjb25maWdOYW1lVHlwZSB7DQogICAgICAgICAgICBsZWFmIHJ1bm5p bmcgICB7IHR5cGUgZW1wdHk7IH0NCiAgICAgICAgICAgIGxlYWYgY2FuZGlkYXRlIHsgdHlwZSBl bXB0eTsgfQ0KICAgICAgICAgICAgbGVhZiBzdGFydHVwICAgeyB0eXBlIGVtcHR5OyB9DQogICAg ICAgICAgfQ0KICAgICAgIH0NCiAgICB9DQoNCiAgICBycGMgcGFydGlhbC1sb2NrIHsNCiAgICAg IGRlc2NyaXB0aW9uICJBIE5FVENPTkYgb3BlcmF0aW9uIHRoYXQgbG9ja3MgcGFydCBvZiBhIGRh dGFzdG9yZS4iOw0KICAgICAgaW5wdXQgew0KICAgICAgICB1c2VzIGNvbmZpZ05hbWU7DQogICAg ICAgIGxlYWYtbGlzdCBzZWxlY3Qgew0KICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAg ICAiWFBhdGggZXhwcmVzc2lvbiB0aGF0IHNwZWNpZmllcyB0aGUgc2NvcGUgb2YgdGhlIGxvY2su DQogICAgICAgICAgICBBbiBJbnN0YW5jZSBJZGVudGlmaWVyIGV4cHJlc3Npb24gbXVzdCBiZSB1 c2VkIHVubGVzcyB0aGUNCiAgICAgICAgICAgIDp4cGF0aCBjYXBhYmlsaXR5IGlzIHN1cHBvcnRl ZCBpbiB3aGljaCBjYXNlIGFueSBYUGF0aCAxLjANCiAgICAgICAgICAgIGV4cHJlc3Npb24gaXMg YWxsb3dlZC4iOw0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2gg MTIsIDIwMDkgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgUGFydGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0K DQogICAgICAgICAgdHlwZSBzdHJpbmc7DQogICAgICAgICAgbWluLWVsZW1lbnRzIDE7DQogICAg ICAgIH0NCiAgICAgIH0NCiAgICAgIG91dHB1dCB7DQogICAgICAgIGxlYWYgbG9jay1pZCB7DQog ICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBsb2NrLCBp ZiBncmFudGVkLiBUaGUgbG9jay1pZCBtdXN0IGJlDQogICAgICAgICAgICAgdXNlZCBpbiB0aGUg cGFydGlhbC11bmxvY2sgcnBjLiI7DQogICAgICAgICAgdHlwZSB1aW50MzI7DQogICAgICAgIH0N CiAgICAgICAgbGVhZi1saXN0IGxvY2tlZC1ub2RlIHsNCiAgICAgICAgICAgIGRlc2NyaXB0aW9u ICJMaXN0IG9mIGxvY2tlZC1ub2RlcyI7DQogICAgICAgICAgICB0eXBlIGluc3RhbmNlLWlkZW50 aWZpZXI7DQogICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQoNCiAgICBycGMgcGFydGlhbC11bmxv Y2sgew0KICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgIkEgTkVUQ09ORiBvcGVyYXRpb24gdGhh dCByZWxlYXNlcyBhIHByZXZpb3VzbHkgYWNxdWlyZWQNCiAgICAgICAgcGFydGlhbC1sb2NrLiI7 DQogICAgICBpbnB1dCB7DQogICAgICAgIGxlYWYgbG9jay1pZCB7DQogICAgICAgICAgZGVzY3Jp cHRpb24NCiAgICAgICAgICAgICJJZGVudGlmaWVzIHRoZSBsb2NrIHRvIGJlIHJlbGVhc2VkLiBN dXN0IGJlIHRoZSB2YWx1ZQ0KICAgICAgICAgICAgcmVjZWl2ZWQgaW4gdGhlIHJlc3BvbnNlIHRv IHRoZSBwYXJ0aWFsLWxvY2sgb3BlcmF0aW9uLiI7DQogICAgICAgICAgdHlwZSB1aW50MzI7DQog ICAgICAgIH0NCiAgICAgIH0NCiAgICB9DQogIH0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIw MDkgICAgICAgICAgICAgICAgW1BhZ2UgMTVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFy dGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo3LiAg QXBwZW5kaXggQyAgLSAgQ2hhbmdlIExvZw0KDQo3LjEuICAwMy0wNA0KDQogICBNaW5vciBjbGFy aWZpY2F0aW9ucw0KDQogICBBZGRlZCBsaXN0IG9mIGxvY2tlZC1ub2RlcyB0byB0aGUgb3V0cHV0 IG9mIHBhcnRpYWwtbG9jay4NCg0KICAgQWRkZWQgPHRhcmdldD4gd3JhcHBlciBhcm91bmQgZGF0 YXN0b3JlIG5hbWUuDQoNCjcuMi4gIDAyLTAzDQoNCiAgIE1pbm9yIGNsYXJpZmljYXRpb25zDQoN CiAgIFNhbWUgZGVzY3JpcHRpb25zIGluIFhTRCBhbmQgWUFORy4NCg0KNy4zLiAgMDEtMDINCg0K ICAgTWFkZSBYU0Qgbm9ybWF0aXZlDQoNCiAgIENsYXJpZmllZCB0aGF0IG5vIHNwZWNpZmljIGFj Y2VzcyBjb250cm9sIGlzIGFzc3VtZWQuDQoNCiAgIENsYXJpZmllZCB0aGF0IG5vbi1leGlzdGlu ZyBub2RlcyBhcmUgTk9UIGNvdmVyZWQgYnkgdGhlIGxvY2ssIGV2ZW4NCiAgIGlmIHRoZXkgd2hl cmUgZXhpc3RpbmcgYW5kIGNvdmVyZWQgYnkgdGhlIGxvY2sgd2hlbiBpdCB3YXMgb3JpZ2luYWxs eQ0KICAgZ3JhbnRlZC4NCg0KICAgU29tZSByZXdvcmRpbmcNCg0KICAgQWRkZWQgYXBwLXRhZ3Mg Zm9yIHR3byBvZiB0aGUgZXJyb3IgY2FzZXMuDQoNCiAgIE1hZGUgWUFORyBhbiBpbmZvcm1hdGl2 ZSByZWZlcmVuY2UNCg0KICAgRW5oYW5jZWQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCjcu NC4gIDAwLTAxDQoNCiAgIEFkZGVkIFlBTkcgbW9kdWxlLg0KDQo3LjUuICAtMDANCg0KICAgQ3Jl YXRlZCBmcm9tIGRyYWZ0LWxlbmd5ZWwtbmdvLXBhcnRpYWwtbG9jay0wMS50eHQNCg0KDQoNCg0K DQoNCg0KDQoNCg0KTGVuZ3llbCAmIEJqb3JrbHVuZCAgICAgIEV4cGlyZXMgTWFyY2ggMTIsIDIw MDkgICAgICAgICAgICAgICAgW1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUGFy dGlhbCBMb2NrIFJQQyBmb3IgTkVUQ09ORiAgICAgICAgU2VwdGVtYmVyIDIwMDgNCg0KDQo4LiAg QWNrbm93bGVkZ2VtZW50cw0KDQogICBUaGFua3MgdG8gQW5keSBCaWVybWFuLCBTaGFyb24gQ2hp c2hvbG0sIFBoaWwgU2hhZmVyICwgRGF2aWQNCiAgIEhhcnJpbmd0b24sIE1laG1ldCBFcnN1ZSBh bmQgbWFueSBvdGhlciBtZW1iZXJzIG9mIHRoZSBORVRDT05GIFdHIGZvcg0KICAgcHJvdmlkaW5n IGltcG9ydGFudCBpbnB1dCB0byB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwg MjAwOSAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQ YXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCjku ICBSZWZlcmVuY2VzDQoNCjkuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFtORVRDT05G XSAgRW5ucywgUi4sICJORVRDT05GIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wiLCBSRkMgNDc0MSwN CiAgICAgICAgICAgICAgRGVjZW1iZXIgMjAwNi4NCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBT LiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAg UmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAg W1JGQzM2ODhdICBNZWFsbGluZywgTS4sICJUaGUgSUVURiBYTUwgUmVnaXN0cnkiLCBCQ1AgODEs IFJGQyAzNjg4LA0KICAgICAgICAgICAgICBKYW51YXJ5IDIwMDQuDQoNCjkuMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMNCg0KICAgW0ktRC5pZXRmLW5ldG1vZC15YW5nXQ0KICAgICAgICAgICAg ICBCam9ya2x1bmQsIE0uLCAiWUFORyAtIEEgZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBmb3INCiAg ICAgICAgICAgICAgTkVUQ09ORiIsIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctMDAgKHdvcmsgaW4g cHJvZ3Jlc3MpLA0KICAgICAgICAgICAgICBNYXkgMjAwOC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5neWVsICYgQmpv cmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAgICBbUGFnZSAx OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZvciBORVRDT05G ICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBCYWxh enMgTGVuZ3llbA0KICAgRXJpY3Nzb24gSHVuZ2FyeQ0KDQogICBFbWFpbDogYmFsYXpzLmxlbmd5 ZWxAZXJpY3Nzb24uY29tDQoNCg0KICAgTWFydGluIEJqb3JrbHVuZA0KICAgVGFpbC1mIFN5c3Rl bXMNCg0KICAgRW1haWw6IG1iakB0YWlsLWYuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpMZW5n eWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAgICAgICAgICAg ICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQYXJ0aWFsIExvY2sgUlBDIGZv ciBORVRDT05GICAgICAgICBTZXB0ZW1iZXIgMjAwOA0KDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRl bWVudA0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJRVRGIFRydXN0ICgyMDA4KS4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmlj dGlvbnMNCiAgIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZCBleGNlcHQgYXMgc2V0IGZvcnRoIHRo ZXJlaW4sIHRoZSBhdXRob3JzDQogICByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KICAgVGhp cyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3Zp ZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdB TklaQVRJT04gSEUvU0hFIFJFUFJFU0VOVFMNCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5Z KSwgVEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0KICAgVEhFIElOVEVS TkVUIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJF U1MNCiAgIE9SIElNUExJRUQsIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJB TlRZIFRIQVQgVEhFIFVTRSBPRg0KICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJ TkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNI QU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRl bGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJk aW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0 eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2Ny aWJlZCBpbg0KICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNl bnNlIHVuZGVyIHN1Y2ggcmlnaHRzDQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxl OyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5k ZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAg b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRz IGNhbiBiZQ0KICAgZm91bmQgaW4gQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJ UFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBh c3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0 IG9mIGFuDQogICBhdHRlbXB0IG1hZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBl cm1pc3Npb24gZm9yIHRoZSB1c2Ugb2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGlt cGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRh aW5lZCBmcm9tIHRoZSBJRVRGIG9uLWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaXByLg0KDQogICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBh cnR5IHRvIGJyaW5nIHRvIGl0cyBhdHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRz IG9yIHBhdGVudCBhcHBsaWNhdGlvbnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMg dGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1l bnQNCiAgIHRoaXMgc3RhbmRhcmQuICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8g dGhlIElFVEYgYXQNCiAgIGlldGYtaXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdtZW50DQoN CiAgIEZ1bmRpbmcgZm9yIHRoZSBSRkMgRWRpdG9yIGZ1bmN0aW9uIGlzIHByb3ZpZGVkIGJ5IHRo ZSBJRVRGDQogICBBZG1pbmlzdHJhdGl2ZSBTdXBwb3J0IEFjdGl2aXR5IChJQVNBKS4NCg0KDQoN Cg0KDQpMZW5neWVsICYgQmpvcmtsdW5kICAgICAgRXhwaXJlcyBNYXJjaCAxMiwgMjAwOSAgICAg ICAgICAgICAgICBbUGFnZSAyMF0NCgwNCg0K ------_=_NextPart_001_01C91270.4668D332 Content-Type: text/plain; name="ATT5860428.txt" Content-Transfer-Encoding: base64 Content-Description: ATT5860428.txt Content-Disposition: attachment; filename="ATT5860428.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== ------_=_NextPart_001_01C91270.4668D332 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_01C91270.4668D332-- From netconf-bounces@ietf.org Tue Sep 9 06:29:44 2008 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 D8B963A6B71; Tue, 9 Sep 2008 06:29:44 -0700 (PDT) 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 B50133A6864 for ; Tue, 9 Sep 2008 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ZF8LNPoUAyxn for ; Tue, 9 Sep 2008 06:29:42 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3C2CE3A6B33 for ; Tue, 9 Sep 2008 06:29:42 -0700 (PDT) Received: (qmail 14663 invoked from network); 9 Sep 2008 13:29:45 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Sep 2008 13:29:45 -0000 Message-ID: <7DE48FCA5F5E4677B485478DDDADC5E0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Martin Bjorklund" References: <48C63F1A.8070906@ericsson.com><48C65520.3040609@ericsson.com> <20080909.131825.211162657.mbj@tail-f.com> In-Reply-To: <20080909.131825.211162657.mbj@tail-f.com> Date: Tue, 9 Sep 2008 15:29:04 +0200 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 Cc: netconf@ietf.org Subject: Re: [Netconf] evaluation of the partial-lock document 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 Inline ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Tuesday, September 09, 2008 1:18 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Balazs Lengyel wrote: >> Hello Bert, >> I could add something like: >> >> Existing: >> >> >> NEW: >> > > Or rather NEW: > > > > > > Maybe that's what you meant. > More somtething like that, indeed. That still does not show that there could be multiple nodes though >> but locked-node will not appear anywhere else in the XSD (lock-id >> does). This would not even show that lock-id is included once while >> locked-node can be included multiple times. > > This is just how XSD works (you could argue that rfc4741 should have > used a substitutionGroup for the reply as well. but it didn't). > :-) Bert > > /martin > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailmaFrom netconf-bounces@ietf.org Tue Sep 9 06:29:44 2008 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 D8B963A6B71; Tue, 9 Sep 2008 06:29:44 -0700 (PDT) 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 B50133A6864 for ; Tue, 9 Sep 2008 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.710, BAYES_00=-2.599, STOX_REPLY_TYPE=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 ZF8LNPoUAyxn for ; Tue, 9 Sep 2008 06:29:42 -0700 (PDT) Received: from relay.versatel.net (relay.versatel.net [62.250.3.110]) by core3.amsl.com (Postfix) with SMTP id 3C2CE3A6B33 for ; Tue, 9 Sep 2008 06:29:42 -0700 (PDT) Received: (qmail 14663 invoked from network); 9 Sep 2008 13:29:45 -0000 Received: from unknown (HELO BertLaptop) (87.215.199.34) by relay.versatel.net with SMTP; 9 Sep 2008 13:29:45 -0000 Message-ID: <7DE48FCA5F5E4677B485478DDDADC5E0@BertLaptop> From: "Bert Wijnen \(IETF\)" To: , "Martin Bjorklund" References: <48C63F1A.8070906@ericsson.com><48C65520.3040609@ericsson.com> <20080909.131825.211162657.mbj@tail-f.com> In-Reply-To: <20080909.131825.211162657.mbj@tail-f.com> Date: Tue, 9 Sep 2008 15:29:04 +0200 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 Cc: netconf@ietf.org Subject: Re: [Netconf] evaluation of the partial-lock document 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 Inline ----- Original Message ----- From: "Martin Bjorklund" To: Cc: ; Sent: Tuesday, September 09, 2008 1:18 PM Subject: Re: [Netconf] evaluation of the partial-lock document > Balazs Lengyel wrote: >> Hello Bert, >> I could add something like: >> >> Existing: >> >> >> NEW: >> > > Or rather NEW: > > > > > > Maybe that's what you meant. > More somtething like that, indeed. That still does not show that there could be multiple nodes though >> but locked-node will not appear anywhere else in the XSD (lock-id >> does). This would not even show that lock-id is included once while >> locked-node can be included multiple times. > > This is just how XSD works (you could argue that rfc4741 should have > used a substitutionGroup for the reply as well. but it didn't). > :-) Bert > > /martin > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/n/listinfo/netconf mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 12:21:23 2008 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 D6CFC3A69DC; Thu, 11 Sep 2008 12:21:23 -0700 (PDT) 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 8703C3A6856 for ; Thu, 11 Sep 2008 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=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 AAQ1WeESLCnu for ; Thu, 11 Sep 2008 12:21:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E00F13A6930 for ; Thu, 11 Sep 2008 12:21:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5F4CC00A9 for ; Thu, 11 Sep 2008 21:21:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7yHlikn3Tr+G; Thu, 11 Sep 2008 21:21:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 054E6C00A2; Thu, 11 Sep 2008 21:21:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 076416C6686; Thu, 11 Sep 2008 21:21:16 +0200 (CEST) Date: Thu, 11 Sep 2008 21:21:16 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080911192116.GA3099@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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 Hi, this might be interesting to look at and to keep an eye on. /js ----- Forwarded message from rfc-editor@rfc-editor.org ----- Delivered-To: ietf-announce@core3.amsl.com To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors From: rfc-editor@rfc-editor.org Date: Thu, 11 Sep 2008 11:57:10 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 5261 Title: An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author: J. Urpalainen Status: Standards Track Date: September 2008 Mailbox: jari.urpalainen@nokia.com Pages: 40 Characters: 78036 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xml-patch-ops-04.txt URL: http://www.rfc-editor.org/rfc/rfc5261.txt Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , , and directives a set of patches can then be applied to update an existing XML document. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 12:21:23 2008 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 D6CFC3A69DC; Thu, 11 Sep 2008 12:21:23 -0700 (PDT) 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 8703C3A6856 for ; Thu, 11 Sep 2008 12:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_93=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 AAQ1WeESLCnu for ; Thu, 11 Sep 2008 12:21:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E00F13A6930 for ; Thu, 11 Sep 2008 12:21:18 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E5F4CC00A9 for ; Thu, 11 Sep 2008 21:21:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7yHlikn3Tr+G; Thu, 11 Sep 2008 21:21:18 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 054E6C00A2; Thu, 11 Sep 2008 21:21:18 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 076416C6686; Thu, 11 Sep 2008 21:21:16 +0200 (CEST) Date: Thu, 11 Sep 2008 21:21:16 +0200 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20080911192116.GA3099@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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 Hi, this might be interesting to look at and to keep an eye on. /js ----- Forwarded message from rfc-editor@rfc-editor.org ----- Delivered-To: ietf-announce@core3.amsl.com To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors From: rfc-editor@rfc-editor.org Date: Thu, 11 Sep 2008 11:57:10 -0700 (PDT) Cc: simple@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 5261 Title: An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors Author: J. Urpalainen Status: Standards Track Date: September 2008 Mailbox: jari.urpalainen@nokia.com Pages: 40 Characters: 78036 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-xml-patch-ops-04.txt URL: http://www.rfc-editor.org/rfc/rfc5261.txt Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. In order to send changes to an XML document, an entire copy of the new version must be sent, unless there is a means of indicating only the portions that have changed. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. In addition to them, with basic , , and directives a set of patches can then be applied to update an existing XML document. [STANDARDS TRACK] This document is a product of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ----- End forwarded message ----- _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 13:06:58 2008 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 C29B128C106; Thu, 11 Sep 2008 13:06:58 -0700 (PDT) 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 A6F5B28C106 for ; Thu, 11 Sep 2008 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVdPRgvjdA97 for ; Thu, 11 Sep 2008 13:06:56 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 48C213A69DC for ; Thu, 11 Sep 2008 13:06:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 13:07:01 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BK6QM04921; Thu, 11 Sep 2008 13:06:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BK2acX062241; Thu, 11 Sep 2008 20:02:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809112002.m8BK2acX062241@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080911192116.GA3099@elstar.local> Date: Thu, 11 Sep 2008 16:02:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 20:06:27.0210 (UTC) FILETIME=[DF86EEA0:01C91449] Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >this might be interesting to look at and to keep an eye on. It's interesting, but seems like a draft, not an rfc. Section 4.1 says they use "a restricted subset of the full XPath 2.0 recommendation", but it isn't explicit about what that subset is. The node step doesn't mention axis or prefix notations and no limitation is put on predicates. The "namespace" in 4.2.1 is "foo:", which works but is very confusing. And 4.2.2 says: In contrast, in this specification, a selector without a prefix only matches one element, and it may match an element with or without a prefix but only if the namespace it's qualified with (or none) is an exact match. From netconf-bounces@ietf.org Thu Sep 11 13:06:58 2008 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 C29B128C106; Thu, 11 Sep 2008 13:06:58 -0700 (PDT) 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 A6F5B28C106 for ; Thu, 11 Sep 2008 13:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVdPRgvjdA97 for ; Thu, 11 Sep 2008 13:06:56 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 48C213A69DC for ; Thu, 11 Sep 2008 13:06:54 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP; Thu, 11 Sep 2008 13:07:01 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 13:06:27 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8BK6QM04921; Thu, 11 Sep 2008 13:06:26 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8BK2acX062241; Thu, 11 Sep 2008 20:02:36 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809112002.m8BK2acX062241@idle.juniper.net> To: j.schoenwaelder@jacobs-university.de In-reply-to: <20080911192116.GA3099@elstar.local> Date: Thu, 11 Sep 2008 16:02:35 -0400 From: Phil Shafer X-OriginalArrivalTime: 11 Sep 2008 20:06:27.0210 (UTC) FILETIME=[DF86EEA0:01C91449] Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Juergen Schoenwaelder writes: >this might be interesting to look at and to keep an eye on. It's interesting, but seems like a draft, not an rfc. Section 4.1 says they use "a restricted subset of the full XPath 2.0 recommendation", but it isn't explicit about what that subset is. The node step doesn't mention axis or prefix notations and no limitation is put on predicates. The "namespace" in 4.2.1 is "foo:", which works but is very confusing. And 4.2.2 says: In contrast, in this specification, a selector without a prefix only matches one element, and it may match an element with or without a prefix but only if the namespace it's qualified with (or none) is an exact match. which which is confusing and/or inconsistent (in that normal XPath selectors match multiple elements, not just one). That said, I like the functionality, and can see a operation approaching in the distance. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf is confusing and/or inconsistent (in that normal XPath selectors match multiple elements, not just one). That said, I like the functionality, and can see a operation approaching in the distance. Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 13:26:04 2008 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 DED4B28C119; Thu, 11 Sep 2008 13:26:04 -0700 (PDT) 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 DDD6828C119 for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.696, 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 CWSO2Rcimdqq for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 30C4228C0EE for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) Received: (qmail 91215 invoked from network); 11 Sep 2008 20:26:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Sep 2008 20:26:08 -0000 X-YMail-OSG: .W4Xq1gVM1ktnHEMXfi0DfyU3nVNZCo_f1Tud9WWlxqzYpJwRclrZfIisqIzp4rcfdJtn.W.nQqwNXlltJUjEHevn_.77Z3.Vt6sLUie8AVlyRin7w3i3oDditwEcgQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C97EDF.9060809@netconfcentral.com> Date: Thu, 11 Sep 2008 13:26:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809112002.m8BK2acX062241@idle.juniper.net> In-Reply-To: <200809112002.m8BK2acX062241@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) 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 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> this might be interesting to look at and to keep an eye on. > > It's interesting, but seems like a draft, not an rfc. Section 4.1 > says they use "a restricted subset of the full XPath 2.0 recommendation", > but it isn't explicit about what that subset is. The node step > doesn't mention axis or prefix notations and no limitation is put > on predicates. The "namespace" in 4.2.1 is "foo:", which works but > is very confusing. And 4.2.2 says: > > In contrast, in this specification, a selector without > a prefix only matches one element, and it may match an element with > or without a prefix but only if the namespace it's qualified with (or > none) is an exact match. > > which is confusing and/or inconsistent (in that normal XPath selectors > match multiple elements, not just one). > > That said, I like the functionality, and can see a > operation approaching in the distance. > The idea of an XPath selector for instead of inline XML was brought up in the past, and I think a draft was published on it. NETCONF has locking, validation, rollback, and a few other things that go beyond patching an XML document, but I agree with you that an edit-config style (XPath selector + replacement XML) would be an interesting power saw. Imagine the fun debugging XPath based auto-edits :-) > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 13:26:04 2008 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 DED4B28C119; Thu, 11 Sep 2008 13:26:04 -0700 (PDT) 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 DDD6828C119 for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.696, 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 CWSO2Rcimdqq for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) Received: from smtp116.sbc.mail.sp1.yahoo.com (smtp116.sbc.mail.sp1.yahoo.com [69.147.64.89]) by core3.amsl.com (Postfix) with SMTP id 30C4228C0EE for ; Thu, 11 Sep 2008 13:26:03 -0700 (PDT) Received: (qmail 91215 invoked from network); 11 Sep 2008 20:26:10 -0000 Received: from unknown (HELO ?127.0.0.1?) (andybierman@att.net@68.120.224.76 with plain) by smtp116.sbc.mail.sp1.yahoo.com with SMTP; 11 Sep 2008 20:26:08 -0000 X-YMail-OSG: .W4Xq1gVM1ktnHEMXfi0DfyU3nVNZCo_f1Tud9WWlxqzYpJwRclrZfIisqIzp4rcfdJtn.W.nQqwNXlltJUjEHevn_.77Z3.Vt6sLUie8AVlyRin7w3i3oDditwEcgQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48C97EDF.9060809@netconfcentral.com> Date: Thu, 11 Sep 2008 13:26:07 -0700 From: Andy Bierman User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Phil Shafer References: <200809112002.m8BK2acX062241@idle.juniper.net> In-Reply-To: <200809112002.m8BK2acX062241@idle.juniper.net> Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) 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 Phil Shafer wrote: > Juergen Schoenwaelder writes: >> this might be interesting to look at and to keep an eye on. > > It's interesting, but seems like a draft, not an rfc. Section 4.1 > says they use "a restricted subset of the full XPath 2.0 recommendation", > but it isn't explicit about what that subset is. The node step > doesn't mention axis or prefix notations and no limitation is put > on predicates. The "namespace" in 4.2.1 is "foo:", which works but > is very confusing. And 4.2.2 says: > > In contrast, in this specification, a selector without > a prefix only matches one element, and it may match an element with > or without a prefix but only if the namespace it's qualified with (or > none) is an exact match. > > which is confusing and/or inconsistent (in that normal XPath selectors > match multiple elements, not just one). > > That said, I like the functionality, and can see a > operation approaching in the distance. > The idea of an XPath selector for instead of inline XML was brought up in the past, and I think a draft was published on it. NETCONF has locking, validation, rollback, and a few other things that go beyond patching an XML document, but I agree with you that an edit-config style (XPath selector + replacement XML) would be an interesting power saw. Imagine the fun debugging XPath based auto-edits :-) > Thanks, > Phil Andy _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 15:19:30 2008 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 D44FA3A68A0; Thu, 11 Sep 2008 15:19:30 -0700 (PDT) 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 893793A68A0 for ; Thu, 11 Sep 2008 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 HXa7yJEs8q-q for ; Thu, 11 Sep 2008 15:19:28 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D110E3A688C for ; Thu, 11 Sep 2008 15:19:28 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DE607399B2F; Thu, 11 Sep 2008 15:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=VZcPwAtia7HFH5p1Qe9fxMi/LjU=; b=ZDxf y8VffBSb+GpxK/sdP2xOG2xO2r1WPpClWUOVEPh4Iaus8zlWgUhxSZItHVzIs0yV hJSIuNf4NX/SODuEWiBh8Y0hX7BOrVo/TtIMujUZuqP+8c9QvoGdlRw/Mb9ml4ml MFSicGr8TufeHWMGVJ7R9R73RNMrlXuPU2zTSUw= Received: by wes.hardakers.net (Postfix, from userid 274) id BE556399B30; Thu, 11 Sep 2008 15:18:53 -0700 (PDT) From: Wes Hardaker To: Phil Shafer Organization: Sparta References: <200809112002.m8BK2acX062241@idle.juniper.net> Date: Thu, 11 Sep 2008 15:18:53 -0700 In-Reply-To: <200809112002.m8BK2acX062241@idle.juniper.net> (Phil Shafer's message of "Thu, 11 Sep 2008 16:02:35 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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 Thu, 11 Sep 2008 16:02:35 -0400, Phil Shafer said: PS> That said, I like the functionality, and can see a PS> operation approaching in the distance. I've argued before that support for something like that is a requirement for multi-operator-role environments where copy-config and global operations can too easily get "bound" because of lack of privileges. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 11 15:19:30 2008 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 D44FA3A68A0; Thu, 11 Sep 2008 15:19:30 -0700 (PDT) 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 893793A68A0 for ; Thu, 11 Sep 2008 15:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 HXa7yJEs8q-q for ; Thu, 11 Sep 2008 15:19:28 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D110E3A688C for ; Thu, 11 Sep 2008 15:19:28 -0700 (PDT) Received: from wes.hardakers.net (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id DE607399B2F; Thu, 11 Sep 2008 15:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hardakers.net; h=from:to :cc:subject:references:date:in-reply-to:message-id:mime-version: content-type; s=wesmail; bh=VZcPwAtia7HFH5p1Qe9fxMi/LjU=; b=ZDxf y8VffBSb+GpxK/sdP2xOG2xO2r1WPpClWUOVEPh4Iaus8zlWgUhxSZItHVzIs0yV hJSIuNf4NX/SODuEWiBh8Y0hX7BOrVo/TtIMujUZuqP+8c9QvoGdlRw/Mb9ml4ml MFSicGr8TufeHWMGVJ7R9R73RNMrlXuPU2zTSUw= Received: by wes.hardakers.net (Postfix, from userid 274) id BE556399B30; Thu, 11 Sep 2008 15:18:53 -0700 (PDT) From: Wes Hardaker To: Phil Shafer Organization: Sparta References: <200809112002.m8BK2acX062241@idle.juniper.net> Date: Thu, 11 Sep 2008 15:18:53 -0700 In-Reply-To: <200809112002.m8BK2acX062241@idle.juniper.net> (Phil Shafer's message of "Thu, 11 Sep 2008 16:02:35 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors] 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 Thu, 11 Sep 2008 16:02:35 -0400, Phil Shafer said: PS> That said, I like the functionality, and can see a PS> operation approaching in the distance. I've argued before that support for something like that is a requirement for multi-operator-role environments where copy-config and global operations can too easily get "bound" because of lack of privileges. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Sep 12 10:22:16 2008 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 EA2663A6B5A; Fri, 12 Sep 2008 10:22:16 -0700 (PDT) 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 D8CA33A6B5A for ; Fri, 12 Sep 2008 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXVILfYM5RzE for ; Fri, 12 Sep 2008 10:22:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C09583A6AD1 for ; Fri, 12 Sep 2008 10:22:14 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8CHMCoD017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Sep 2008 19:22:12 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8CHMCOk010490 for ; Fri, 12 Sep 2008 19:22:12 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 19:22:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 19:22:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom call for candidates Thread-Index: AckU+UNKuk2yYJDlSiO0QR9F4MbN6QAAqhEw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 12 Sep 2008 17:22:09.0531 (UTC) FILETIME=[164E3CB0:01C914FC] Subject: [Netconf] FW: Nomcom call for candidates 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 For those of you who are not subscribed on the IETF announcements list. Please consider nominating. Cheers, Mehmet -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext NomCom Chair Sent: Friday, September 12, 2008 6:48 PM To: Working Group Chairs Subject: Nomcom call for candidates The message below was just sent to the IETF-Annoucne list. However, it order to get to as many people as possible, I am asking WG chairs a favor. Please forward the message to your working groups. Thank you, Joel M. Halpern The 2008-9 IETF Nominating Committee needs your help. We have started getting candidates. If we are going to do our job in time, we have only 3 more weeks to get enough candidates to have a reasonable pool for all the jobs. At the moment, we do not have a reasonable pool for any jobs. If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. The web site at: http://wiki.tools.ietf.org/group/nomcom/08 Has the list of positions we are seeking people for, as well as tools for providing both nominations and feedback. Alternatively, you can submit nominations by sending email to me. Please help us. Thank you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Sep 12 10:22:16 2008 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 EA2663A6B5A; Fri, 12 Sep 2008 10:22:16 -0700 (PDT) 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 D8CA33A6B5A for ; Fri, 12 Sep 2008 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=2.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXVILfYM5RzE for ; Fri, 12 Sep 2008 10:22:15 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C09583A6AD1 for ; Fri, 12 Sep 2008 10:22:14 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8CHMCoD017546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Sep 2008 19:22:12 +0200 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8CHMCOk010490 for ; Fri, 12 Sep 2008 19:22:12 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Sep 2008 19:22:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Sep 2008 19:22:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Nomcom call for candidates Thread-Index: AckU+UNKuk2yYJDlSiO0QR9F4MbN6QAAqhEw From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 12 Sep 2008 17:22:09.0531 (UTC) FILETIME=[164E3CB0:01C914FC] Subject: [Netconf] FW: Nomcom call for candidates 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 For those of you who are not subscribed on the IETF announcements list. Please consider nominating. Cheers, Mehmet -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of ext NomCom Chair Sent: Friday, September 12, 2008 6:48 PM To: Working Group Chairs Subject: Nomcom call for candidates The message below was just sent to the IETF-Annoucne list. However, it order to get to as many people as possible, I am asking WG chairs a favor. Please forward the message to your working groups. Thank you, Joel M. Halpern The 2008-9 IETF Nominating Committee needs your help. We have started getting candidates. If we are going to do our job in time, we have only 3 more weeks to get enough candidates to have a reasonable pool for all the jobs. At the moment, we do not have a reasonable pool for any jobs. If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. The web site at: http://wiki.tools.ietf.org/group/nomcom/08 Has the list of positions we are seeking people for, as well as tools for providing both nominations and feedback. Alternatively, you can submit nominations by sending email to me. Please help us. Thank you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Sep 17 10:37:04 2008 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 C87003A6984; Wed, 17 Sep 2008 10:37:04 -0700 (PDT) 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 D53723A6C85 for ; Wed, 17 Sep 2008 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.996, 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 t6E5YYk-SBex for ; Wed, 17 Sep 2008 10:37:03 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id BDDA63A6C7C for ; Wed, 17 Sep 2008 10:37:02 -0700 (PDT) X-Trace: 137952717/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.81 X-SBRS: None X-RemoteIP: 213.116.52.81 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAFzd0EjVdDRR/2dsb2JhbACDRzuIQK0SA4Fk X-IronPort-AV: E=Sophos;i="4.32,416,1217804400"; d="scan'208";a="137952717" X-IP-Direction: IN Received: from 1cust81.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.81]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Sep 2008 18:37:09 +0100 Message-ID: <004f01c918e2$a1d16520$0601a8c0@allison> From: "tom.petch" To: , "Phil Shafer" , "Lada" , "Andy Bierman" References: <200809112002.m8BK2acX062241@idle.juniper.net> Date: Wed, 17 Sep 2008 18:26:46 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "Phil Shafer" To: Cc: Sent: Thursday, September 11, 2008 10:02 PM Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] > Juergen Schoenwaelder writes: > >this might be interesting to look at and to keep an eye on. > > It's interesting, but seems like a draft, not an rfc. Section 4.1 > says they use "a restricted subset of the full XPath 2.0 recommendation", errr.... I'm confused. The copy I am looking at, fresh from the rfc-editor, says "a restricted subset of the full XPath 1.0 recommendation. " I commented at IETF last call time that this I-D seemed to be specifying more like XPath 2.0 functionality in its handling of default/no namespaces, and I see that this section has since been wholy rewritten, adding a section on how this use of XPath diverges from the formal specifications:-( This is germane to the "belongs to" thread on Netmod, which touched on the 'no namespace' issue in XPath. In this thread, Lada raised the question of whether yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up. A discussion which is probably worth pursuing on netmod. Tom Petch > but it isn't explicit about what that subset is. The node step > doesn't mention axis or prefix notations and no limitation is put > on predicates. The "namespace" in 4.2.1 is "foo:", which works but > is very confusing. And 4.2.2 says: > > In contrast, in this specification, a selector without > a prefix only matches one element, and it may match an element with > or without a prefix but only if the namespace it's qualified with (or > none) is an exact match. > > which is confusing and/or inconsistent (in that normal XPath selectors > match multiple elements, not just one). > > That said, I like the functionality, and can see a > operation approaching in the distance. > > Thanks, > Phil > _______________________________________________ > 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 Sep 17 10:37:04 2008 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 C87003A6984; Wed, 17 Sep 2008 10:37:04 -0700 (PDT) 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 D53723A6C85 for ; Wed, 17 Sep 2008 10:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.996, 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 t6E5YYk-SBex for ; Wed, 17 Sep 2008 10:37:03 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id BDDA63A6C7C for ; Wed, 17 Sep 2008 10:37:02 -0700 (PDT) X-Trace: 137952717/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.52.81 X-SBRS: None X-RemoteIP: 213.116.52.81 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEAFzd0EjVdDRR/2dsb2JhbACDRzuIQK0SA4Fk X-IronPort-AV: E=Sophos;i="4.32,416,1217804400"; d="scan'208";a="137952717" X-IP-Direction: IN Received: from 1cust81.tnt102.lnd4.gbr.da.uu.net (HELO allison) ([213.116.52.81]) by smtp.pipex.tiscali.co.uk with SMTP; 17 Sep 2008 18:37:09 +0100 Message-ID: <004f01c918e2$a1d16520$0601a8c0@allison> From: "tom.petch" To: , "Phil Shafer" , "Lada" , "Andy Bierman" References: <200809112002.m8BK2acX062241@idle.juniper.net> Date: Wed, 17 Sep 2008 18:26:46 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" 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 ----- Original Message ----- From: "Phil Shafer" To: Cc: Sent: Thursday, September 11, 2008 10:02 PM Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] > Juergen Schoenwaelder writes: > >this might be interesting to look at and to keep an eye on. > > It's interesting, but seems like a draft, not an rfc. Section 4.1 > says they use "a restricted subset of the full XPath 2.0 recommendation", errr.... I'm confused. The copy I am looking at, fresh from the rfc-editor, says "a restricted subset of the full XPath 1.0 recommendation. " I commented at IETF last call time that this I-D seemed to be specifying more like XPath 2.0 functionality in its handling of default/no namespaces, and I see that this section has since been wholy rewritten, adding a section on how this use of XPath diverges from the formal specifications:-( This is germane to the "belongs to" thread on Netmod, which touched on the 'no namespace' issue in XPath. In this thread, Lada raised the question of whether yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up. A discussion which is probably worth pursuing on netmod. Tom Petch > but it isn't explicit about what that subset is. The node step > doesn't mention axis or prefix notations and no limitation is put > on predicates. The "namespace" in 4.2.1 is "foo:", which works but > is very confusing. And 4.2.2 says: > > In contrast, in this specification, a selector without > a prefix only matches one element, and it may match an element with > or without a prefix but only if the namespace it's qualified with (or > none) is an exact match. > > which is confusing and/or inconsistent (in that normal XPath selectors > match multiple elements, not just one). > > That said, I like the functionality, and can see a > operation approaching in the distance. > > Thanks, > Phil > _______________________________________________ > 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 Sep 17 11:44:13 2008 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 B88203A69B1; Wed, 17 Sep 2008 11:44:13 -0700 (PDT) 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 B026E3A695C for ; Wed, 17 Sep 2008 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gicq2xm09Mfy for ; Wed, 17 Sep 2008 11:44:11 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 1D3733A67AB for ; Wed, 17 Sep 2008 11:44:05 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Wed, 17 Sep 2008 11:44:08 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Sep 2008 11:43:08 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Sep 2008 11:43:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Sep 2008 11:43:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8HIh7M26279; Wed, 17 Sep 2008 11:43:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8HId9jx016321; Wed, 17 Sep 2008 18:39:10 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809171839.m8HId9jx016321@idle.juniper.net> To: "tom.petch" In-reply-to: <004f01c918e2$a1d16520$0601a8c0@allison> Date: Wed, 17 Sep 2008 14:39:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Sep 2008 18:43:08.0115 (UTC) FILETIME=[3A501230:01C918F5] Cc: Lada , netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "tom.petch" writes: >This is germane to the "belongs to" thread on Netmod, which touched on the 'no >namespace' issue in XPath. In this thread, Lada raised the question of whethe >r >yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up. The issue with XPath2.0 is the growth in size of the spec (6x iirc) and the lack of availability of implementations. One can wonder if the two are related ;^) Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Sep 17 11:44:13 2008 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 B88203A69B1; Wed, 17 Sep 2008 11:44:13 -0700 (PDT) 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 B026E3A695C for ; Wed, 17 Sep 2008 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gicq2xm09Mfy for ; Wed, 17 Sep 2008 11:44:11 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7ob116.obsmtp.com [64.18.2.218]) by core3.amsl.com (Postfix) with ESMTP id 1D3733A67AB for ; Wed, 17 Sep 2008 11:44:05 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP; Wed, 17 Sep 2008 11:44:08 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp01.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Sep 2008 11:43:08 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Sep 2008 11:43:08 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Sep 2008 11:43:08 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m8HIh7M26279; Wed, 17 Sep 2008 11:43:07 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id m8HId9jx016321; Wed, 17 Sep 2008 18:39:10 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200809171839.m8HId9jx016321@idle.juniper.net> To: "tom.petch" In-reply-to: <004f01c918e2$a1d16520$0601a8c0@allison> Date: Wed, 17 Sep 2008 14:39:09 -0400 From: Phil Shafer X-OriginalArrivalTime: 17 Sep 2008 18:43:08.0115 (UTC) FILETIME=[3A501230:01C918F5] Cc: Lada , netconf@ietf.org Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org "tom.petch" writes: >This is germane to the "belongs to" thread on Netmod, which touched on the 'no >namespace' issue in XPath. In this thread, Lada raised the question of whethe >r >yang should use XPath 1.0 or 2.0, a question to which I never saw a follow up. The issue with XPath2.0 is the growth in size of the spec (6x iirc) and the lack of availability of implementations. One can wonder if the two are related ;^) Thanks, Phil _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Wed Sep 17 13:41:18 2008 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 0A84E3A6840; Wed, 17 Sep 2008 13:41:18 -0700 (PDT) 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 176EF3A6892 for ; Wed, 17 Sep 2008 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66rxqEt24X2a for ; Wed, 17 Sep 2008 13:41:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 407523A6814 for ; Wed, 17 Sep 2008 13:41:15 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 873E7D800CC for ; Wed, 17 Sep 2008 22:41:28 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <200809171839.m8HId9jx016321@idle.juniper.net> References: <200809171839.m8HId9jx016321@idle.juniper.net> Organization: CESNET Date: Wed, 17 Sep 2008 22:41:29 +0200 Message-Id: <1221684089.6405.51.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] 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="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMTcuIDA5LiAyMDA4IHYgMTQ6MzkgLTA0MDA6Cj4gInRv bS5wZXRjaCIgd3JpdGVzOgo+ID5UaGlzIGlzIGdlcm1hbmUgdG8gdGhlICJiZWxvbmdzIHRvIiB0 aHJlYWQgb24gTmV0bW9kLCB3aGljaCB0b3VjaGVkIG9uIHRoZSAnbm8KPiA+bmFtZXNwYWNlJyBp c3N1ZSBpbiBYUGF0aC4gIEluIHRoaXMgdGhyZWFkLCBMYWRhIHJhaXNlZCB0aGUgcXVlc3Rpb24g b2Ygd2hldGhlCj4gPnIKPiA+eWFuZyBzaG91bGQgdXNlIFhQYXRoIDEuMCBvciAyLjAsIGEgcXVl c3Rpb24gdG8gd2hpY2ggSSBuZXZlciBzYXcgYSBmb2xsb3cgdXAuCj4gCj4gVGhlIGlzc3VlIHdp dGggWFBhdGgyLjAgaXMgdGhlIGdyb3d0aCBpbiBzaXplIG9mIHRoZSBzcGVjICg2eCBpaXJjKQo+ IGFuZCB0aGUgbGFjayBvZiBhdmFpbGFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zLiAgT25lIGNh biB3b25kZXIKPiBpZiB0aGUgdHdvIGFyZSByZWxhdGVkIDteKQoKSW4gbXkgb3BpbmlvbiB0aGUg YmVzdCBhbHRlcm5hdGl2ZSBieSBmYXIgaXMgdG8gdXNlIFhQYXRoIDEuMCBhbmQgYWNjZXB0CnRo ZSB3YXkgaG93IGl0IGhhbmRsZXMgbmFtZXNwYWNlcywgd2l0aG91dCBjaGVhdGluZy4KCkJ5IGNv aW5jaWRlbmNlLCBJIHdhcyBsb29raW5nIGF0IHRoZSBzcGVjIG9mIE5WREwgKG9uZSBwYXJ0IG9m IERTREwpCndoZXJlIHRoZXkgaGFkIGEgc2ltaWxhciBwcm9ibGVtIC0gdGhleSBhbHNvIG5lZWRl ZCBzb21ldGhpbmcgbGlrZQpYUGF0aCwgYnV0IHNpbXBsZXIgYW5kIHdpdGggbm9uLW51bGwgZGVm YXVsdCBuYW1lc3BhY2UuIFNvIHRoZXkgY2FsbCBpdAptYXRjaFBhdGhFeHAgYW5kIGRlZmluZSBl dmVyeXRoaW5nIGluIHBsYWNlIC0gd2hhdCBpdCBtZWFucyB0aGF0IHN1Y2ggYW4KZXhwcmVzc2lv biBtYXRjaGVzIGV0Yy4gVGhpcyBpcyBhbiBvcHRpb24gZm9yIFlBTkcsIHRvbywgYWx0aG91Z2gg SQp0aGluayBpdCdzIG5vdCB3b3J0aCB0aGUgZWZmb3J0LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcgbGlzdApOZXRjb25mQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgo= From netconf-bounces@ietf.org Wed Sep 17 13:41:18 2008 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 0A84E3A6840; Wed, 17 Sep 2008 13:41:18 -0700 (PDT) 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 176EF3A6892 for ; Wed, 17 Sep 2008 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.925 X-Spam-Level: X-Spam-Status: No, score=-0.925 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66rxqEt24X2a for ; Wed, 17 Sep 2008 13:41:15 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 407523A6814 for ; Wed, 17 Sep 2008 13:41:15 -0700 (PDT) Received: from [172.29.2.202] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id 873E7D800CC for ; Wed, 17 Sep 2008 22:41:28 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <200809171839.m8HId9jx016321@idle.juniper.net> References: <200809171839.m8HId9jx016321@idle.juniper.net> Organization: CESNET Date: Wed, 17 Sep 2008 22:41:29 +0200 Message-Id: <1221684089.6405.51.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [Netconf] [rfc-editor@rfc-editor.org: RFC 5261 on An ExtensibleMarkup Language (XML) Patch Operations Framework UtilizingXML Path Language (XPath) Selectors] 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="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org UGhpbCBTaGFmZXIgcMOtxaFlIHYgU3QgMTcuIDA5LiAyMDA4IHYgMTQ6MzkgLTA0MDA6Cj4gInRv bS5wZXRjaCIgd3JpdGVzOgo+ID5UaGlzIGlzIGdlcm1hbmUgdG8gdGhlICJiZWxvbmdzIHRvIiB0 aHJlYWQgb24gTmV0bW9kLCB3aGljaCB0b3VjaGVkIG9uIHRoZSAnbm8KPiA+bmFtZXNwYWNlJyBp c3N1ZSBpbiBYUGF0aC4gIEluIHRoaXMgdGhyZWFkLCBMYWRhIHJhaXNlZCB0aGUgcXVlc3Rpb24g b2Ygd2hldGhlCj4gPnIKPiA+eWFuZyBzaG91bGQgdXNlIFhQYXRoIDEuMCBvciAyLjAsIGEgcXVl c3Rpb24gdG8gd2hpY2ggSSBuZXZlciBzYXcgYSBmb2xsb3cgdXAuCj4gCj4gVGhlIGlzc3VlIHdp dGggWFBhdGgyLjAgaXMgdGhlIGdyb3d0aCBpbiBzaXplIG9mIHRoZSBzcGVjICg2eCBpaXJjKQo+ IGFuZCB0aGUgbGFjayBvZiBhdmFpbGFiaWxpdHkgb2YgaW1wbGVtZW50YXRpb25zLiAgT25lIGNh biB3b25kZXIKPiBpZiB0aGUgdHdvIGFyZSByZWxhdGVkIDteKQoKSW4gbXkgb3BpbmlvbiB0aGUg YmVzdCBhbHRlcm5hdGl2ZSBieSBmYXIgaXMgdG8gdXNlIFhQYXRoIDEuMCBhbmQgYWNjZXB0CnRo ZSB3YXkgaG93IGl0IGhhbmRsZXMgbmFtZXNwYWNlcywgd2l0aG91dCBjaGVhdGluZy4KCkJ5IGNv aW5jaWRlbmNlLCBJIHdhcyBsb29raW5nIGF0IHRoZSBzcGVjIG9mIE5WREwgKG9uZSBwYXJ0IG9m IERTREwpCndoZXJlIHRoZXkgaGFkIGEgc2ltaWxhciBwcm9ibGVtIC0gdGhleSBhbHNvIG5lZWRl ZCBzb21ldGhpbmcgbGlrZQpYUGF0aCwgYnV0IHNpbXBsZXIgYW5kIHdpdGggbm9uLW51bGwgZGVm YXVsdCBuYW1lc3BhY2UuIFNvIHRoZXkgY2FsbCBpdAptYXRjaFBhdGhFeHAgYW5kIGRlZmluZSBl dmVyeXRoaW5nIGluIHBsYWNlIC0gd2hhdCBpdCBtZWFucyB0aGF0IHN1Y2ggYW4KZXhwcmVzc2lv biBtYXRjaGVzIGV0Yy4gVGhpcyBpcyBhbiBvcHRpb24gZm9yIFlBTkcsIHRvbywgYWx0aG91Z2gg SQp0aGluayBpdCdzIG5vdCB3b3J0aCB0aGUgZWZmb3J0LgoKTGFkYQoKLS0gCkxhZGlzbGF2IExo b3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcgbGlzdApOZXRjb25mQGll dGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZgo= From netconf-bounces@ietf.org Sun Sep 21 08:07:29 2008 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 22E4F3A6BCA; Sun, 21 Sep 2008 08:07:29 -0700 (PDT) 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 BC00F3A6802; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 i3Fkqwvn+g7h; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F3AAB3A6862; Fri, 19 Sep 2008 07:14:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,429,1217822400"; d="scan'208";a="122286925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Sep 2008 10:14:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 19 Sep 2008 10:14:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 16:14:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail Problems Thread-Index: AckaXfJaz1KltMUORmq3BbOwrj8wBQ== From: "Romascanu, Dan (Dan)" To: "IESG" , "IAB" , , "ops-area (IETF)" , , , , , , "IETF DNS Directorate" , , , "MIB Doctors (E-mail)" , X-Mailman-Approved-At: Sun, 21 Sep 2008 08:07:28 -0700 Subject: [Netconf] Mail Problems 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 My company mail servers were in trouble for about thirteen hours starting around 7PM ET yesterday 9/18. All mails sent to me during this time got lost. If you believe that you sent me something important during this time please resend. Thanks and Regards, Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Sep 21 08:07:29 2008 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 22E4F3A6BCA; Sun, 21 Sep 2008 08:07:29 -0700 (PDT) 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 BC00F3A6802; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 i3Fkqwvn+g7h; Fri, 19 Sep 2008 07:15:02 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id F3AAB3A6862; Fri, 19 Sep 2008 07:14:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,429,1217822400"; d="scan'208";a="122286925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Sep 2008 10:14:55 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 19 Sep 2008 10:14:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 19 Sep 2008 16:14:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mail Problems Thread-Index: AckaXfJaz1KltMUORmq3BbOwrj8wBQ== From: "Romascanu, Dan (Dan)" To: "IESG" , "IAB" , , "ops-area (IETF)" , , , , , , "IETF DNS Directorate" , , , "MIB Doctors (E-mail)" , X-Mailman-Approved-At: Sun, 21 Sep 2008 08:07:28 -0700 Subject: [Netconf] Mail Problems 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 My company mail servers were in trouble for about thirteen hours starting around 7PM ET yesterday 9/18. All mails sent to me during this time got lost. If you believe that you sent me something important during this time please resend. Thanks and Regards, Dan _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 22 11:01:00 2008 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 E051328C18E; Mon, 22 Sep 2008 11:00:59 -0700 (PDT) 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 D60073A6C05 for ; Mon, 22 Sep 2008 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.556 X-Spam-Level: X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_05=-1.11, 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 k1ePpdE1Fx9s for ; Mon, 22 Sep 2008 11:00:56 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 70E7C3A6B60 for ; Mon, 22 Sep 2008 10:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 424FFA96D91 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17267-06 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 01B76A96D89 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Mon, 22 Sep 2008 10:59:35 -0700 From: Vladlen Kot To: "netconf@ietf.org" Date: Mon, 22 Sep 2008 10:59:34 -0700 Thread-Topic: Need help with setting up an NETCONF on my server. Thread-Index: AckZ5MtFcv+ghK8aT7uP/OzOMMuDcwC+B37Q Message-ID: <48C276B536524E478C659685995F6AA590428A2E2A@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] Need help with setting up an NETCONF on my server. 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="===============1263534388==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============1263534388== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello there, I'm creating an SSH/NETCONF Client (for internal use) to establish NETCONF = session. And I'm looking for a help/info on how to set up a NETCONF on my s= erver to at least verify that my Client works (some fake NETCONF set up can= work too (I guess)). Thanks in advance, Vlad --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello there,

     

    I’m creating an SSH/NETCONF Client (for internal u= se) to establish NETCONF session. And I’m looking for a help/info on how = to set up a NETCONF on my server to at least verify that my Client works (some fake NETCONF set up can work too (I guess)).

     

    Thanks in advance,

    Vlad

     

    --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_-- --===============1263534388== 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 --===============1263534388==-- From netconf-bounces@ietf.org Mon Sep 22 11:01:00 2008 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 E051328C18E; Mon, 22 Sep 2008 11:00:59 -0700 (PDT) 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 D60073A6C05 for ; Mon, 22 Sep 2008 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.556 X-Spam-Level: X-Spam-Status: No, score=0.556 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_05=-1.11, 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 k1ePpdE1Fx9s for ; Mon, 22 Sep 2008 11:00:56 -0700 (PDT) Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by core3.amsl.com (Postfix) with ESMTP id 70E7C3A6B60 for ; Mon, 22 Sep 2008 10:59:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 424FFA96D91 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17267-06 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from rbsjx.ad.redback.com (rbsjxh1.redback.com [155.53.14.105]) by prattle.redback.com (Postfix) with ESMTP id 01B76A96D89 for ; Mon, 22 Sep 2008 10:59:36 -0700 (PDT) Received: from RBSJX.ad.redback.com ([155.53.14.103]) by rbsjxh1.ad.redback.com ([155.53.14.105]) with mapi; Mon, 22 Sep 2008 10:59:35 -0700 From: Vladlen Kot To: "netconf@ietf.org" Date: Mon, 22 Sep 2008 10:59:34 -0700 Thread-Topic: Need help with setting up an NETCONF on my server. Thread-Index: AckZ5MtFcv+ghK8aT7uP/OzOMMuDcwC+B37Q Message-ID: <48C276B536524E478C659685995F6AA590428A2E2A@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] Need help with setting up an NETCONF on my server. 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="===============1263534388==" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org --===============1263534388== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_" --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello there, I'm creating an SSH/NETCONF Client (for internal use) to establish NETCONF = session. And I'm looking for a help/info on how to set up a NETCONF on my s= erver to at least verify that my Client works (some fake NETCONF set up can= work too (I guess)). Thanks in advance, Vlad --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello there,

     

    I’m creating an SSH/NETCONF Client (for internal u= se) to establish NETCONF session. And I’m looking for a help/info on how = to set up a NETCONF on my server to at least verify that my Client works (some fake NETCONF set up can work too (I guess)).

     

    Thanks in advance,

    Vlad

     

    --_000_48C276B536524E478C659685995F6AA590428A2E2ARBSJXadredbac_-- --===============1263534388== 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 --===============1263534388==-- From netconf-bounces@ietf.org Mon Sep 22 13:13:41 2008 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 950833A6B05; Mon, 22 Sep 2008 13:13:41 -0700 (PDT) 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 56A7B3A6B05 for ; Mon, 22 Sep 2008 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBDZK9DYMwgr for ; Mon, 22 Sep 2008 13:13:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5D4973A6AB3 for ; Mon, 22 Sep 2008 13:13:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A3C3ED800BD for ; Mon, 22 Sep 2008 22:13:36 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <48C276B536524E478C659685995F6AA590428A2E2A@RBSJX.ad.redback.com> References: <48C276B536524E478C659685995F6AA590428A2E2A@RBSJX.ad.redback.com> Organization: CESNET Date: Mon, 22 Sep 2008 22:13:38 +0200 Message-Id: <1222114418.32313.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [Netconf] Need help with setting up an NETCONF on my server. 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="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org SGkgVmxhZCwKCkkgcHV0IHRvZ2V0aGVyIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBzZXR1 cDoKaHR0cDovL3d3dy5mbG93bW9uLm9yZy9mbG93bW9uLXByb2JlL2RldmVsL2NvbmZpZy9uZXRj b25mLXNzaC1ub3Rlcy8KCkhvcGUgdGhpcyBoZWxwcywKCkxhZGEKClZsYWRsZW4gS290IHDDrcWh ZSB2IFBvIDIyLiAwOS4gMjAwOCB2IDEwOjU5IC0wNzAwOgo+IEhlbGxvIHRoZXJlLAo+IAo+ICAK PiAKPiBJ4oCZbSBjcmVhdGluZyBhbiBTU0gvTkVUQ09ORiBDbGllbnQgKGZvciBpbnRlcm5hbCB1 c2UpIHRvIGVzdGFibGlzaAo+IE5FVENPTkYgc2Vzc2lvbi4gQW5kIEnigJltIGxvb2tpbmcgZm9y IGEgaGVscC9pbmZvIG9uIGhvdyB0byBzZXQgdXAgYQo+IE5FVENPTkYgb24gbXkgc2VydmVyIHRv IGF0IGxlYXN0IHZlcmlmeSB0aGF0IG15IENsaWVudCB3b3JrcyAoc29tZQo+IGZha2UgTkVUQ09O RiBzZXQgdXAgY2FuIHdvcmsgdG9vIChJIGd1ZXNzKSkuCj4gCj4gIAo+IAo+IFRoYW5rcyBpbiBh ZHZhbmNlLAo+IAo+IFZsYWQKPiAKPiAgCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBOZXRjb25mIG1haWxpbmcgbGlzdAo+IE5ldGNvbmZA aWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcg bGlzdApOZXRjb25mQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZgo= From netconf-bounces@ietf.org Mon Sep 22 13:13:41 2008 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 950833A6B05; Mon, 22 Sep 2008 13:13:41 -0700 (PDT) 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 56A7B3A6B05 for ; Mon, 22 Sep 2008 13:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.088 X-Spam-Level: X-Spam-Status: No, score=-0.088 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBDZK9DYMwgr for ; Mon, 22 Sep 2008 13:13:39 -0700 (PDT) Received: from office2.cesnet.cz (office2.cesnet.cz [195.113.144.244]) by core3.amsl.com (Postfix) with ESMTP id 5D4973A6AB3 for ; Mon, 22 Sep 2008 13:13:39 -0700 (PDT) Received: from [172.29.2.201] (asus-gx.lhotka.cesnet.cz [195.113.161.161]) by office2.cesnet.cz (Postfix) with ESMTP id A3C3ED800BD for ; Mon, 22 Sep 2008 22:13:36 +0200 (CEST) From: Ladislav Lhotka To: netconf@ietf.org In-Reply-To: <48C276B536524E478C659685995F6AA590428A2E2A@RBSJX.ad.redback.com> References: <48C276B536524E478C659685995F6AA590428A2E2A@RBSJX.ad.redback.com> Organization: CESNET Date: Mon, 22 Sep 2008 22:13:38 +0200 Message-Id: <1222114418.32313.23.camel@missotis> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [Netconf] Need help with setting up an NETCONF on my server. 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="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org SGkgVmxhZCwKCkkgcHV0IHRvZ2V0aGVyIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhpcyBzZXR1 cDoKaHR0cDovL3d3dy5mbG93bW9uLm9yZy9mbG93bW9uLXByb2JlL2RldmVsL2NvbmZpZy9uZXRj b25mLXNzaC1ub3Rlcy8KCkhvcGUgdGhpcyBoZWxwcywKCkxhZGEKClZsYWRsZW4gS290IHDDrcWh ZSB2IFBvIDIyLiAwOS4gMjAwOCB2IDEwOjU5IC0wNzAwOgo+IEhlbGxvIHRoZXJlLAo+IAo+ICAK PiAKPiBJ4oCZbSBjcmVhdGluZyBhbiBTU0gvTkVUQ09ORiBDbGllbnQgKGZvciBpbnRlcm5hbCB1 c2UpIHRvIGVzdGFibGlzaAo+IE5FVENPTkYgc2Vzc2lvbi4gQW5kIEnigJltIGxvb2tpbmcgZm9y IGEgaGVscC9pbmZvIG9uIGhvdyB0byBzZXQgdXAgYQo+IE5FVENPTkYgb24gbXkgc2VydmVyIHRv IGF0IGxlYXN0IHZlcmlmeSB0aGF0IG15IENsaWVudCB3b3JrcyAoc29tZQo+IGZha2UgTkVUQ09O RiBzZXQgdXAgY2FuIHdvcmsgdG9vIChJIGd1ZXNzKSkuCj4gCj4gIAo+IAo+IFRoYW5rcyBpbiBh ZHZhbmNlLAo+IAo+IFZsYWQKPiAKPiAgCj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBOZXRjb25mIG1haWxpbmcgbGlzdAo+IE5ldGNvbmZA aWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK LS0gCkxhZGlzbGF2IExob3RrYSwgQ0VTTkVUClBHUCBLZXkgSUQ6IEU3NEU4QzBDCgpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpOZXRjb25mIG1haWxpbmcg bGlzdApOZXRjb25mQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZgo= From netconf-bounces@ietf.org Mon Sep 22 13:36:31 2008 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 745143A6B58; Mon, 22 Sep 2008 13:36:31 -0700 (PDT) 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 C404E3A6B58 for ; Mon, 22 Sep 2008 13:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 Z8m8bJqDIk6c for ; Mon, 22 Sep 2008 13:36:28 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 75CC63A6841 for ; Mon, 22 Sep 2008 13:36:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,448,1217822400"; d="scan'208";a="135743925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 22:35:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC Thread-Index: AckczK//Kj0LxJFYSRW36Bv0IHgU6QAJaABQ From: "Romascanu, Dan (Dan)" To: , , , , Cc: netconf@ietf.org Subject: [Netconf] FW: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC 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 This document was approved by the IESG as Informational RFC. Thanks and congratulations to the editors, and to the folks in the NETCONF community who supported this work with their comments and reviews. Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, September 22, 2008 7:02 PM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor Subject: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC The IESG has approved the following document: - 'Experience of implementing NETCONF over SOAP ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementa tion-10.txt Technical Summary This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. In the case that SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. Working Group Summary This document is an individual submission. Presentations were made in the NETCONF Working Group, the NETCONF WG chairs reviewed the document but no formal review was undertaken by the WG. Document Quality The document is based upon the implementation experienced gathered by the authors in implementing RFC 4741 and RFC 4743. The document was reviewed by Dan Romascanu as Area Director, by Mehmet Ersue and Bert Wijnen, co-chairs of the NETCONF WG, and by Stefan Santesson for the security directorate. Personnel This document is an indivudual submission and Dan Romascanu is the shepherding AD. RFC Editor Note RFC Editor, please make the following changes: 1. In the Abstract Section: OLD: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. NEW: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. It describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. 2. Add to Section 1.2 the following paragraph: This document describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation as it relies on cookies used on top of the persistent transport connections of HTTP. This is provided for information purposes only based on the implementation experience of the authors. 3. In Section 3.1.2 OLD: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session will be supported by an HTTP connection. However HTTP is a stateless protocol; that is, HTTP cannot process a user's request according to the state resulting from the user's previous request. Unless the state is kept at the HTTP- level, a different NETCONF service provider will be invoked every time the NETCONF application sends a NETCONF message to the NETCONF service provider. To ensure that the same NETCONF service provider is used every time the NETCONF application sends a NETCONF message, the state of the HTTP connection must be maintained. Accordingly, a cookie field inside an HTTP header was devised for maintaining the state of an HTTP connection. We therefore used such a cookie field to maintain the state of the HTTP connection over which the NETCONF- session maintenance is ensured. NEW: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session state is tied to the state of the underlying transport (TCP) connection (just like in NETCONF over SSH [RFC4742] and NETCONF over BEEP [RFC4744]). However, HTTP itself is a stateless protocol, and many server implementations process user requests independently of previous requests received over the same transport connection. To simplify implementation of the NETCONF service provider, we used the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. Note that this means our implementation actually uses an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. IESG Note This document discusses implementation experience of NETCONF over SOAP. Note that RFC 4741 section 2.4 states, "A NETCONF implementation MUST support the SSH transport protocol mapping". Therefore, a NETCONF implementation that only supports the SOAP transport described in this document and not (at least) also SSH is not in compliance with the NETCONF standards. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 22 13:36:31 2008 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 745143A6B58; Mon, 22 Sep 2008 13:36:31 -0700 (PDT) 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 C404E3A6B58 for ; Mon, 22 Sep 2008 13:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.061 X-Spam-Level: X-Spam-Status: No, score=-2.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 Z8m8bJqDIk6c for ; Mon, 22 Sep 2008 13:36:28 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 75CC63A6841 for ; Mon, 22 Sep 2008 13:36:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,448,1217822400"; d="scan'208";a="135743925" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.10]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 22 Sep 2008 16:35:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 22:35:52 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC Thread-Index: AckczK//Kj0LxJFYSRW36Bv0IHgU6QAJaABQ From: "Romascanu, Dan (Dan)" To: , , , , Cc: netconf@ietf.org Subject: [Netconf] FW: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC 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 This document was approved by the IESG as Informational RFC. Thanks and congratulations to the editors, and to the folks in the NETCONF community who supported this work with their comments and reviews. Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, September 22, 2008 7:02 PM To: IETF-Announce Cc: Internet Architecture Board; RFC Editor Subject: Document Action: 'Experience of implementing NETCONF over SOAP' to Informational RFC The IESG has approved the following document: - 'Experience of implementing NETCONF over SOAP ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-iijima-netconf-soap-implementa tion-10.txt Technical Summary This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. In the case that SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. Working Group Summary This document is an individual submission. Presentations were made in the NETCONF Working Group, the NETCONF WG chairs reviewed the document but no formal review was undertaken by the WG. Document Quality The document is based upon the implementation experienced gathered by the authors in implementing RFC 4741 and RFC 4743. The document was reviewed by Dan Romascanu as Area Director, by Mehmet Ersue and Bert Wijnen, co-chairs of the NETCONF WG, and by Stefan Santesson for the security directorate. Personnel This document is an indivudual submission and Dan Romascanu is the shepherding AD. RFC Editor Note RFC Editor, please make the following changes: 1. In the Abstract Section: OLD: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. NEW: This document describes how the authors developed a SOAP (Simple Object Access Protocol)-based NETCONF client and server. It describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation making use of cookies on top of the persistent transport connections of HTTP. When SOAP is used as a transport protocol for NETCONF, various kinds of development tools are available. By making full use of these tools, developers can significantly reduce their workload. The authors developed an NMS (Network Management System) and network equipment that can deal with NETCONF messages sent over SOAP. This document aims to provide NETCONF development guidelines gained from the experience of implementing a SOAP-based NETCONF client and server. 2. Add to Section 1.2 the following paragraph: This document describes an alternative SOAP binding for NETCONF which does not interoperate with an RFC4743 conformant implementation as it relies on cookies used on top of the persistent transport connections of HTTP. This is provided for information purposes only based on the implementation experience of the authors. 3. In Section 3.1.2 OLD: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session will be supported by an HTTP connection. However HTTP is a stateless protocol; that is, HTTP cannot process a user's request according to the state resulting from the user's previous request. Unless the state is kept at the HTTP- level, a different NETCONF service provider will be invoked every time the NETCONF application sends a NETCONF message to the NETCONF service provider. To ensure that the same NETCONF service provider is used every time the NETCONF application sends a NETCONF message, the state of the HTTP connection must be maintained. Accordingly, a cookie field inside an HTTP header was devised for maintaining the state of an HTTP connection. We therefore used such a cookie field to maintain the state of the HTTP connection over which the NETCONF- session maintenance is ensured. NEW: In [RFC4743], HTTP is specified as an option of an underlying protocol for NETCONF over SOAP. When HTTP is used for that purpose, it is also specified that a NETCONF session state is tied to the state of the underlying transport (TCP) connection (just like in NETCONF over SSH [RFC4742] and NETCONF over BEEP [RFC4744]). However, HTTP itself is a stateless protocol, and many server implementations process user requests independently of previous requests received over the same transport connection. To simplify implementation of the NETCONF service provider, we used the cookie field inside the HTTP header to map incoming requests to NETCONF sessions. Note that this means our implementation actually uses an alternative SOAP binding for NETCONF which does not interoperate with RFC4743 compliant implementations. IESG Note This document discusses implementation experience of NETCONF over SOAP. Note that RFC 4741 section 2.4 states, "A NETCONF implementation MUST support the SSH transport protocol mapping". Therefore, a NETCONF implementation that only supports the SOAP transport described in this document and not (at least) also SSH is not in compliance with the NETCONF standards. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 25 04:33:31 2008 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 500C53A689D; Thu, 25 Sep 2008 04:33:31 -0700 (PDT) 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 19AB83A689B for ; Thu, 25 Sep 2008 04:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQh0PzccWF6A for ; Thu, 25 Sep 2008 04:33:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 98F903A689D for ; Thu, 25 Sep 2008 04:33:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8P9i9AD014425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Sep 2008 11:44:09 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8P9i9Ia011337; Thu, 25 Sep 2008 11:44:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Sep 2008 11:44:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Sep 2008 11:44:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-tls-04.txt Thread-Index: AckeeL7BWp0YU3CbRtCCShffwHu2ggAcu8TA From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Sep 2008 09:44:09.0234 (UTC) FILETIME=[42246F20:01C91EF3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080925114409-322EABB0-AA21AFD6/0-0/0-15 X-purgate-size: 1081/0 Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Hi All, > as discussed in the NETCONF session Badra initiated > the review of the security AD Pasi and updated the > draft NETCONF over TLS based on the recommendations > in the session and Pasi's review comments (see > http://tools.ietf.org/html/draft-ietf-netconf-tls-04 and > http://www.ietf.org/mail-archive/web/netconf/current/msg03743.html). > With this mail we want to start a WGLC for the draft > NETCONF over TLS, which is proposed to publish as a > Proposed Standard RFC. > > The WGLC starts on September 25, 2008 and will run > until October 10, 2008. > Unfortunately there were no additional comments on > the last version of the draft on the maillist. > We definitely want to be sure whether we have sufficient > WG support for the document or not. > > PLEASE REVIEW and comment it. Even if you don't have any technical comments PLEASE SPEAK UP AND STATE whether you support it or not! > Thank you and looking forward for your reviews and > comments. > > Mehmet & Bert > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Thu Sep 25 04:33:31 2008 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 500C53A689D; Thu, 25 Sep 2008 04:33:31 -0700 (PDT) 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 19AB83A689B for ; Thu, 25 Sep 2008 04:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQh0PzccWF6A for ; Thu, 25 Sep 2008 04:33:29 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 98F903A689D for ; Thu, 25 Sep 2008 04:33:25 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id m8P9i9AD014425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 25 Sep 2008 11:44:09 +0200 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id m8P9i9Ia011337; Thu, 25 Sep 2008 11:44:09 +0200 Received: from DEMUEXC005.nsn-intra.net ([10.150.128.17]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Sep 2008 11:44:09 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 25 Sep 2008 11:44:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC for draft-ietf-netconf-tls-04.txt Thread-Index: AckeeL7BWp0YU3CbRtCCShffwHu2ggAcu8TA From: "Ersue, Mehmet (NSN - DE/Munich)" To: X-OriginalArrivalTime: 25 Sep 2008 09:44:09.0234 (UTC) FILETIME=[42246F20:01C91EF3] X-purgate: clean X-purgate: This mail is considered clean X-purgate-type: clean X-purgate-Ad: Checked for Spam by eleven - eXpurgate www.eXpurgate.net X-purgate-ID: 151667::080925114409-322EABB0-AA21AFD6/0-0/0-15 X-purgate-size: 1081/0 Subject: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > Hi All, > as discussed in the NETCONF session Badra initiated > the review of the security AD Pasi and updated the > draft NETCONF over TLS based on the recommendations > in the session and Pasi's review comments (see > http://tools.ietf.org/html/draft-ietf-netconf-tls-04 and > http://www.ietf.org/mail-archive/web/netconf/current/msg03743.html). > With this mail we want to start a WGLC for the draft > NETCONF over TLS, which is proposed to publish as a > Proposed Standard RFC. > > The WGLC starts on September 25, 2008 and will run > until October 10, 2008. > Unfortunately there were no additional comments on > the last version of the draft on the maillist. > We definitely want to be sure whether we have sufficient > WG support for the document or not. > > PLEASE REVIEW and comment it. Even if you don't have any technical comments PLEASE SPEAK UP AND STATE whether you support it or not! > Thank you and looking forward for your reviews and > comments. > > Mehmet & Bert > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Sep 26 01:17:21 2008 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 59AEE28C16B; Fri, 26 Sep 2008 01:17:21 -0700 (PDT) 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 D741A28C16B for ; Fri, 26 Sep 2008 01:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 QNMZ7pQSVdrR for ; Fri, 26 Sep 2008 01:17:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BF6353A6AED for ; Fri, 26 Sep 2008 01:17:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E144C005D; Fri, 26 Sep 2008 10:17:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TYHzTzGevnx7; Fri, 26 Sep 2008 10:17:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BB68C0026; Fri, 26 Sep 2008 10:17:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDF297B9C1A; Fri, 26 Sep 2008 10:17:14 +0200 (CEST) Date: Fri, 26 Sep 2008 10:17:14 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20080926081714.GA27659@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 25, 2008 at 11:44:07AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > With this mail we want to start a WGLC for the draft NETCONF over > TLS, which is proposed to publish as a Proposed Standard RFC. I have read and here are my comments: a) I am wondering about PSK support. RFC 4279 says in the applicability statement: The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. With NETMOD deployed on many bridges and routers and some host systems in the future, we might have a small number of clients with a large number of sFrom netconf-bounces@ietf.org Fri Sep 26 01:17:21 2008 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 59AEE28C16B; Fri, 26 Sep 2008 01:17:21 -0700 (PDT) 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 D741A28C16B for ; Fri, 26 Sep 2008 01:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 QNMZ7pQSVdrR for ; Fri, 26 Sep 2008 01:17:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id BF6353A6AED for ; Fri, 26 Sep 2008 01:17:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E144C005D; Fri, 26 Sep 2008 10:17:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TYHzTzGevnx7; Fri, 26 Sep 2008 10:17:15 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1BB68C0026; Fri, 26 Sep 2008 10:17:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BDF297B9C1A; Fri, 26 Sep 2008 10:17:14 +0200 (CEST) Date: Fri, 26 Sep 2008 10:17:14 +0200 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20080926081714.GA27659@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 25, 2008 at 11:44:07AM +0200, Ersue, Mehmet (NSN - DE/Munich) wrote: > With this mail we want to start a WGLC for the draft NETCONF over > TLS, which is proposed to publish as a Proposed Standard RFC. I have read and here are my comments: a) I am wondering about PSK support. RFC 4279 says in the applicability statement: The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. With NETMOD deployed on many bridges and routers and some host systems in the future, we might have a small number of clients with a large numbeervers and a key management problem. b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA (please add a reference to RFC 4279 where this cipher suite is defined to help the reader) but does not spell out any other cipher suite requirement, essentially making TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps there needs to be more text about required to implement cipher suites or pointers to "standard" required to implement TLS cipher suites that apply here as well. c) I suggest to remove "simple" from the text in the introduction. d) What does "highly recommended" mean in terms of IETF terminology? Is this the same as RECOMMENDED? I suggest to stick to the well defined and understood IETF terminology. Summary: I think the document has improved quite a bit since its early days. I am still not 100% convinced about the PSK support and it being required to implement. /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 r of servers and a key management problem. b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA (please add a reference to RFC 4279 where this cipher suite is defined to help the reader) but does not spell out any other cipher suite requirement, essentially making TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps there needs to be more text about required to implement cipher suites or pointers to "standard" required to implement TLS cipher suites that apply here as well. c) I suggest to remove "simple" from the text in the introduction. d) What does "highly recommended" mean in terms of IETF terminology? Is this the same as RECOMMENDED? I suggest to stick to the well defined and understood IETF terminology. Summary: I think the document has improved quite a bit since its early days. I am still not 100% convinced about the PSK support and it being required to implement. /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 Sep 26 13:25:57 2008 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 2B1DA3A6903; Fri, 26 Sep 2008 13:25:57 -0700 (PDT) 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 57A0F3A6903 for ; Fri, 26 Sep 2008 13:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HELO_EQ_FR=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 klmxiYXH722b for ; Fri, 26 Sep 2008 13:25:54 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 31C593A6818 for ; Fri, 26 Sep 2008 13:25:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8QLQ6M4631038; Fri, 26 Sep 2008 22:26:06 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Fri, 26 Sep 2008 22:25:13 +0200 (CEST) Message-ID: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Date: Fri, 26 Sep 2008 22:25:13 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Fri, 26 Sep 2008 22:26:09 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org RGVhciBKdWVyZ2VuLAoKVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBSZXNwb25zZXMgYXJl IGluLWxpbmXigKYKCj4+IFdpdGggdGhpcyBtYWlsIHdlIHdhbnQgdG8gc3RhcnQgYSBXR0xDIGZv ciB0aGUgZHJhZnQgTkVUQ09ORiBvdmVyCj4+IFRMUywgd2hpY2ggaXMgcHJvcG9zZWQgdG8gcHVi bGlzaCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQy4KCj4gSSBoYXZlIHJlYWQgPGRyYWZ0LWll dGYtbmV0Y29uZi10bHMtMDQudHh0PiBhbmQgaGVyZSBhcmUgbXkgY29tbWVudHM6Cgo+IGEpIEkg YW0gd29uZGVyaW5nIGFib3V0IFBTSyBzdXBwb3J0LiBSRkMgNDI3OSBzYXlzIGluIHRoZQo+IGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50Ogo+Cj4gIFRoZSBjaXBoZXJzdWl0ZXMgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50IGFyZSBpbnRlbmRlZCBmb3IgYSByYXRoZXIKPiAgbGltaXRlZCBzZXQgb2Yg YXBwbGljYXRpb25zLCB1c3VhbGx5IGludm9sdmluZyBvbmx5IGEgdmVyeSBzbWFsbAo+ICBudW1i ZXIgb2YgY2xpZW50cyBhbmQgc2VydmVycy4gIEV2ZW4gaW4gc3VjaCBlbnZpcm9ubWVudHMsIG90 aGVyCj4gIGFsdGVybmF0aXZlcyBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZS4KPgo+IFdpdGggTkVU TU9EIGRlcGxveWVkIG9uIG1hbnkgYnJpZGdlcyBhbmQgcm91dGVycyBhbmQgc29tZSBob3N0Cj4g c3lzdGVtcyBpbiB0aGUgZnV0dXJlLCB3ZSBtaWdodCBoYXZlIGEgc21hbGwgbnVtYmVyIG9mIGNs aWVudHMgd2l0aAo+IGEgbGFyZ2UgbnVtYmVyIG9mIHNlcnZlcnMgYW5kIGEga2V5IG1hbmFnZW1l bnQgcHJvYmxlbS4KCj4gU3VtbWFyeTogSSB0aGluayB0aGUgZG9jdW1lbnQgaGFzIGltcHJvdmVk IHF1aXRlIGEgYml0IHNpbmNlIGl0cyBlYXJseQo+IGRheXMuIEkgYW0gc3RpbGwgbm90IDEwMCUg Y29udmluY2VkIGFib3V0IHRoZSBQU0sgc3VwcG9ydCBhbmQgaXQgYmVpbmcKPiByZXF1aXJlZCB0 byBpbXBsZW1lbnQuCgpJcyBpdCBzdWZmaWNpZW50IHRvIHVzZSB0aGUga2V5IHdvcmQgIk1BWSIg YXMgZm9sbG93aW5nIHRvIG1ha2Ugb3B0aW9uYWwKdGhlIFBTSyB1c2U/IE9yIGRvIHlvdSBwcmVm ZXIgdG8gZW50aXJlbHkgcmVtb3ZlIFBTSyByZWxhdGVkIHRleHQ/IEluIHRoZQpmaXJzdCBjYXNl OgoKT0xEOgoKICAgU2VjdGlvbiAzLjEgZGVzY3JpYmVzIGhvdyB0aGUgY2xpZW50IGF1dGhlbnRp Y2F0ZXMgdGhlIHNlcnZlciBpZgogICBwdWJsaWMga2V5IGNlcnRpZmljYXRlcyBhcmUgcHJvdmlk ZWQgYnkgdGhlIHNlcnZlciwgc2VjdGlvbiAzLjIKICAgZGVzY3JpYmVzIGhvdyB0aGUgc2VydmVy IGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBpZiBwdWJsaWMga2V5CiAgIGNlcnRpZmljYXRlcyBh cmUgcHJvdmlkZWQgYnkgdGhlIGNsaWVudCwgYW5kIHNlY3Rpb24gMy4zIGRlc2NyaWJlcyBob3cK ICAgdGhlIGNsaWVudCBhbmQgc2VydmVyIG11dHVhbGx5IGF1dGhlbnRpY2F0ZSBvbmUgYW5vdGhl ciB1c2luZyBhIHByZS0KICAgc2hhcmVkIGtleSAoUFNLKS4KCk5FVzoKCiAgIFNlY3Rpb24gMy4x IGRlc2NyaWJlcyBob3cgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHRoZSBzZXJ2ZXIgaWYKICAg cHVibGljIGtleSBjZXJ0aWZpY2F0ZXMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIsIHNlY3Rp b24gMy4yCiAgIGRlc2NyaWJlcyBob3cgdGhlIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGll bnQgaWYgcHVibGljIGtleQogICBjZXJ0aWZpY2F0ZXMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBjbGll bnQsIGFuZCBzZWN0aW9uIDMuMyBkZXNjcmliZXMgaG93CiAgIHRoZSBjbGllbnQgYW5kIHNlcnZl ciBNQVkgbXV0dWFsbHkgYXV0aGVudGljYXRlIG9uZSBhbm90aGVyIHVzaW5nIGEKICAgcHJlLXNo YXJlZCBrZXkgKFBTSykuIF5eXgoKPiBiKSBTZWN0aW9uIDQgcmVxdWlyZXMgdG8gaW1wbGVtZW50 IFRMU19ESEVfUFNLX1dJVEhfQUVTXzEyOF9DQkNfU0hBCj4gIChwbGVhc2UgYWRkIGEgcmVmZXJl bmNlIHRvIFJGQyA0Mjc5IHdoZXJlIHRoaXMgY2lwaGVyIHN1aXRlIGlzCj4gIGRlZmluZWQgdG8g aGVscCB0aGUgcmVhZGVyKSBidXQgZG9lcyBub3Qgc3BlbGwgb3V0IGFueSBvdGhlciBjaXBoZXIK PiAgc3VpdGUgcmVxdWlyZW1lbnQsIGVzc2VudGlhbGx5IG1ha2luZwo+ICBUTFNfREhFX1BTS19X SVRIX0FFU18xMjhfQ0JDX1NIQSB0aGUgY29tbW9uIGRlbm9taW5hdG9yLiBQZXJoYXBzCj4gIHRo ZXJlIG5lZWRzIHRvIGJlIG1vcmUgdGV4dCBhYm91dCByZXF1aXJlZCB0byBpbXBsZW1lbnQgY2lw aGVyCj4gIHN1aXRlcyBvciBwb2ludGVycyB0byAic3RhbmRhcmQiIHJlcXVpcmVkIHRvIGltcGxl bWVudCBUTFMgY2lwaGVyCj4gIHN1aXRlcyB0aGF0IGFwcGx5IGhlcmUgYXMgd2VsbC4KClllcywg dGhpcyBpcyB0cnVlLiBXaXRoIFRMUywgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGFuIGFwcGxpY2F0 aW9uIHByb2ZpbGUKc3RhbmRhcmQgc3BlY2lmeWluZyBvdGhlcndpc2UsIGEgVExTLWNvbXBsaWFu dCBhcHBsaWNhdGlvbiBNVVNUIGltcGxlbWVudAphIGNpcGhlciBzdWl0ZSwgd2hpY2ggdmFyaWVz IHdpdGggdGhlIFRMUyB2ZXJzaW9uLCBpLmUuOgoKVExTIDEuMjogVExTX1JTQV9XSVRIX0FFU18x MjhfQ0JDX1NIQQpUTFMgMS4xOiBUTFNfUlNBX1dJVEhfM0RFU19FREVfQ0JDX1NIQQpUTFMgMS4w OiBUTFNfREhFX0RTU19XSVRIXzNERVNfRURFX0NCQ19TSEEKClBsZWFzZSBkb24ndCBoZXNpdGF0 ZSB0byBwcm9wb3NlIGEgYmV0dGVyIHRleHQsIGhlcmUgaXMgYSB0ZW50YXRpdmU6CgpPTEQ6Cgog ICBBIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcHJvdG9jb2wgc3BlY2lmaWVkIGlu IHRoaXMgZG9jdW1lbnQKICAgTVVTVCBpbXBsZW1lbnQgdGhlIGNpcGhlciBzdWl0ZSBUTFNfREhF X1BTS19XSVRIX0FFU18xMjhfQ0JDX1NIQSBhbmQKICAgTUFZIGltcGxlbWVudCBhbnkgVExTIGNp cGhlciBzdWl0ZSB0aGF0IHByb3ZpZGVzIG11dHVhbCBhdXRoZW50aWNhdGlvbi4KCk5FVzoKCiAg IEEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIG9mIHRoZSBwcm90b2NvbCBzcGVjaWZpZWQgaW4g dGhpcyBkb2N1bWVudAogICBNQVkgaW1wbGVtZW50IGFueSBUTFMgY2lwaGVyIHN1aXRlIHRoYXQg cHJvdmlkZXMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLgoKICAgRm9yIGF1dGhlbnRpY2F0aW9uIGJh c2VkIG9uIFBTS3MsIGEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIE1VU1QKICAgaW1wbGVtZW50 IHRoZSBjaXBoZXIgc3VpdGUgVExTX0RIRV9QU0tfV0lUSF9BRVNfMTI4X0NCQ19TSEEuCgogICBG cm8gYXV0aGVudGljYXRpb24gYmFzZWQgb24gcHVibGljIGtleSBjZXJ0aWZpY2F0ZXMsIGEgY29t cGxpYW50CiAgIGltcGxlbWVudGF0aW9uIE1VU1QgaW1wbGVtZW50IHRoZSAnbWFuZGF0b3J5IGNp cGhlciBzdWl0ZScgc3BlY2lmaWVkIGJ5CiAgIGVhY2ggVExTIHZlcnNpb24gKGUuZy4gIHdpdGgg VExTIDEuMiwgdGhlIG1hbmRvdGFyeSBjaXBoZXIgc3VpdGUgaXMKICAgVExTX1JTQV9XSVRIX0FF U18xMjhfQ0JDX1NIQSkuCgo+IGMpIEkgc3VnZ2VzdCB0byByZW1vdmUgInNpbXBsZSIgZnJvbSB0 aGUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9uLgoKT0suCgo+IGQpIFdoYXQgZG9lcyAiaGlnaGx5 IHJlY29tbWVuZGVkIiBtZWFuIGluIHRlcm1zIG9mIElFVEYgdGVybWlub2xvZ3k/Cj4gIElzIHRo aXMgdGhlIHNhbWUgYXMgUkVDT01NRU5ERUQ/IEkgc3VnZ2VzdCB0byBzdGljayB0byB0aGUgd2Vs bAo+ICBkZWZpbmVkIGFuZCB1bmRlcnN0b29kIElFVEYgdGVybWlub2xvZ3kuCgpPSy4KCkJlc3Qg cmVnYXJkcywKQmFkcmEKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK From netconf-bounces@ietf.org Fri Sep 26 13:25:57 2008 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 2B1DA3A6903; Fri, 26 Sep 2008 13:25:57 -0700 (PDT) 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 57A0F3A6903 for ; Fri, 26 Sep 2008 13:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HELO_EQ_FR=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 klmxiYXH722b for ; Fri, 26 Sep 2008 13:25:54 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 31C593A6818 for ; Fri, 26 Sep 2008 13:25:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8QLQ6M4631038; Fri, 26 Sep 2008 22:26:06 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Fri, 26 Sep 2008 22:25:13 +0200 (CEST) Message-ID: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Date: Fri, 26 Sep 2008 22:25:13 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Fri, 26 Sep 2008 22:26:09 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org RGVhciBKdWVyZ2VuLAoKVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzLiBSZXNwb25zZXMgYXJl IGluLWxpbmXigKYKCj4+IFdpdGggdGhpcyBtYWlsIHdlIHdhbnQgdG8gc3RhcnQgYSBXR0xDIGZv ciB0aGUgZHJhZnQgTkVUQ09ORiBvdmVyCj4+IFRMUywgd2hpY2ggaXMgcHJvcG9zZWQgdG8gcHVi bGlzaCBhcyBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQy4KCj4gSSBoYXZlIHJlYWQgPGRyYWZ0LWll dGYtbmV0Y29uZi10bHMtMDQudHh0PiBhbmQgaGVyZSBhcmUgbXkgY29tbWVudHM6Cgo+IGEpIEkg YW0gd29uZGVyaW5nIGFib3V0IFBTSyBzdXBwb3J0LiBSRkMgNDI3OSBzYXlzIGluIHRoZQo+IGFw cGxpY2FiaWxpdHkgc3RhdGVtZW50Ogo+Cj4gIFRoZSBjaXBoZXJzdWl0ZXMgZGVmaW5lZCBpbiB0 aGlzIGRvY3VtZW50IGFyZSBpbnRlbmRlZCBmb3IgYSByYXRoZXIKPiAgbGltaXRlZCBzZXQgb2Yg YXBwbGljYXRpb25zLCB1c3VhbGx5IGludm9sdmluZyBvbmx5IGEgdmVyeSBzbWFsbAo+ICBudW1i ZXIgb2YgY2xpZW50cyBhbmQgc2VydmVycy4gIEV2ZW4gaW4gc3VjaCBlbnZpcm9ubWVudHMsIG90 aGVyCj4gIGFsdGVybmF0aXZlcyBtYXkgYmUgbW9yZSBhcHByb3ByaWF0ZS4KPgo+IFdpdGggTkVU TU9EIGRlcGxveWVkIG9uIG1hbnkgYnJpZGdlcyBhbmQgcm91dGVycyBhbmQgc29tZSBob3N0Cj4g c3lzdGVtcyBpbiB0aGUgZnV0dXJlLCB3ZSBtaWdodCBoYXZlIGEgc21hbGwgbnVtYmVyIG9mIGNs aWVudHMgd2l0aAo+IGEgbGFyZ2UgbnVtYmVyIG9mIHNlcnZlcnMgYW5kIGEga2V5IG1hbmFnZW1l bnQgcHJvYmxlbS4KCj4gU3VtbWFyeTogSSB0aGluayB0aGUgZG9jdW1lbnQgaGFzIGltcHJvdmVk IHF1aXRlIGEgYml0IHNpbmNlIGl0cyBlYXJseQo+IGRheXMuIEkgYW0gc3RpbGwgbm90IDEwMCUg Y29udmluY2VkIGFib3V0IHRoZSBQU0sgc3VwcG9ydCBhbmQgaXQgYmVpbmcKPiByZXF1aXJlZCB0 byBpbXBsZW1lbnQuCgpJcyBpdCBzdWZmaWNpZW50IHRvIHVzZSB0aGUga2V5IHdvcmQgIk1BWSIg YXMgZm9sbG93aW5nIHRvIG1ha2Ugb3B0aW9uYWwKdGhlIFBTSyB1c2U/IE9yIGRvIHlvdSBwcmVm ZXIgdG8gZW50aXJlbHkgcmVtb3ZlIFBTSyByZWxhdGVkIHRleHQ/IEluIHRoZQpmaXJzdCBjYXNl OgoKT0xEOgoKICAgU2VjdGlvbiAzLjEgZGVzY3JpYmVzIGhvdyB0aGUgY2xpZW50IGF1dGhlbnRp Y2F0ZXMgdGhlIHNlcnZlciBpZgogICBwdWJsaWMga2V5IGNlcnRpZmljYXRlcyBhcmUgcHJvdmlk ZWQgYnkgdGhlIHNlcnZlciwgc2VjdGlvbiAzLjIKICAgZGVzY3JpYmVzIGhvdyB0aGUgc2VydmVy IGF1dGhlbnRpY2F0ZXMgdGhlIGNsaWVudCBpZiBwdWJsaWMga2V5CiAgIGNlcnRpZmljYXRlcyBh cmUgcHJvdmlkZWQgYnkgdGhlIGNsaWVudCwgYW5kIHNlY3Rpb24gMy4zIGRlc2NyaWJlcyBob3cK ICAgdGhlIGNsaWVudCBhbmQgc2VydmVyIG11dHVhbGx5IGF1dGhlbnRpY2F0ZSBvbmUgYW5vdGhl ciB1c2luZyBhIHByZS0KICAgc2hhcmVkIGtleSAoUFNLKS4KCk5FVzoKCiAgIFNlY3Rpb24gMy4x IGRlc2NyaWJlcyBob3cgdGhlIGNsaWVudCBhdXRoZW50aWNhdGVzIHRoZSBzZXJ2ZXIgaWYKICAg cHVibGljIGtleSBjZXJ0aWZpY2F0ZXMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2ZXIsIHNlY3Rp b24gMy4yCiAgIGRlc2NyaWJlcyBob3cgdGhlIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBjbGll bnQgaWYgcHVibGljIGtleQogICBjZXJ0aWZpY2F0ZXMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBjbGll bnQsIGFuZCBzZWN0aW9uIDMuMyBkZXNjcmliZXMgaG93CiAgIHRoZSBjbGllbnQgYW5kIHNlcnZl ciBNQVkgbXV0dWFsbHkgYXV0aGVudGljYXRlIG9uZSBhbm90aGVyIHVzaW5nIGEKICAgcHJlLXNo YXJlZCBrZXkgKFBTSykuIF5eXgoKPiBiKSBTZWN0aW9uIDQgcmVxdWlyZXMgdG8gaW1wbGVtZW50 IFRMU19ESEVfUFNLX1dJVEhfQUVTXzEyOF9DQkNfU0hBCj4gIChwbGVhc2UgYWRkIGEgcmVmZXJl bmNlIHRvIFJGQyA0Mjc5IHdoZXJlIHRoaXMgY2lwaGVyIHN1aXRlIGlzCj4gIGRlZmluZWQgdG8g aGVscCB0aGUgcmVhZGVyKSBidXQgZG9lcyBub3Qgc3BlbGwgb3V0IGFueSBvdGhlciBjaXBoZXIK PiAgc3VpdGUgcmVxdWlyZW1lbnQsIGVzc2VudGlhbGx5IG1ha2luZwo+ICBUTFNfREhFX1BTS19X SVRIX0FFU18xMjhfQ0JDX1NIQSB0aGUgY29tbW9uIGRlbm9taW5hdG9yLiBQZXJoYXBzCj4gIHRo ZXJlIG5lZWRzIHRvIGJlIG1vcmUgdGV4dCBhYm91dCByZXF1aXJlZCB0byBpbXBsZW1lbnQgY2lw aGVyCj4gIHN1aXRlcyBvciBwb2ludGVycyB0byAic3RhbmRhcmQiIHJlcXVpcmVkIHRvIGltcGxl bWVudCBUTFMgY2lwaGVyCj4gIHN1aXRlcyB0aGF0IGFwcGx5IGhlcmUgYXMgd2VsbC4KClllcywg dGhpcyBpcyB0cnVlLiBXaXRoIFRMUywgYW5kIGluIHRoZSBhYnNlbmNlIG9mIGFuIGFwcGxpY2F0 aW9uIHByb2ZpbGUKc3RhbmRhcmQgc3BlY2lmeWluZyBvdGhlcndpc2UsIGEgVExTLWNvbXBsaWFu dCBhcHBsaWNhdGlvbiBNVVNUIGltcGxlbWVudAphIGNpcGhlciBzdWl0ZSwgd2hpY2ggdmFyaWVz IHdpdGggdGhlIFRMUyB2ZXJzaW9uLCBpLmUuOgoKVExTIDEuMjogVExTX1JTQV9XSVRIX0FFU18x MjhfQ0JDX1NIQQpUTFMgMS4xOiBUTFNfUlNBX1dJVEhfM0RFU19FREVfQ0JDX1NIQQpUTFMgMS4w OiBUTFNfREhFX0RTU19XSVRIXzNERVNfRURFX0NCQ19TSEEKClBsZWFzZSBkb24ndCBoZXNpdGF0 ZSB0byBwcm9wb3NlIGEgYmV0dGVyIHRleHQsIGhlcmUgaXMgYSB0ZW50YXRpdmU6CgpPTEQ6Cgog ICBBIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcHJvdG9jb2wgc3BlY2lmaWVkIGlu IHRoaXMgZG9jdW1lbnQKICAgTVVTVCBpbXBsZW1lbnQgdGhlIGNpcGhlciBzdWl0ZSBUTFNfREhF X1BTS19XSVRIX0FFU18xMjhfQ0JDX1NIQSBhbmQKICAgTUFZIGltcGxlbWVudCBhbnkgVExTIGNp cGhlciBzdWl0ZSB0aGF0IHByb3ZpZGVzIG11dHVhbCBhdXRoZW50aWNhdGlvbi4KCk5FVzoKCiAg IEEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIG9mIHRoZSBwcm90b2NvbCBzcGVjaWZpZWQgaW4g dGhpcyBkb2N1bWVudAogICBNQVkgaW1wbGVtZW50IGFueSBUTFMgY2lwaGVyIHN1aXRlIHRoYXQg cHJvdmlkZXMgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLgoKICAgRm9yIGF1dGhlbnRpY2F0aW9uIGJh c2VkIG9uIFBTS3MsIGEgY29tcGxpYW50IGltcGxlbWVudGF0aW9uIE1VU1QKICAgaW1wbGVtZW50 IHRoZSBjaXBoZXIgc3VpdGUgVExTX0RIRV9QU0tfV0lUSF9BRVNfMTI4X0NCQ19TSEEuCgogICBG cm8gYXV0aGVudGljYXRpb24gYmFzZWQgb24gcHVibGljIGtleSBjZXJ0aWZpY2F0ZXMsIGEgY29t cGxpYW50CiAgIGltcGxlbWVudGF0aW9uIE1VU1QgaW1wbGVtZW50IHRoZSAnbWFuZGF0b3J5IGNp cGhlciBzdWl0ZScgc3BlY2lmaWVkIGJ5CiAgIGVhY2ggVExTIHZlcnNpb24gKGUuZy4gIHdpdGgg VExTIDEuMiwgdGhlIG1hbmRvdGFyeSBjaXBoZXIgc3VpdGUgaXMKICAgVExTX1JTQV9XSVRIX0FF U18xMjhfQ0JDX1NIQSkuCgo+IGMpIEkgc3VnZ2VzdCB0byByZW1vdmUgInNpbXBsZSIgZnJvbSB0 aGUgdGV4dCBpbiB0aGUgaW50cm9kdWN0aW9uLgoKT0suCgo+IGQpIFdoYXQgZG9lcyAiaGlnaGx5 IHJlY29tbWVuZGVkIiBtZWFuIGluIHRlcm1zIG9mIElFVEYgdGVybWlub2xvZ3k/Cj4gIElzIHRo aXMgdGhlIHNhbWUgYXMgUkVDT01NRU5ERUQ/IEkgc3VnZ2VzdCB0byBzdGljayB0byB0aGUgd2Vs bAo+ICBkZWZpbmVkIGFuZCB1bmRlcnN0b29kIElFVEYgdGVybWlub2xvZ3kuCgpPSy4KCkJlc3Qg cmVnYXJkcywKQmFkcmEKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KTmV0Y29uZiBtYWlsaW5nIGxpc3QKTmV0Y29uZkBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYK From netconf-bounces@ietf.org Fri Sep 26 23:05:57 2008 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 096203A6A97; Fri, 26 Sep 2008 23:05:57 -0700 (PDT) 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 3396628C144 for ; Fri, 26 Sep 2008 23:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 IffeI+E6SYft for ; Fri, 26 Sep 2008 23:05:55 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 7F1C73A69FF for ; Fri, 26 Sep 2008 23:05:55 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7U0069KBM79M@usaga01-in.huawei.com> for netconf@ietf.org; Fri, 26 Sep 2008 23:06:07 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7U006VNBM6DV@usaga01-in.huawei.com> for netconf@ietf.org; Fri, 26 Sep 2008 23:06:07 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sat, 27 Sep 2008 14:05:51 +0800 Date: Sat, 27 Sep 2008 14:05:51 +0800 From: fanhuaxiang 90002624 In-reply-to: To: "Ersue, Mehmet (NSN - DE/Munich)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, in section 2, it says, "The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes" I wanna ask why immediately instead of sending pening writes before close down the connection. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Fri Sep 26 23:05:57 2008 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 096203A6A97; Fri, 26 Sep 2008 23:05:57 -0700 (PDT) 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 3396628C144 for ; Fri, 26 Sep 2008 23:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 IffeI+E6SYft for ; Fri, 26 Sep 2008 23:05:55 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 7F1C73A69FF for ; Fri, 26 Sep 2008 23:05:55 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7U0069KBM79M@usaga01-in.huawei.com> for netconf@ietf.org; Fri, 26 Sep 2008 23:06:07 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7U006VNBM6DV@usaga01-in.huawei.com> for netconf@ietf.org; Fri, 26 Sep 2008 23:06:07 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sat, 27 Sep 2008 14:05:51 +0800 Date: Sat, 27 Sep 2008 14:05:51 +0800 From: fanhuaxiang 90002624 In-reply-to: To: "Ersue, Mehmet (NSN - DE/Munich)" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, in section 2, it says, "The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes" I wanna ask why immediately instead of sending pening writes before close down the connection. _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 02:06:24 2008 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 50D0A3A68C2; Sat, 27 Sep 2008 02:06:24 -0700 (PDT) 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 4A80D3A68C2 for ; Sat, 27 Sep 2008 02:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lpR866EmrrTI for ; Sat, 27 Sep 2008 02:06:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 309593A68EE for ; Sat, 27 Sep 2008 02:06:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F104FC0086; Sat, 27 Sep 2008 11:06:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MPiJRJrZYZON; Sat, 27 Sep 2008 11:06:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE605C0079; Sat, 27 Sep 2008 11:06:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 821807BAEEA; Sat, 27 Sep 2008 11:06:22 +0200 (CEST) Date: Sat, 27 Sep 2008 11:06:22 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080927090622.GA431@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > Hi, > in section 2, it says, > "The other party MUST respond with a close_notify alert of > its own and close down the connection immediately, discarding any > pending writes" > I wanna ask why immediately instead of sending pening writes before > close down the connection. And I like to add whether it is normal practice that the TLS teardown procedure is application protocol specific. RFC 5246 section 7.2.1 discusses closure alerts in TLS 1.2 and I like to understand why we need additional text for NETCONF over TLS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 BremeFrom netconf-bounces@ietf.org Sat Sep 27 02:06:24 2008 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 50D0A3A68C2; Sat, 27 Sep 2008 02:06:24 -0700 (PDT) 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 4A80D3A68C2 for ; Sat, 27 Sep 2008 02:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 lpR866EmrrTI for ; Sat, 27 Sep 2008 02:06:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 309593A68EE for ; Sat, 27 Sep 2008 02:06:21 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F104FC0086; Sat, 27 Sep 2008 11:06:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MPiJRJrZYZON; Sat, 27 Sep 2008 11:06:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AE605C0079; Sat, 27 Sep 2008 11:06:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 821807BAEEA; Sat, 27 Sep 2008 11:06:22 +0200 (CEST) Date: Sat, 27 Sep 2008 11:06:22 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080927090622.GA431@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , "Ersue, Mehmet (NSN - DE/Munich)" , netconf@ietf.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > Hi, > in section 2, it says, > "The other party MUST respond with a close_notify alert of > its own and close down the connection immediately, discarding any > pending writes" > I wanna ask why immediately instead of sending pening writes before > close down the connection. And I like to add whether it is normal practice that the TLS teardown procedure is application protocol specific. RFC 5246 section 7.2.1 discusses closure alerts in TLS 1.2 and I like to understand why we need additional text for NETCONF over TLS. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759n, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 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 Sep 27 02:11:11 2008 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 D86193A6A96; Sat, 27 Sep 2008 02:11:11 -0700 (PDT) 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 2AEDF3A69EB for ; Sat, 27 Sep 2008 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 PYd3P3kes8Eu for ; Sat, 27 Sep 2008 02:11:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19F2A3A6A17 for ; Sat, 27 Sep 2008 02:11:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05724C0086; Sat, 27 Sep 2008 11:10:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XM9FHcKRnlek; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86E6BC0079; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 681827BAF25; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Date: Sat, 27 Sep 2008 11:10:42 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927091042.GB431@elstar.local> Mail-Followup-To: badra@isima.fr, mehmet.ersue@nsn.com, netconf@ietf.org References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 26, 2008 at 10:25:13PM +0200, badra@isima.fr wrote: > OLD: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 describes how > the client and server mutually authenticate one another using a pre- > shared key (PSK). > > NEW: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 describes how > the client and server MAY mutually authenticate one another using a > pre-shared key (PSK). ^^^ OK > OLD: > > A compliant implementation of the protocol specified in this document > MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and > MAY implement any TLS cipher suite that provides mutual authentication. > > NEW: > > A compliant implementation of the protocol specified in this document > MAY implement any TLS cipher suite that provides mutual authentication. > > For authentication based on PSKs, a compliant implementation MUST > implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. I suggest to add "[RFC4279]" to end of the sentence so that it is easy to find the definition. > Fro authentication based on public key certificates, a compliant > implementation MUST implement the 'mandatory cipher suite' specified by > each TLS version (e.g. with TLS 1.2, the mandotary cipher suite is > TLS_RSA_WITH_AES_128_CBC_SHA). Please s/Fro/For and add "[RFC 5246]" as a service to the readers. /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 Sep 27 02:11:11 2008 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 D86193A6A96; Sat, 27 Sep 2008 02:11:11 -0700 (PDT) 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 2AEDF3A69EB for ; Sat, 27 Sep 2008 02:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 PYd3P3kes8Eu for ; Sat, 27 Sep 2008 02:11:10 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 19F2A3A6A17 for ; Sat, 27 Sep 2008 02:11:10 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 05724C0086; Sat, 27 Sep 2008 11:10:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id XM9FHcKRnlek; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 86E6BC0079; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 681827BAF25; Sat, 27 Sep 2008 11:10:42 +0200 (CEST) Date: Sat, 27 Sep 2008 11:10:42 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927091042.GB431@elstar.local> Mail-Followup-To: badra@isima.fr, mehmet.ersue@nsn.com, netconf@ietf.org References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 26, 2008 at 10:25:13PM +0200, badra@isima.fr wrote: > OLD: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 describes how > the client and server mutually authenticate one another using a pre- > shared key (PSK). > > NEW: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 describes how > the client and server MAY mutually authenticate one another using a > pre-shared key (PSK). ^^^ OK > OLD: > > A compliant implementation of the protocol specified in this document > MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA and > MAY implement any TLS cipher suite that provides mutual authentication. > > NEW: > > A compliant implementation of the protocol specified in this document > MAY implement any TLS cipher suite that provides mutual authentication. > > For authentication based on PSKs, a compliant implementation MUST > implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. I suggest to add "[RFC4279]" to end of the sentence so that it is easy to find the definition. > Fro authentication based on public key certificates, a compliant > implementation MUST implement the 'mandatory cipher suite' specified by > each TLS version (e.g. with TLS 1.2, the mandotary cipher suite is > TLS_RSA_WITH_AES_128_CBC_SHA). Please s/Fro/For and add "[RFC 5246]" as a service to the readers. /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 Sep 27 07:16:16 2008 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 DA1843A6405; Sat, 27 Sep 2008 07:16:16 -0700 (PDT) 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 3FFA93A6405 for ; Sat, 27 Sep 2008 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFWutJxtFJn9 for ; Sat, 27 Sep 2008 07:16:15 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 439A13A63D2 for ; Sat, 27 Sep 2008 07:16:14 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8REoSiC557164; Sat, 27 Sep 2008 15:50:28 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 15:49:33 +0200 (CEST) Message-ID: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> In-Reply-To: <20080927090622.GA431@elstar.local> References: <20080927090622.GA431@elstar.local> Date: Sat, 27 Sep 2008 15:49:33 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 15:50:31 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: >> Hi, >> in section 2, it says, >> "The other party MUST respond with a close_notify alert of >> its own and close down the connection immediately, discarding any >> pending writes" >> I wanna ask why immediately instead of sending pening writes before >> close down the connection. > > And I like to add whether it is normal practice that the TLS teardown > procedure is application protocol specific. RFC 5246 section 7.2.1 > discusses closure alerts in TLS 1.2 and I like to understand why we > need additional text for NETCONF over TLS. I think we should correct that. What about adopting the text of section 4.4 of syslog-tls (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt). "A TLS client MUST close the associated TLS connection if the connection is not expected to deliver any NETCONF messages later. It MUST send a TLS close_notify alert before closing the connection. A client MAY choose to not wait for the server's close_notify alert and simply close the connection, thus generating an incomplete close on the seFrom netconf-bounces@ietf.org Sat Sep 27 07:16:16 2008 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 DA1843A6405; Sat, 27 Sep 2008 07:16:16 -0700 (PDT) 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 3FFA93A6405 for ; Sat, 27 Sep 2008 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFWutJxtFJn9 for ; Sat, 27 Sep 2008 07:16:15 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 439A13A63D2 for ; Sat, 27 Sep 2008 07:16:14 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8REoSiC557164; Sat, 27 Sep 2008 15:50:28 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 15:49:33 +0200 (CEST) Message-ID: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> In-Reply-To: <20080927090622.GA431@elstar.local> References: <20080927090622.GA431@elstar.local> Date: Sat, 27 Sep 2008 15:49:33 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 15:50:31 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: >> Hi, >> in section 2, it says, >> "The other party MUST respond with a close_notify alert of >> its own and close down the connection immediately, discarding any >> pending writes" >> I wanna ask why immediately instead of sending pening writes before >> close down the connection. > > And I like to add whether it is normal practice that the TLS teardown > procedure is application protocol specific. RFC 5246 section 7.2.1 > discusses closure alerts in TLS 1.2 and I like to understand why we > need additional text for NETCONF over TLS. I think we should correct that. What about adopting the text of section 4.4 of syslog-tls (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt). "A TLS client MUST close the associated TLS connection if the connection is not expected to deliver any NETCONF messages later. It MUST send a TLS close_notify alert before closing the connection. A client MAY choose to not wait for the server's close_notify alert and simply close the connection, thus generating an incomplete close on rver side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the client (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a server MAY close the connection. The server MUST attempt to initiate an exchange of close_notify alerts with the client before closing the connection. Servers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Best regards, _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the client (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a server MAY close the connection. The server MUST attempt to initiate an exchange of close_notify alerts with the client before closing the connection. Servers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Best regards, _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 08:52:32 2008 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 2AA113A68F0; Sat, 27 Sep 2008 08:52:32 -0700 (PDT) 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 69D1F3A68F0 for ; Sat, 27 Sep 2008 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 dVtkeEF3mS3M for ; Sat, 27 Sep 2008 08:52:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9A9BD3A68C8 for ; Sat, 27 Sep 2008 08:52:29 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1C6C0054; Sat, 27 Sep 2008 17:41:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z7TUBmmkewTo; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAB40C0035; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B18717BB0C4; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Date: Sat, 27 Sep 2008 17:41:19 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927154119.GA803@elstar.local> Mail-Followup-To: badra@isima.fr, fanhuaxiang? 90002624? , ? References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt 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, Sep 27, 2008 at 03:49:33PM +0200, badra@isima.fr wrote: > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > >> Hi, > >> in section 2, it says, > >> "The other party MUST respond with a close_notify alert of > >> its own and close down the connection immediately, discarding any > >> pending writes" > >> I wanna ask why immediately instead of sending pening writes before > >> close down the connection. > > > > And I like to add whether it is normal practice that the TLS teardown > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > discusses closure alerts in TLS 1.2 and I like to understand why we > > need additional text for NETCONF over TLS. > > > I think we should correct that. What about adopting the text of section > 4.4 of syslogFrom netconf-bounces@ietf.org Sat Sep 27 08:52:32 2008 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 2AA113A68F0; Sat, 27 Sep 2008 08:52:32 -0700 (PDT) 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 69D1F3A68F0 for ; Sat, 27 Sep 2008 08:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 dVtkeEF3mS3M for ; Sat, 27 Sep 2008 08:52:30 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 9A9BD3A68C8 for ; Sat, 27 Sep 2008 08:52:29 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1C6C0054; Sat, 27 Sep 2008 17:41:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z7TUBmmkewTo; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CAB40C0035; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B18717BB0C4; Sat, 27 Sep 2008 17:41:19 +0200 (CEST) Date: Sat, 27 Sep 2008 17:41:19 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927154119.GA803@elstar.local> Mail-Followup-To: badra@isima.fr, fanhuaxiang? 90002624? , ? References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt 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, Sep 27, 2008 at 03:49:33PM +0200, badra@isima.fr wrote: > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > >> Hi, > >> in section 2, it says, > >> "The other party MUST respond with a close_notify alert of > >> its own and close down the connection immediately, discarding any > >> pending writes" > >> I wanna ask why immediately instead of sending pening writes before > >> close down the connection. > > > > And I like to add whether it is normal practice that the TLS teardown > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > discusses closure alerts in TLS 1.2 and I like to understand why we > > need additional text for NETCONF over TLS. > > > I think we should correct that. What about adopting the text of section > 4.4 of -tls > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt). > > "A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any NETCONF messages later. It > MUST send a TLS close_notify alert before closing the connection. A > client MAY choose to not wait for the server's close_notify alert and > simply close the connection, thus generating an incomplete close on > the server side. Once the server gets a close_notify from the > client, it MUST reply with a close_notify unless it becomes aware > that the connection has already been closed by the client (e.g., the > closure was indicated by TCP). > > When no data is received from a connection for a long time (where the > application decides what "long" means), a server MAY close the > connection. The server MUST attempt to initiate an exchange of > close_notify alerts with the client before closing the connection. > Servers that are unprepared to receive any more data MAY close the > connection after sending the close_notify alert, thus generating an > incomplete close on the client side. When the client has received > the close_notify alert from the server and still has pending data to > send, it SHOULD send the pending data before sending the close_notify > alert." Can someone explain to me _why_ all this detail is needed? The SSH transport mapping does not spell how how the SSH teardown is done. So why do we need to be that specific with TLS? /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 syslog-tls > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transport-tls-13.txt). > > "A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any NETCONF messages later. It > MUST send a TLS close_notify alert before closing the connection. A > client MAY choose to not wait for the server's close_notify alert and > simply close the connection, thus generating an incomplete close on > the server side. Once the server gets a close_notify from the > client, it MUST reply with a close_notify unless it becomes aware > that the connection has already been closed by the client (e.g., the > closure was indicated by TCP). > > When no data is received from a connection for a long time (where the > application decides what "long" means), a server MAY close the > connection. The server MUST attempt to initiate an exchange of > close_notify alerts with the client before closing the connection. > Servers that are unprepared to receive any more data MAY close the > connection after sending the close_notify alert, thus generating an > incomplete close on the client side. When the client has received > the close_notify alert from the server and still has pending data to > send, it SHOULD send the pending data before sending the close_notify > alert." Can someone explain to me _why_ all this detail is needed? The SSH transport mapping does not spell how how the SSH teardown is done. So why do we need to be that specific with TLS? /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 Sep 27 08:54:52 2008 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 961E13A6A03; Sat, 27 Sep 2008 08:54:52 -0700 (PDT) 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 AEDDE3A69E3 for ; Sat, 27 Sep 2008 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7SEQK97pLDq for ; Sat, 27 Sep 2008 08:54:51 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B89723A68F0 for ; Sat, 27 Sep 2008 08:54:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RGsRjm1040470; Sat, 27 Sep 2008 17:54:27 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 17:53:29 +0200 (CEST) Message-ID: <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> In-Reply-To: <20080927154119.GA803@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> Date: Sat, 27 Sep 2008 17:53:29 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 17:54:27 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?q?_Re=3A=C2=A0_WGLC_for_draft-ietf-netconf-t?= =?utf-8?b?wqBscy0wNC50eHQ=?= 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, Sep 27, 2008 at 03:49:33PM +0200, badra@isima.fr wrote: >> > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > Can someone explain to me _why_ all this detail is needed? The SSH > transport mapping does not spell how how the SSH teardown is done. > So why do we need to be that specific with TLS? > > /js Well, I think we can find the same text in all "Application over TLS" documents, and there was no objection on integrating such text in those documents, which can IMO improve the readability. Please don't hesitate to propose your text (to the Connection Closure Section) if you prefer to don't have this detail. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 08:54:52 2008 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 961E13A6A03; Sat, 27 Sep 2008 08:54:52 -0700 (PDT) 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 AEDDE3A69E3 for ; Sat, 27 Sep 2008 08:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7SEQK97pLDq for ; Sat, 27 Sep 2008 08:54:51 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B89723A68F0 for ; Sat, 27 Sep 2008 08:54:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RGsRjm1040470; Sat, 27 Sep 2008 17:54:27 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 17:53:29 +0200 (CEST) Message-ID: <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> In-Reply-To: <20080927154119.GA803@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> Date: Sat, 27 Sep 2008 17:53:29 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 17:54:27 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?q?_Re=3A=C2=A0_WGLC_for_draft-ietf-netconf-t?= =?utf-8?b?wqBscy0wNC50eHQ=?= 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, Sep 27, 2008 at 03:49:33PM +0200, badra@isima.fr wrote: >> > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang 90002624 wrote: > Can someone explain to me _why_ all this detail is needed? The SSH > transport mapping does not spell how how the SSH teardown is done. > So why do we need to be that specific with TLS? > > /js Well, I think we can find the same text in all "Application over TLS" documents, and there was no objection on integrating such text in those documents, which can IMO improve the readability. Please don't hesitate to propose your text (to the Connection Closure Section) if you prefer to don't have this detail. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 09:15:19 2008 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 77E563A688B; Sat, 27 Sep 2008 09:15:19 -0700 (PDT) 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 C69F63A688B for ; Sat, 27 Sep 2008 09:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 p2DVKfcoHrhQ for ; Sat, 27 Sep 2008 09:15:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC4BC3A67B0 for ; Sat, 27 Sep 2008 09:15:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9898C0035; Sat, 27 Sep 2008 18:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wfKT+F50dI01; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C28AC0039; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8035B7BB320; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Date: Sat, 27 Sep 2008 18:14:32 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927161432.GA918@elstar.local> Mail-Followup-To: badra@isima.fr, washam.fan@huawei.com, ? References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ?? WGLC for draft-ietf-netconf-t??ls-04.txt 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, Sep 27, 2008 at 05:53:29PM +0200, badra@isima.fr wrote: > Well, I think we can find the same text in all "Application over TLS" > documents, and there was no objection on integrating such text in those > documents, which can IMO improve the readability. This does not really answer my question. Why is the text in the TLS specs not sufficient? We should IMHO not include text is the TLS specifications already cover things. /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 Sep 27 09:15:19 2008 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 77E563A688B; Sat, 27 Sep 2008 09:15:19 -0700 (PDT) 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 C69F63A688B for ; Sat, 27 Sep 2008 09:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 p2DVKfcoHrhQ for ; Sat, 27 Sep 2008 09:15:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CC4BC3A67B0 for ; Sat, 27 Sep 2008 09:15:17 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9898C0035; Sat, 27 Sep 2008 18:14:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wfKT+F50dI01; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C28AC0039; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8035B7BB320; Sat, 27 Sep 2008 18:14:32 +0200 (CEST) Date: Sat, 27 Sep 2008 18:14:32 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080927161432.GA918@elstar.local> Mail-Followup-To: badra@isima.fr, washam.fan@huawei.com, ? References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ?? WGLC for draft-ietf-netconf-t??ls-04.txt 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, Sep 27, 2008 at 05:53:29PM +0200, badra@isima.fr wrote: > Well, I think we can find the same text in all "Application over TLS" > documents, and there was no objection on integrating such text in those > documents, which can IMO improve the readability. This does not really answer my question. Why is the text in the TLS specs not sufficient? We should IMHO not include text is the TLS specifications already cover things. /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 Sep 27 10:19:53 2008 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 8663B3A6804; Sat, 27 Sep 2008 10:19:53 -0700 (PDT) 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 A4A523A6804 for ; Sat, 27 Sep 2008 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+4Y6BLF3F4Y for ; Sat, 27 Sep 2008 10:19:51 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id AF4EE3A67B0 for ; Sat, 27 Sep 2008 10:19:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RIJ320921660; Sat, 27 Sep 2008 19:19:03 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 19:18:05 +0200 (CEST) Message-ID: <62308.88.164.98.77.1222535885.squirrel@www.isima.fr> In-Reply-To: <20080927161432.GA918@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> Date: Sat, 27 Sep 2008 19:18:05 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 19:19:03 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Sat, Sep 27, 2008 at 05:53:29PM +0200, badra@isima.fr wrote: > >> Well, I think we can find the same text in all "Application over TLS" >> documents, and there was no objection on integrating such text in those >> documents, which can IMO improve the readability. > > This does not really answer my question. Why is the text in the TLS > specs not sufficient? We should IMHO not include text is the TLS > specifications already cover things. > Well, in this case we should remove the last two paragraphs from the section 2.2. But I don't think it is a good idea. Keep it as it is will improve the readability. Based on your review on version 01 (http://www.ops.ietf.org/lists/netconf/netconf.2008/msg00154.html), Section 2.2 has been detailed as it is today. Please kindly propose which portion you prefer to read in the document, and which one you don't. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 10:19:53 2008 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 8663B3A6804; Sat, 27 Sep 2008 10:19:53 -0700 (PDT) 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 A4A523A6804 for ; Sat, 27 Sep 2008 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.192 X-Spam-Level: X-Spam-Status: No, score=-0.192 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+4Y6BLF3F4Y for ; Sat, 27 Sep 2008 10:19:51 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id AF4EE3A67B0 for ; Sat, 27 Sep 2008 10:19:50 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RIJ320921660; Sat, 27 Sep 2008 19:19:03 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 19:18:05 +0200 (CEST) Message-ID: <62308.88.164.98.77.1222535885.squirrel@www.isima.fr> In-Reply-To: <20080927161432.GA918@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> Date: Sat, 27 Sep 2008 19:18:05 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 19:19:03 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > On Sat, Sep 27, 2008 at 05:53:29PM +0200, badra@isima.fr wrote: > >> Well, I think we can find the same text in all "Application over TLS" >> documents, and there was no objection on integrating such text in those >> documents, which can IMO improve the readability. > > This does not really answer my question. Why is the text in the TLS > specs not sufficient? We should IMHO not include text is the TLS > specifications already cover things. > Well, in this case we should remove the last two paragraphs from the section 2.2. But I don't think it is a good idea. Keep it as it is will improve the readability. Based on your review on version 01 (http://www.ops.ietf.org/lists/netconf/netconf.2008/msg00154.html), Section 2.2 has been detailed as it is today. Please kindly propose which portion you prefer to read in the document, and which one you don't. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 14:31:24 2008 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 794A83A68D1; Sat, 27 Sep 2008 14:31:24 -0700 (PDT) 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 3DCB03A68D1 for ; Sat, 27 Sep 2008 14:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSAJbJhT1kpz for ; Sat, 27 Sep 2008 14:31:22 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 33F193A68AA for ; Sat, 27 Sep 2008 14:31:22 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RMUFeh745650; Sat, 27 Sep 2008 23:30:15 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 23:29:21 +0200 (CEST) Message-ID: <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> In-Reply-To: <20080927161432.GA918@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> Date: Sat, 27 Sep 2008 23:29:21 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 23:30:20 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgPz/CoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1u?= =?utf-8?q?et_conf-t_=3F=3Fls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > This does not really answer my question. Why is the text in the TLS > specs not sufficient? We should IMHO not include text is the TLS > specifications already cover things. Dear Juergen, What about modify the actual text as follows: OLD: 2.2. Connection Closure Either NETCONF peer MAY stop the NETCONF connection at any time and therefore notify the other NETCONF peer that no more data on this channel will be sent and that any data received after a closure request will be ignored. This MAY happen when no data is received from a connection for a long time, where the application decides what "long" means. TLS has the ability for secure connection closure using the Alert protocol. When the NETCONF peer closes the NETCONF connection, it MUST send a TLS close_notify alert before closing the TCP connection. Any data received after a closure alert is ignored. Unless a fatal error has occurred, each party is required to send a close_notify alert before closing the write side of the connection [RFC5246]. TFrom netconf-bounces@ietf.org Sat Sep 27 14:31:24 2008 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 794A83A68D1; Sat, 27 Sep 2008 14:31:24 -0700 (PDT) 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 3DCB03A68D1 for ; Sat, 27 Sep 2008 14:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_40=-0.185, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSAJbJhT1kpz for ; Sat, 27 Sep 2008 14:31:22 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 33F193A68AA for ; Sat, 27 Sep 2008 14:31:22 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8RMUFeh745650; Sat, 27 Sep 2008 23:30:15 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sat, 27 Sep 2008 23:29:21 +0200 (CEST) Message-ID: <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> In-Reply-To: <20080927161432.GA918@elstar.local> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> Date: Sat, 27 Sep 2008 23:29:21 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sat, 27 Sep 2008 23:30:20 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgPz/CoFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1u?= =?utf-8?q?et_conf-t_=3F=3Fls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org > This does not really answer my question. Why is the text in the TLS > specs not sufficient? We should IMHO not include text is the TLS > specifications already cover things. Dear Juergen, What about modify the actual text as follows: OLD: 2.2. Connection Closure Either NETCONF peer MAY stop the NETCONF connection at any time and therefore notify the other NETCONF peer that no more data on this channel will be sent and that any data received after a closure request will be ignored. This MAY happen when no data is received from a connection for a long time, where the application decides what "long" means. TLS has the ability for secure connection closure using the Alert protocol. When the NETCONF peer closes the NETCONF connection, it MUST send a TLS close_notify alert before closing the TCP connection. Any data received after a closure alert is ignored. Unless a fatal error has occurred, each party is required to send a close_notify alert before closing the write side of the connection [RFC524he other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. NEW: 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. This notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert is ignored. Like that, if people need more information on this alert behaviour, they can refer to TLS document. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf 6]. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. NEW: 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. This notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert is ignored. Like that, if people need more information on this alert behaviour, they can refer to TLS document. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 18:09:41 2008 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 14FC03A6873; Sat, 27 Sep 2008 18:09:41 -0700 (PDT) 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 3B6243A68B6 for ; Sat, 27 Sep 2008 18:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 KdLN7Ajd9-+N for ; Sat, 27 Sep 2008 18:09:38 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 72FCB3A6842 for ; Sat, 27 Sep 2008 18:09:38 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7V00DB1SJILK@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 18:09:18 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7V008D8SJG55@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 18:09:18 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 09:09:01 +0800 Date: Sun, 28 Sep 2008 09:09:01 +0800 From: fanhuaxiang 90002624 In-reply-to: <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> Cc: =?iso-8859-7?Q?=C2?= Subject: [Netconf] =?iso-8859-7?b?IFJlOiBSZTqgPz+gV0dMQ6Bmb3KgZHJhZnQtaWV0?= =?iso-8859-7?q?f-net_conf-t=3F=3Fls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, comments inline. > > This does not really answer my question. Why is the text in the TLS > > specs not sufficient? We should IMHO not include text is the TLS > > specifications already cover things. > > Dear Juergen, > > What about modify the actual text as follows: > > OLD: > > 2.2. Connection Closure > > Either NETCONF peer MAY stop the NETCONF connection at any time and > therefore notify the other NETCONF peer that no more data on this > channel will be sent and that any data received after a closure > request will be ignored. This MAY happen when no data is received > from a connection for a long time, where the application > decides what > "long" means. > > TLS has the ability From netconf-bounces@ietf.org Sat Sep 27 18:09:41 2008 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 14FC03A6873; Sat, 27 Sep 2008 18:09:41 -0700 (PDT) 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 3B6243A68B6 for ; Sat, 27 Sep 2008 18:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 KdLN7Ajd9-+N for ; Sat, 27 Sep 2008 18:09:38 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 72FCB3A6842 for ; Sat, 27 Sep 2008 18:09:38 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7V00DB1SJILK@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 18:09:18 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7V008D8SJG55@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 18:09:18 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 09:09:01 +0800 Date: Sun, 28 Sep 2008 09:09:01 +0800 From: fanhuaxiang 90002624 In-reply-to: <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> Cc: =?iso-8859-7?Q?=C2?= Subject: [Netconf] =?iso-8859-7?b?IFJlOiBSZTqgPz+gV0dMQ6Bmb3KgZHJhZnQtaWV0?= =?iso-8859-7?q?f-net_conf-t=3F=3Fls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, comments inline. > > This does not really answer my question. Why is the text in the TLS > > specs not sufficient? We should IMHO not include text is the TLS > > specifications already cover things. > > Dear Juergen, > > What about modify the actual text as follows: > > OLD: > > 2.2. Connection Closure > > Either NETCONF peer MAY stop the NETCONF connection at any time and > therefore notify the other NETCONF peer that no more data on this > channel will be sent and that any data received after a closure > request will be ignored. This MAY happen when no data is received > from a connection for a long time, where the application > decides what > "long" means. > > TLS has the abfor secure connection closure using the Alert > protocol. When the NETCONF peer closes the NETCONF connection, it > MUST send a TLS close_notify alert before closing the TCP > connection. Any data received after a closure alert is ignored. > > Unless a fatal error has occurred, each party is required to > send a > close_notify alert before closing the write side of the connection > [RFC5246]. The other party MUST respond with a close_notify > alert of > its own and close down the connection immediately, discarding any > pending writes. It is not required for the initiator of the > close to > wait for the responding close_notify alert before closing the read > side of the connection. > > > NEW: > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure > using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > any time by sending a TLS close_notify alert. This notifies the > recipient that the sender will not send any more messages on this > connection. Any data received after a closure alert is ignored. > IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time. And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server. washam > > Like that, if people need more information on this alert > behaviour, they > can refer to TLS document. > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ility for secure connection closure using the Alert > protocol. When the NETCONF peer closes the NETCONF connection, it > MUST send a TLS close_notify alert before closing the TCP > connection. Any data received after a closure alert is ignored. > > Unless a fatal error has occurred, each party is required to > send a > close_notify alert before closing the write side of the connection > [RFC5246]. The other party MUST respond with a close_notify > alert of > its own and close down the connection immediately, discarding any > pending writes. It is not required for the initiator of the > close to > wait for the responding close_notify alert before closing the read > side of the connection. > > > NEW: > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure > using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > any time by sending a TLS close_notify alert. This notifies the > recipient that the sender will not send any more messages on this > connection. Any data received after a closure alert is ignored. > IMHO, we may need to describe when to close connection for both sides.e.g, when client don't want to initial any rpc operation or server found there is no data on the wire for a long time. And, I wanna express there is a difference between syslog and netconf scenarios. in syslog case, only client is expected to send data, so syslog-tls says "client SHOULD send the pending data before sending the close_notify alert", whilst in netconf case, both sides are expected to send data, so the same words should be applied to client and server. washam > > Like that, if people need more information on this alert > behaviour, they > can refer to TLS document. > > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 18:34:58 2008 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 CB8773A6975; Sat, 27 Sep 2008 18:34:58 -0700 (PDT) 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 D1C773A68C6 for ; Sat, 27 Sep 2008 18:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 yJT25ylxBifp for ; Sat, 27 Sep 2008 18:34:57 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id D62623A6842 for ; Sat, 27 Sep 2008 18:34:56 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8S2Z7N3921734; Sun, 28 Sep 2008 03:35:07 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 28 Sep 2008 03:34:07 +0200 (CEST) Message-ID: <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> In-Reply-To: References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr> Date: Sun, 28 Sep 2008 03:34:07 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sun, 28 Sep 2008 03:35:07 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Washam, > IMHO, we may need to describe when to close connection for both sides.e.g, > when client don't want to initial any rpc operation or server found there > is no data on the wire for a long time. > And, I wanna express there is a difference between syslog and netconf > scenarios. in syslog case, only client is expected to send data, so > syslog-tls says "client SHOULD send the pending data before sending the > close_notify alert", whilst in netconf case, both sides are expected to > send data, so the same words should be applied to client and server. Let's agree on a common text, please don't hesitate to propose your text if the following isn't sufficient for you or if more correction is needed. 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. A NETCONF peer MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation or when no data is received from a connection for a long time, where the application decides what "long" means. The NETCONF peer MUST send a TLS close_notify alert before closing the connection. A sender's close_notify MAY choose to not wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver's close_notify side. Once the receiver gets a close_notify from the sender's close_notify, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 18:34:58 2008 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 CB8773A6975; Sat, 27 Sep 2008 18:34:58 -0700 (PDT) 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 D1C773A68C6 for ; Sat, 27 Sep 2008 18:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_20=-0.74, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] 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 yJT25ylxBifp for ; Sat, 27 Sep 2008 18:34:57 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id D62623A6842 for ; Sat, 27 Sep 2008 18:34:56 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8S2Z7N3921734; Sun, 28 Sep 2008 03:35:07 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 28 Sep 2008 03:34:07 +0200 (CEST) Message-ID: <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> In-Reply-To: References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr> Date: Sun, 28 Sep 2008 03:34:07 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sun, 28 Sep 2008 03:35:07 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Washam, > IMHO, we may need to describe when to close connection for both sides.e.g, > when client don't want to initial any rpc operation or server found there > is no data on the wire for a long time. > And, I wanna express there is a difference between syslog and netconf > scenarios. in syslog case, only client is expected to send data, so > syslog-tls says "client SHOULD send the pending data before sending the > close_notify alert", whilst in netconf case, both sides are expected to > send data, so the same words should be applied to client and server. Let's agree on a common text, please don't hesitate to propose your text if the following isn't sufficient for you or if more correction is needed. 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. A NETCONF peer MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation or when no data is received from a connection for a long time, where the application decides what "long" means. The NETCONF peer MUST send a TLS close_notify alert before closing the connection. A sender's close_notify MAY choose to not wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver's close_notify side. Once the receiver gets a close_notify from the sender's close_notify, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sat Sep 27 22:27:33 2008 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 B32EF3A696C; Sat, 27 Sep 2008 22:27:33 -0700 (PDT) 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 5E1393A68AA for ; Sat, 27 Sep 2008 22:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 29ufJlepmHcw for ; Sat, 27 Sep 2008 22:27:31 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 9FFCD3A681A for ; Sat, 27 Sep 2008 22:27:31 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W006944IAWC@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 22:27:46 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W003N04I8PP@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 22:27:46 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 13:27:29 +0800 Date: Sun, 28 Sep 2008 13:27:29 +0800 From: fanhuaxiang 90002624 In-reply-to: <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> Cc: =?iso-8859-7?Q?=C2?= Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Let's agree on a common text, please don't hesitate to propose > your text > if the following isn't sufficient for you or if more correction is > needed. > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure > using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when > no data > is received from a connection for a long time, where the > application decides what "long" means. The NETCONF peer MUST > send a TLS > close_noFrom netconf-bounces@ietf.org Sat Sep 27 22:27:33 2008 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 B32EF3A696C; Sat, 27 Sep 2008 22:27:33 -0700 (PDT) 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 5E1393A68AA for ; Sat, 27 Sep 2008 22:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 29ufJlepmHcw for ; Sat, 27 Sep 2008 22:27:31 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 9FFCD3A681A for ; Sat, 27 Sep 2008 22:27:31 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W006944IAWC@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 22:27:46 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7W003N04I8PP@usaga01-in.huawei.com> for netconf@ietf.org; Sat, 27 Sep 2008 22:27:46 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.27.141.6]) by szxmc04-in.huawei.com (mshttpd); Sun, 28 Sep 2008 13:27:29 +0800 Date: Sun, 28 Sep 2008 13:27:29 +0800 From: fanhuaxiang 90002624 In-reply-to: <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> To: badra@isima.fr Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> Cc: =?iso-8859-7?Q?=C2?= Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Let's agree on a common text, please don't hesitate to propose > your text > if the following isn't sufficient for you or if more correction is > needed. > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure > using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when > no data > is received from a connection for a long time, where the > application decides what "long" means. The NETCONF peer MUST > send a TLS > close_notify atify alert before closing the connection. A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an > incomplete close on the receiver's close_notify side. Once the > receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has > already been closed by the sender (e.g., the closure was > indicated by TCP). I'd like add below sentence to the end of the paragraph. "in the case receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf lert before closing the connection. A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an > incomplete close on the receiver's close_notify side. Once the > receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has > already been closed by the sender (e.g., the closure was > indicated by TCP). I'd like add below sentence to the end of the paragraph. "in the case receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." > Best regards, > Badra > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Sun Sep 28 03:24:08 2008 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 848123A68A0; Sun, 28 Sep 2008 03:24:08 -0700 (PDT) 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 2CA9C3A68A0 for ; Sun, 28 Sep 2008 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLfVeKHiA6pT for ; Sun, 28 Sep 2008 03:24:06 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA5B3A67F4 for ; Sun, 28 Sep 2008 03:24:04 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8SBNpdF782532; Sun, 28 Sep 2008 12:23:51 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 28 Sep 2008 12:22:51 +0200 (CEST) Message-ID: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> In-Reply-To: References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr><53194.88.164.98.77.1222565647.squirrel@www.isima.fr> Date: Sun, 28 Sep 2008 12:22:51 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sun, 28 Sep 2008 12:23:52 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgUmU6wqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYt?= =?utf-8?q?netcon__f-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Washam, Thank you for your reply. Here is the last text we agree on. Dear Juergen, based on Washam's comments, I think we need to keep such a text even if TLS describes this alert. 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. A NETCONF peer MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation or when no data is received from a connection for a long time, where the application decides what "long" means. The NETCONF peer MUST send a TLS close_notify alert before closing the connection. A sender's close_notify MAY choose to not wait for the receiver's close_notify alert and simply close the conneFrom netconf-bounces@ietf.org Sun Sep 28 03:24:08 2008 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 848123A68A0; Sun, 28 Sep 2008 03:24:08 -0700 (PDT) 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 2CA9C3A68A0 for ; Sun, 28 Sep 2008 03:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLfVeKHiA6pT for ; Sun, 28 Sep 2008 03:24:06 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA5B3A67F4 for ; Sun, 28 Sep 2008 03:24:04 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8SBNpdF782532; Sun, 28 Sep 2008 12:23:51 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Sun, 28 Sep 2008 12:22:51 +0200 (CEST) Message-ID: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> In-Reply-To: References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr><53194.88.164.98.77.1222565647.squirrel@www.isima.fr> Date: Sun, 28 Sep 2008 12:22:51 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?fanhuaxiang=C2_90002624=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Sun, 28 Sep 2008 12:23:52 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJlOsKgUmU6wqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYt?= =?utf-8?q?netcon__f-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear Washam, Thank you for your reply. Here is the last text we agree on. Dear Juergen, based on Washam's comments, I think we need to keep such a text even if TLS describes this alert. 2.2. Connection Closure TLS [RFC5246] has the ability for secure connection closure using the Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at any time by sending a TLS close_notify alert. A NETCONF peer MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation or when no data is received from a connection for a long time, where the application decides what "long" means. The NETCONF peer MUST send a TLS close_notify alert before closing the connection. A sender's close_notify MAY choose to not wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver's close_notify side. Once the receiver gets a close_notify from the sender's close_notify, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). In the case the receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf ction, thus generating an incomplete close on the receiver's close_notify side. Once the receiver gets a close_notify from the sender's close_notify, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). In the case the receiver still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 03:13:35 2008 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 A2B6F3A68CF; Mon, 29 Sep 2008 03:13:35 -0700 (PDT) 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 849A43A67EA for ; Mon, 29 Sep 2008 03:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 hx6Wn8vyM9En for ; Mon, 29 Sep 2008 03:13:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 364863A6806 for ; Mon, 29 Sep 2008 03:13:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52FD0C000D; Mon, 29 Sep 2008 12:13:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KkxkKlEVgHfe; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CAA6C0003; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5FD9F7D49A8; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Date: Mon, 29 Sep 2008 12:13:40 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080929101340.GC22657@elstar.local> Mail-Followup-To: badra@isima.fr, fanhuaxiang? 90002624? , ? References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt 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, Sep 28, 2008 at 12:22:51PM +0200, badra@isima.fr wrote: > Here is the last text we agree on. > Dear Juergen, based on Washam's comments, I think we need to keep such a > text even if TLS describes this alert. > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when no data > is received from a connection for a long time, where the application > decides what "long" means. I don't really see the value of this sentence. Essentially the text says "an application MUST close the TLS connection if the application believes the TLS connection is not used anymore" - something rather obvious and I am not sure an explicit MUST is needed. > The NETCONF peer MUST send a TLS close_notify alert before > closing the connection. But I think you can't rely on being able to do this in all cases. Perhaps this should be a SHOULD instead of a MUST. > A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an incomplete > close on the receiver's close_notify side. Once the receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has already > been closed by the sender (e.g., the closure was indicated by TCP). See above - I assume a SHOULD is more appropriate than a MUST. > In the case the receiver still has pending data to send, it > SHOULD send the pending data before sending the close_notify > alert. Here I agree with the SHOULD. ;-) /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 Sep 29 03:13:35 2008 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 A2B6F3A68CF; Mon, 29 Sep 2008 03:13:35 -0700 (PDT) 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 849A43A67EA for ; Mon, 29 Sep 2008 03:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 hx6Wn8vyM9En for ; Mon, 29 Sep 2008 03:13:33 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 364863A6806 for ; Mon, 29 Sep 2008 03:13:33 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52FD0C000D; Mon, 29 Sep 2008 12:13:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KkxkKlEVgHfe; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CAA6C0003; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5FD9F7D49A8; Mon, 29 Sep 2008 12:13:40 +0200 (CEST) Date: Mon, 29 Sep 2008 12:13:40 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080929101340.GC22657@elstar.local> Mail-Followup-To: badra@isima.fr, fanhuaxiang? 90002624? , ? References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt 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, Sep 28, 2008 at 12:22:51PM +0200, badra@isima.fr wrote: > Here is the last text we agree on. > Dear Juergen, based on Washam's comments, I think we need to keep such a > text even if TLS describes this alert. > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when no data > is received from a connection for a long time, where the application > decides what "long" means. I don't really see the value of this sentence. Essentially the text says "an application MUST close the TLS connection if the application believes the TLS connection is not used anymore" - something rather obvious and I am not sure an explicit MUST is needed. > The NETCONF peer MUST send a TLS close_notify alert before > closing the connection. But I think you can't rely on being able to do this in all cases. Perhaps this should be a SHOULD instead of a MUST. > A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an incomplete > close on the receiver's close_notify side. Once the receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has already > been closed by the sender (e.g., the closure was indicated by TCP). See above - I assume a SHOULD is more appropriate than a MUST. > In the case the receiver still has pending data to send, it > SHOULD send the pending data before sending the close_notify > alert. Here I agree with the SHOULD. ;-) /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 Sep 29 03:19:32 2008 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 0854D3A6A70; Mon, 29 Sep 2008 03:19:32 -0700 (PDT) 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 95B683A6A70 for ; Mon, 29 Sep 2008 03:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 P-9cUD1HifeR for ; Mon, 29 Sep 2008 03:19:30 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 942633A6895 for ; Mon, 29 Sep 2008 03:19:30 -0700 (PDT) X-Trace: 32028066/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.130.38 X-SBRS: None X-RemoteIP: 62.188.130.38 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAPtH4Eg+vIIm/2dsb2JhbACDQzmIVa4OA4Fk X-IronPort-AV: E=Sophos;i="4.33,330,1220223600"; d="scan'208";a="32028066" X-IP-Direction: IN Received: from 1cust38.tnt1.lnd4.gbr.da.uu.net (HELO allison) ([62.188.130.38]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Sep 2008 11:19:08 +0100 Message-ID: <006a01c92213$63b81060$0601a8c0@allison> From: "tom.petch" To: , =?iso-8859-1?Q?fanhuaxiang=C2_90002624=C2?= References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr><53194.88.164.98.77.1222565647.squirrel@www.isima.fr> <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 11:10:26 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: =?iso-8859-1?B?wg==?= Subject: Re: [Netconf] =?iso-8859-1?q?=C2=A0Re=3A=C2=A0WGLC=C2=A0for=C2=A0draf?= =?iso-8859-1?q?t-ietf-netcon__f-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: To: "fanhuaxiang=C2 90002624=C2" Cc: "=C2" Sent: Sunday, September 28, 2008 12:22 PM Subject: [Netconf] Re:=C2 Re:=C2 WGLC=C2 for=C2 draft-ietf-netcon f-tls-04.= txt > Dear Washam, > > Thank you for your reply. > Here is the last text we agree on. > Dear Juergen, based on Washam's comments, I think we need to keep such a > text even if TLS describes this alert. > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when no data > is received from a connection for a long time, where the application > decides what "long" means. The NETCONF peer MUST send a TLS > close_notify alert before closing the connection. A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an incomplete > close on the receiver's close_notify side. Once the receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has already > been closed by the sender (e.g., the closure was indicated by TCP). In > the case the receiver still has pending data to send, it SHOULD send > the pending data before sending the close_notify alert. > To quote TLS, "The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. " so this proposed text would appear to contradict a TLS MUST. TLS also takes great care not to bind itself to TCP and not to prescribe the behaviour of = the underlying transport protocol. And I imagine that this is what Juergen had in mind. When we start to repr= oduce TLS in our own words, we are likely to make things worse (perhaps also know= n as the distributed database problem). And for those with a sense of history, = be aware that the last call on syslog-tls completed precisely two years ago - = and the I-D is still being revised:-( Tom Petch > Best regards, > Badra > _______________________________________________ > 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 Mon Sep 29 03:19:32 2008 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 0854D3A6A70; Mon, 29 Sep 2008 03:19:32 -0700 (PDT) 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 95B683A6A70 for ; Mon, 29 Sep 2008 03:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 P-9cUD1HifeR for ; Mon, 29 Sep 2008 03:19:30 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 942633A6895 for ; Mon, 29 Sep 2008 03:19:30 -0700 (PDT) X-Trace: 32028066/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.130.38 X-SBRS: None X-RemoteIP: 62.188.130.38 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAPtH4Eg+vIIm/2dsb2JhbACDQzmIVa4OA4Fk X-IronPort-AV: E=Sophos;i="4.33,330,1220223600"; d="scan'208";a="32028066" X-IP-Direction: IN Received: from 1cust38.tnt1.lnd4.gbr.da.uu.net (HELO allison) ([62.188.130.38]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Sep 2008 11:19:08 +0100 Message-ID: <006a01c92213$63b81060$0601a8c0@allison> From: "tom.petch" To: , =?iso-8859-1?Q?fanhuaxiang=C2_90002624=C2?= References: <20080927090622.GA431@elstar.local><59304.88.164.98.77.1222523373.squirrel@www.isima.fr><20080927154119.GA803@elstar.local><61122.88.164.98.77.1222530809.squirrel@www.isima.fr><20080927161432.GA918@elstar.local><49231.88.164.98.77.1222550961.squirrel@www.isima.fr><53194.88.164.98.77.1222565647.squirrel@www.isima.fr> <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 11:10:26 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: =?iso-8859-1?B?wg==?= Subject: Re: [Netconf] =?iso-8859-1?q?=C2=A0Re=3A=C2=A0WGLC=C2=A0for=C2=A0draf?= =?iso-8859-1?q?t-ietf-netcon__f-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: To: "fanhuaxiang=C2 90002624=C2" Cc: "=C2" Sent: Sunday, September 28, 2008 12:22 PM Subject: [Netconf] Re:=C2 Re:=C2 WGLC=C2 for=C2 draft-ietf-netcon f-tls-04.= txt > Dear Washam, > > Thank you for your reply. > Here is the last text we agree on. > Dear Juergen, based on Washam's comments, I think we need to keep such a > text even if TLS describes this alert. > > 2.2. Connection Closure > > TLS [RFC5246] has the ability for secure connection closure using the > Alert protocol. Either NETCONF peer MAY stop the NETCONF connection at > any time by sending a TLS close_notify alert. > > A NETCONF peer MUST close the associated TLS connection if the > connection is not expected to deliver any rpc operation or when no data > is received from a connection for a long time, where the application > decides what "long" means. The NETCONF peer MUST send a TLS > close_notify alert before closing the connection. A sender's > close_notify MAY choose to not wait for the receiver's close_notify > alert and simply close the connection, thus generating an incomplete > close on the receiver's close_notify side. Once the receiver gets a > close_notify from the sender's close_notify, it MUST reply with a > close_notify unless it becomes aware that the connection has already > been closed by the sender (e.g., the closure was indicated by TCP). In > the case the receiver still has pending data to send, it SHOULD send > the pending data before sending the close_notify alert. > To quote TLS, "The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. " so this proposed text would appear to contradict a TLS MUST. TLS also takes great care not to bind itself to TCP and not to prescribe the behaviour of = the underlying transport protocol. And I imagine that this is what Juergen had in mind. When we start to repr= oduce TLS in our own words, we are likely to make things worse (perhaps also know= n as the distributed database problem). And for those with a sense of history, = be aware that the last call on syslog-tls completed precisely two years ago - = and the I-D is still being revised:-( Tom Petch > Best regards, > Badra > _______________________________________________ > 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 Mon Sep 29 03:35:23 2008 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 89AF63A6981; Mon, 29 Sep 2008 03:35:23 -0700 (PDT) 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 0F6043A6A5D for ; Mon, 29 Sep 2008 03:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWzQgC8iilDY for ; Mon, 29 Sep 2008 03:35:22 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 35D913A6979 for ; Mon, 29 Sep 2008 03:35:22 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00C0KDEQO3@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:35:14 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00H7ODEPKA@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:35:14 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Sep 2008 18:34:57 +0800 Date: Mon, 29 Sep 2008 18:34:57 +0800 From: fanhuaxiang 90002624 In-reply-to: <20080929101340.GC22657@elstar.local> To: j.schoenwaelder@jacobs-university.de Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Sun, Sep 28, 2008 at 12:22:51PM +0200, badra@isima.fr wrote: > > > Here is the last text we agree on. > > Dear Juergen, based on Washam's comments, I think we need to keep > such a > > text even if TLS describes this alert. > > > > 2.2. Connection Closure > > > > TLS [RFC5246] has the ability for secure connection closure > using the > > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > > any time by sending a TLS close_notify alert. > > > > A NETCONF peer MUST close the associated TLS connection if the > > connection is not expected to deliver any rpc operation or > when no data > > is received from a connection for a long time, where the > application> decides what "long" means. > > I don't really see the value of this sentence. Essentially the text > says "an application MUST close the TLS connection if the application > believes the TLS connection is not used anymore" - somFrom netconf-bounces@ietf.org Mon Sep 29 03:35:23 2008 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 89AF63A6981; Mon, 29 Sep 2008 03:35:23 -0700 (PDT) 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 0F6043A6A5D for ; Mon, 29 Sep 2008 03:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWzQgC8iilDY for ; Mon, 29 Sep 2008 03:35:22 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 35D913A6979 for ; Mon, 29 Sep 2008 03:35:22 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00C0KDEQO3@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:35:14 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00H7ODEPKA@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:35:14 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Sep 2008 18:34:57 +0800 Date: Mon, 29 Sep 2008 18:34:57 +0800 From: fanhuaxiang 90002624 In-reply-to: <20080929101340.GC22657@elstar.local> To: j.schoenwaelder@jacobs-university.de Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > On Sun, Sep 28, 2008 at 12:22:51PM +0200, badra@isima.fr wrote: > > > Here is the last text we agree on. > > Dear Juergen, based on Washam's comments, I think we need to keep > such a > > text even if TLS describes this alert. > > > > 2.2. Connection Closure > > > > TLS [RFC5246] has the ability for secure connection closure > using the > > Alert protocol. Either NETCONF peer MAY stop the NETCONF > connection at > > any time by sending a TLS close_notify alert. > > > > A NETCONF peer MUST close the associated TLS connection if the > > connection is not expected to deliver any rpc operation or > when no data > > is received from a connection for a long time, where the > application> decides what "long" means. > > I don't really see the value of this sentence. Essentially the text > says "an application MUST close the TLS connection if the application > believes the TLS connection is not used anymore"ething rather > obvious and I am not sure an explicit MUST is needed. > I think the value of section "connection closure" is to describe when and how to end up a connection. so I think maybe we need to elaborate what "TLS connection is not used anymore" means in netconf context. > > The NETCONF peer MUST send a TLS close_notify alert before > > closing the connection. > > But I think you can't rely on being able to do this in all cases. > Perhaps this should be a SHOULD instead of a MUST. > isn't it what TLS rfc specify how to close a connection? > > A sender's > > close_notify MAY choose to not wait for the receiver's > close_notify> alert and simply close the connection, thus > generating an incomplete > > close on the receiver's close_notify side. Once the receiver > gets a > > close_notify from the sender's close_notify, it MUST reply > with a > > close_notify unless it becomes aware that the connection has > already> been closed by the sender (e.g., the closure was > indicated by TCP). > > See above - I assume a SHOULD is more appropriate than a MUST. > > > In the case the receiver still has pending data to send, it > > SHOULD send the pending data before sending the close_notify > > alert. > > Here I agree with the SHOULD. ;-) > > /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 - something rather > obvious and I am not sure an explicit MUST is needed. > I think the value of section "connection closure" is to describe when and how to end up a connection. so I think maybe we need to elaborate what "TLS connection is not used anymore" means in netconf context. > > The NETCONF peer MUST send a TLS close_notify alert before > > closing the connection. > > But I think you can't rely on being able to do this in all cases. > Perhaps this should be a SHOULD instead of a MUST. > isn't it what TLS rfc specify how to close a connection? > > A sender's > > close_notify MAY choose to not wait for the receiver's > close_notify> alert and simply close the connection, thus > generating an incomplete > > close on the receiver's close_notify side. Once the receiver > gets a > > close_notify from the sender's close_notify, it MUST reply > with a > > close_notify unless it becomes aware that the connection has > already> been closed by the sender (e.g., the closure was > indicated by TCP). > > See above - I assume a SHOULD is more appropriate than a MUST. > > > In the case the receiver still has pending data to send, it > > SHOULD send the pending data before sending the close_notify > > alert. > > Here I agree with the SHOULD. ;-) > > /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 Sep 29 03:45:02 2008 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 E60773A6784; Mon, 29 Sep 2008 03:45:01 -0700 (PDT) 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 AE0B43A6819 for ; Mon, 29 Sep 2008 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrEn9jOZhFIw for ; Mon, 29 Sep 2008 03:44:59 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C0F553A6784 for ; Mon, 29 Sep 2008 03:44:59 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00JH8DUQHN@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:44:50 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00HMDDUPKA@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:44:50 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Sep 2008 18:44:32 +0800 Date: Mon, 29 Sep 2008 18:44:32 +0800 From: fanhuaxiang 90002624 In-reply-to: <006a01c92213$63b81060$0601a8c0@allison> To: "tom.petch" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <006a01c92213$63b81060$0601a8c0@allison> Cc: ? Subject: Re: [Netconf] ? Re:? WGLC? for? draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > To quote TLS, > "The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. " > so this proposed text would appear to contradict a TLS MUST. TLS > also takes > great care not to bind itself to TCP and not to prescribe the > behaviour of the > underlying transport protocol. maybe what said in counterpart section in syslog-tls contradict a TLS MUST, too. > > And I imagine that this is what Juergen had in mind. When we start > to reproduce > TLS in our own words, we are likFrom netconf-bounces@ietf.org Mon Sep 29 03:45:02 2008 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 E60773A6784; Mon, 29 Sep 2008 03:45:01 -0700 (PDT) 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 AE0B43A6819 for ; Mon, 29 Sep 2008 03:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrEn9jOZhFIw for ; Mon, 29 Sep 2008 03:44:59 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id C0F553A6784 for ; Mon, 29 Sep 2008 03:44:59 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00JH8DUQHN@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:44:50 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K7Y00HMDDUPKA@usaga01-in.huawei.com> for netconf@ietf.org; Mon, 29 Sep 2008 03:44:50 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Mon, 29 Sep 2008 18:44:32 +0800 Date: Mon, 29 Sep 2008 18:44:32 +0800 From: fanhuaxiang 90002624 In-reply-to: <006a01c92213$63b81060$0601a8c0@allison> To: "tom.petch" Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <20080927154119.GA803@elstar.local> <61122.88.164.98.77.1222530809.squirrel@www.isima.fr> <20080927161432.GA918@elstar.local> <49231.88.164.98.77.1222550961.squirrel@www.isima.fr> <53194.88.164.98.77.1222565647.squirrel@www.isima.fr> <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <006a01c92213$63b81060$0601a8c0@allison> Cc: ? Subject: Re: [Netconf] ? Re:? WGLC? for? draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > To quote TLS, > "The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. " > so this proposed text would appear to contradict a TLS MUST. TLS > also takes > great care not to bind itself to TCP and not to prescribe the > behaviour of the > underlying transport protocol. maybe what said in counterpart section in syslog-tls contradict a TLS MUST, too. > > And I imagine that this is what Juergen had in mind. When we start > to reproduce > TLS in our own words, we aely to make things worse (perhaps > also known as > the distributed database problem). And for those with a sense of > history, be > aware that the last call on syslog-tls completed precisely two > years ago - and > the I-D is still being revised:-( washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf re likely to make things worse (perhaps > also known as > the distributed database problem). And for those with a sense of > history, be > aware that the last call on syslog-tls completed precisely two > years ago - and > the I-D is still being revised:-( washam _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 03:52:27 2008 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 5803C3A68AB; Mon, 29 Sep 2008 03:52:27 -0700 (PDT) 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 BBCA73A682C for ; Mon, 29 Sep 2008 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 5Lki3zdbVaZ7 for ; Mon, 29 Sep 2008 03:52:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D23603A67BD for ; Mon, 29 Sep 2008 03:52:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B87E8C0007; Mon, 29 Sep 2008 12:52:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6qSOkgpz3afk; Mon, 29 Sep 2008 12:52:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2011C0024; Mon, 29 Sep 2008 12:52:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1621F7D4AAC; Mon, 29 Sep 2008 12:52:05 +0200 (CEST) Date: Mon, 29 Sep 2008 12:52:05 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080929105205.GA22832@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , badra@isima.fr, ? References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt 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, Sep 29, 2008 at 06:34:57PM +0800, fanhuaxiang 90002624 wrote: > I think the value of section "connection closure" is to describe > when and how to end up a connection. so I think maybe we need to > elaborate what "TLS connection is not used anymore" means in netconf > context. It is the application's decision and hence any discussion is either pointless or likely getting it wrong. /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 Sep 29 03:52:27 2008 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 5803C3A68AB; Mon, 29 Sep 2008 03:52:27 -0700 (PDT) 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 BBCA73A682C for ; Mon, 29 Sep 2008 03:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 5Lki3zdbVaZ7 for ; Mon, 29 Sep 2008 03:52:25 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id D23603A67BD for ; Mon, 29 Sep 2008 03:52:24 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B87E8C0007; Mon, 29 Sep 2008 12:52:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6qSOkgpz3afk; Mon, 29 Sep 2008 12:52:04 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2011C0024; Mon, 29 Sep 2008 12:52:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1621F7D4AAC; Mon, 29 Sep 2008 12:52:05 +0200 (CEST) Date: Mon, 29 Sep 2008 12:52:05 +0200 From: Juergen Schoenwaelder To: fanhuaxiang 90002624 Message-ID: <20080929105205.GA22832@elstar.local> Mail-Followup-To: fanhuaxiang 90002624 , badra@isima.fr, ? References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt 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, Sep 29, 2008 at 06:34:57PM +0800, fanhuaxiang 90002624 wrote: > I think the value of section "connection closure" is to describe > when and how to end up a connection. so I think maybe we need to > elaborate what "TLS connection is not used anymore" means in netconf > context. It is the application's decision and hence any discussion is either pointless or likely getting it wrong. /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 Sep 29 04:45:50 2008 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 31AC23A6832; Mon, 29 Sep 2008 04:45:50 -0700 (PDT) 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 E1CAB3A6832 for ; Mon, 29 Sep 2008 04:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HELO_EQ_FR=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 0e+Y+--PXv2a for ; Mon, 29 Sep 2008 04:45:47 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id F05F43A6784 for ; Mon, 29 Sep 2008 04:45:46 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m8TCjKc21085592; Mon, 29 Sep 2008 13:45:21 +0100 Message-ID: <48E0BF94.2060208@isima.fr> Date: Mon, 29 Sep 2008 13:44:20 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 , Juergen Schoenwaelder , cfinss@dial.pipex.com References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> <20080929105205.GA22832@elstar.local> In-Reply-To: <20080929105205.GA22832@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 13:45:21 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org tom.petch wrote: >>Juergen Schoenwaelder wrote: >>>fanhuaxiang 90002624 wrote: > To quote TLS, > "The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. " > so this proposed text would appear to contradict a TLS MUST. TLS also takes > great care not to bind itself to TCP and not to prescribe the behaviour of the > underlying transport protocol. >> maybe what said in counterpart section in syslog-tls contradict a >>TLS MUST, too. >>> I think the value of section "connection closure" is to describe >>> when and how to end up a connection. so I think maybe we need to >>> elaborate what "TLS connection is not used anymore" means in netconf >>> context. >>> >>> It is the application's decision and hence any discussion is either >>> pointless or likely getting it wrong. To quote IESG Evaluation on syslog-tls, "Section 4.4: OLD: A TLS client MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A client MAY choose to not wait for the server's close_noFrom netconf-bounces@ietf.org Mon Sep 29 04:45:50 2008 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 31AC23A6832; Mon, 29 Sep 2008 04:45:50 -0700 (PDT) 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 E1CAB3A6832 for ; Mon, 29 Sep 2008 04:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, HELO_EQ_FR=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 0e+Y+--PXv2a for ; Mon, 29 Sep 2008 04:45:47 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id F05F43A6784 for ; Mon, 29 Sep 2008 04:45:46 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m8TCjKc21085592; Mon, 29 Sep 2008 13:45:21 +0100 Message-ID: <48E0BF94.2060208@isima.fr> Date: Mon, 29 Sep 2008 13:44:20 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 , Juergen Schoenwaelder , cfinss@dial.pipex.com References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> <20080929105205.GA22832@elstar.local> In-Reply-To: <20080929105205.GA22832@elstar.local> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 13:45:21 +0100 (WEST) Cc: netconf@ietf.org Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org tom.petch wrote: >>Juergen Schoenwaelder wrote: >>>fanhuaxiang 90002624 wrote: > To quote TLS, > "The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. " > so this proposed text would appear to contradict a TLS MUST. TLS also takes > great care not to bind itself to TCP and not to prescribe the behaviour of the > underlying transport protocol. >> maybe what said in counterpart section in syslog-tls contradict a >>TLS MUST, too. >>> I think the value of section "connection closure" is to describe >>> when and how to end up a connection. so I think maybe we need to >>> elaborate what "TLS connection is not used anymore" means in netconf >>> context. >>> >>> It is the application's decision and hence any discussion is either >>> pointless or likely getting it wrong. To quote IESG Evaluation on syslog-tls, "Section 4.4: OLD: A TLS client MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A client MAY choose to not wait for the server's close_notify atify alert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the client (e.g., the closure was indicated by TCP). NEW: A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A transport sender (TLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the transport receiver (TLS server) side. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). Section 4.4: OLD: When no data is received from a connection for a long time (where the application decides what "long" means), a server MAY close the connection. The server MUST attempt to initiate an exchange of close_notify alerts with the client before closing the connection. Servers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. NEW: When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (TLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the transport sender side. When the transport sender (TLS client) has received the close_notify alert from the transport receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." I think the above text would appear to contradict a TLS MUST. Wouldn't? I also think the above text describes when to close connection for both sides. e.g, when the client doesn't want to initial any syslog message or when the server found there is no data on the wire for a long time. With respect to that, I think we should propose a simalar text, a modified text is below: "A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a TLS server MAY close the connection. The TLS server MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. The server that is unprepared to receive any more data MAY close the connection after slert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the client (e.g., the closure was indicated by TCP). NEW: A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A transport sender (TLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the transport receiver (TLS server) side. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). Section 4.4: OLD: When no data is received from a connection for a long time (where the application decides what "long" means), a server MAY close the connection. The server MUST attempt to initiate an exchange of close_notify alerts with the client before closing the connection. Servers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. NEW: When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (TLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the transport sender side. When the transport sender (TLS client) has received the close_notify alert from the transport receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." I think the above text would appear to contradict a TLS MUST. Wouldn't? I also think the above text describes when to close connection for both sides. e.g, when the client doesn't want to initial any syslog message or when the server found there is no data on the wire for a long time. With respect to that, I think we should propose a simalar text, a modified text is below: "A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a TLS server MAY close the connection. The TLS server MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. The server that is unprepared to receive any more data MAY close the connection after sendingending the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Comments? Best regards, Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf the close_notify alert, thus generating an incomplete close on the client side. When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Comments? Best regards, Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 05:14:20 2008 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 AEA1A3A69A1; Mon, 29 Sep 2008 05:14:20 -0700 (PDT) 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 7A85C3A68CE for ; Mon, 29 Sep 2008 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=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 Txwu5PjQPwbC for ; Mon, 29 Sep 2008 05:14:18 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 03D4B3A68F5 for ; Mon, 29 Sep 2008 05:14:17 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m8TDEXrd634974; Mon, 29 Sep 2008 14:14:35 +0100 Message-ID: <48E0C66D.8020106@isima.fr> Date: Mon, 29 Sep 2008 14:13:33 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> <20080929105205.GA22832@elstar.local> <48E0BF94.2060208@isima.fr> In-Reply-To: <48E0BF94.2060208@isima.fr> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 14:14:35 +0100 (WEST) Cc: Juergen Schoenwaelder , netconf@ietf.org Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org My apologies, I forgot to include Washam comments "in netconf case, both = sides are expected to send data" So please forget my last text, below is the correct one: "A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a NETCONF peer MAY close the connection. The peer MUST attempt to initiate an exchange of close_notify alerts with the other NETCONF peer before closing the connection. The close_notify's sender that is unpreFrom netconf-bounces@ietf.org Mon Sep 29 05:14:20 2008 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 AEA1A3A69A1; Mon, 29 Sep 2008 05:14:20 -0700 (PDT) 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 7A85C3A68CE for ; Mon, 29 Sep 2008 05:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=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 Txwu5PjQPwbC for ; Mon, 29 Sep 2008 05:14:18 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 03D4B3A68F5 for ; Mon, 29 Sep 2008 05:14:17 -0700 (PDT) Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id m8TDEXrd634974; Mon, 29 Sep 2008 14:14:35 +0100 Message-ID: <48E0C66D.8020106@isima.fr> Date: Mon, 29 Sep 2008 14:13:33 +0200 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: fanhuaxiang 90002624 References: <54592.88.164.98.77.1222597371.squirrel@www.isima.fr> <20080929101340.GC22657@elstar.local> <20080929105205.GA22832@elstar.local> <48E0BF94.2060208@isima.fr> In-Reply-To: <48E0BF94.2060208@isima.fr> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 14:14:35 +0100 (WEST) Cc: Juergen Schoenwaelder , netconf@ietf.org Subject: Re: [Netconf] ??Re:??WGLC??for??draft-ietf-netcon f-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org My apologies, I forgot to include Washam comments "in netconf case, both = sides are expected to send data" So please forget my last text, below is the correct one: "A TLS client (NETCONF manager) MUST close the associated TLS connection if the connection is not expected to deliver any rpc operation later. It MUST send a TLS close_notify alert before closing the connection. The client MAY choose to not wait for the TLS server (NETCONF agent) close_notify alert and simply close the connection, thus generating an incomplete close on the server side. Once the server gets a close_notify from the client, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a NETCONF peer MAY close the connection. The peer MUST attempt to initiate an exchange of close_notify alerts with the other NETCONF peer before closing the connection. The close_notify's sender that is pared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the close_notify's receiver side. When the receiver has received the close_notify alert from the sender and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Best regards Mohamad Badra CNRS - LIMOS Laboratory Mohamad Badra a =E9crit : > tom.petch wrote: > >>Juergen Schoenwaelder wrote: > >>>fanhuaxiang 90002624 wrote: >> To quote TLS, >> "The other party MUST respond with a close_notify >> alert of its own and close down the connection immediately, >> discarding any pending writes. " >> so this proposed text would appear to contradict a TLS MUST. TLS also = >> takes >> great care not to bind itself to TCP and not to prescribe the = >> behaviour of the >> underlying transport protocol. > = > >> maybe what said in counterpart section in syslog-tls contradict a = > >>TLS MUST, too. > = >>>> I think the value of section "connection closure" is to describe >>>> when and how to end up a connection. so I think maybe we need to >>>> elaborate what "TLS connection is not used anymore" means in netconf >>>> context. >>>> >>>> It is the application's decision and hence any discussion is either >>>> pointless or likely getting it wrong. > = > To quote IESG Evaluation on syslog-tls, > = > "Section 4.4: > OLD: > A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It MUST send a TLS close_notify alert before closing the > connection. A client MAY choose to not wait for the server's > close_notify alert and simply close the connection, thus > generating an incomplete close on the server side. Once the > server gets a close_notify from the client, it MUST reply with a > close_notify unless it becomes aware that the connection has > already been closed by the client (e.g., the closure was > indicated by TCP). > NEW: > A transport sender MUST close the associated TLS connection if > the connection is not expected to deliver any syslog messages > later. It MUST send a TLS close_notify alert before closing the > connection. A transport sender (TLS client) MAY choose to not > wait for the transport receiver's close_notify alert and simply > close the connection, thus generating an incomplete close on the > transport receiver (TLS server) side. Once the transport > receiver gets a close_notify from the transport sender, it MUST > reply with a close_notify unless it becomes aware that the > connection has already been closed by the transport sender > (e.g., the closure was indicated by TCP). > = > Section 4.4: > OLD: > When no data is received from a connection for a long time > (where the application decides what "long" means), a server MAY > close the connection. The server MUST attempt to initiate an > exchange of close_notify alerts with the client before closing > the connection. Servers that are unprepared to receive any more > data MAY close the connection after sending the close_notify > alert, thus generating an incomplete close on the client side. > When the client has received the close_notify alert from the > server and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. > NEW: > When no data is received from a connection for a long time > (where the application decides what "long" means), a transport > receiver MAY close the connection. The transport receiver (TLS > server) MUST attempt to initiate an exchange of close_notify > alerts with the transport sender before closing the connection. > Transport receivers that are unprepared to receive any more data > MAY close the connection after sending the close_notify unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the close_notify's receiver side. When the receiver has received the close_notify alert from the sender and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." Best regards Mohamad Badra CNRS - LIMOS Laboratory Mohamad Badra a =E9crit : > tom.petch wrote: > >>Juergen Schoenwaelder wrote: > >>>fanhuaxiang 90002624 wrote: >> To quote TLS, >> "The other party MUST respond with a close_notify >> alert of its own and close down the connection immediately, >> discarding any pending writes. " >> so this proposed text would appear to contradict a TLS MUST. TLS also = >> takes >> great care not to bind itself to TCP and not to prescribe the = >> behaviour of the >> underlying transport protocol. > = > >> maybe what said in counterpart section in syslog-tls contradict a = > >>TLS MUST, too. > = >>>> I think the value of section "connection closure" is to describe >>>> when and how to end up a connection. so I think maybe we need to >>>> elaborate what "TLS connection is not used anymore" means in netconf >>>> context. >>>> >>>> It is the application's decision and hence any discussion is either >>>> pointless or likely getting it wrong. > = > To quote IESG Evaluation on syslog-tls, > = > "Section 4.4: > OLD: > A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It MUST send a TLS close_notify alert before closing the > connection. A client MAY choose to not wait for the server's > close_notify alert and simply close the connection, thus > generating an incomplete close on the server side. Once the > server gets a close_notify from the client, it MUST reply with a > close_notify unless it becomes aware that the connection has > already been closed by the client (e.g., the closure was > indicated by TCP). > NEW: > A transport sender MUST close the associated TLS connection if > the connection is not expected to deliver any syslog messages > later. It MUST send a TLS close_notify alert before closing the > connection. A transport sender (TLS client) MAY choose to not > wait for the transport receiver's close_notify alert and simply > close the connection, thus generating an incomplete close on the > transport receiver (TLS server) side. Once the transport > receiver gets a close_notify from the transport sender, it MUST > reply with a close_notify unless it becomes aware that the > connection has already been closed by the transport sender > (e.g., the closure was indicated by TCP). > = > Section 4.4: > OLD: > When no data is received from a connection for a long time > (where the application decides what "long" means), a server MAY > close the connection. The server MUST attempt to initiate an > exchange of close_notify alerts with the client before closing > the connection. Servers that are unprepared to receive any more > data MAY close the connection after sending the close_notify > alert, thus generating an incomplete close on the client side. > When the client has received the close_notify alert from the > server and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. > NEW: > When no data is received from a connection for a long time > (where the application decides what "long" means), a transport > receiver MAY close the connection. The transport receiver (TLS > server) MUST attempt to initiate an exchange of close_notify > alerts with the transport sender before closing the connection. > Transport receivers that are unprepared to receive any more data > MAY close the connection after sending the close_notify alert, > thus generating an incomplete close on the transport sender > side. When the transport sender (TLS client) has received the > close_notify alert from the transport receiver and still has > pending data to send, it SHOULD send the pending data before > sending the close_notify alert." > = > = > I think the above text would appear to contradict a TLS MUST. Wouldn't? > = > I also think the above text describes when to close connection for both = > sides. e.g, when the client doesn't want to initial any syslog message = > or when the server found there is no data on the wire for a long time. > = > With respect to that, I think we should propose a simalar text, a = > modified text is below: > = > "A TLS client (NETCONF manager) MUST close the associated TLS > connection if the connection is not expected to deliver any rpc > operation later. It MUST send a TLS close_notify alert before > closing the connection. The client MAY choose to not wait for the > TLS server (NETCONF agent) close_notify alert and simply close the > connection, thus generating an incomplete close on the server > side. Once the server gets a close_notify from the client, it > MUST reply with a close_notify unless it becomes aware that the > connection has already been closed by the transport sender (e.g., > the closure was indicated by TCP). > = > When no data is received from a connection for a long time (where > the application decides what "long" means), a TLS server MAY close > the connection. The TLS server MUST attempt to initiate an > exchange of close_notify alerts with the transport sender before > closing the connection. The server that is unprepared to receive > any more data MAY close the connection after sending the > close_notify alert, thus generating an incomplete close on the > client side. When the client has received the close_notify alert > from the server and still has pending data to send, it SHOULD send > the pending data before sending the close_notify alert." > = > = > Comments? > Best regards, > Mohamad Badra > CNRS - LIMOS Laboratory > = _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf alert, > thus generating an incomplete close on the transport sender > side. When the transport sender (TLS client) has received the > close_notify alert from the transport receiver and still has > pending data to send, it SHOULD send the pending data before > sending the close_notify alert." > = > = > I think the above text would appear to contradict a TLS MUST. Wouldn't? > = > I also think the above text describes when to close connection for both = > sides. e.g, when the client doesn't want to initial any syslog message = > or when the server found there is no data on the wire for a long time. > = > With respect to that, I think we should propose a simalar text, a = > modified text is below: > = > "A TLS client (NETCONF manager) MUST close the associated TLS > connection if the connection is not expected to deliver any rpc > operation later. It MUST send a TLS close_notify alert before > closing the connection. The client MAY choose to not wait for the > TLS server (NETCONF agent) close_notify alert and simply close the > connection, thus generating an incomplete close on the server > side. Once the server gets a close_notify from the client, it > MUST reply with a close_notify unless it becomes aware that the > connection has already been closed by the transport sender (e.g., > the closure was indicated by TCP). > = > When no data is received from a connection for a long time (where > the application decides what "long" means), a TLS server MAY close > the connection. The TLS server MUST attempt to initiate an > exchange of close_notify alerts with the transport sender before > closing the connection. The server that is unprepared to receive > any more data MAY close the connection after sending the > close_notify alert, thus generating an incomplete close on the > client side. When the client has received the close_notify alert > from the server and still has pending data to send, it SHOULD send > the pending data before sending the close_notify alert." > = > = > Comments? > Best regards, > Mohamad Badra > CNRS - LIMOS Laboratory > = _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 12:00:48 2008 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 86A533A6B66; Mon, 29 Sep 2008 12:00:48 -0700 (PDT) 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 838D83A6B66 for ; Mon, 29 Sep 2008 12:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQYfRCnqpFP7 for ; Mon, 29 Sep 2008 12:00:46 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 36C7428C127 for ; Mon, 29 Sep 2008 12:00:43 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id LiUp1a00D16AWCUA9j0f33; Mon, 29 Sep 2008 19:00:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Lj0d1a00C4HwxpC8Sj0e7a; Mon, 29 Sep 2008 19:00:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=NK_fnipnCRsA:10 a=bH-OIGKTXmwA:10 a=48vgC7mUAAAA:8 a=-rfTg5z2wFw-5FXC_EwA:9 a=lWFTstjybw6zWNkJIB4A:7 a=_0l0SF-wvBmQ9uUo5PxkXsiOA1YA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 15:00:37 -0400 Message-ID: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Thread-Index: AckgFhy4+T7oOvKsR8mFow0ayzn08QCTihgA Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, In syslog WG, we worked with the AD to decide what text was needed regarding ciphersuite support. We removed ciphersuite text that was redundant with TLS specs, and simplified ciphersuite support to this: TLS typically uses certificates [RFC5280] to authenticate peers. Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported. All the major toolkits also know how to do TLS1.0 and TLS1.1 required suites, and many suites hve been updated to support the TLS1.2 required suite. If an implmentation is non-compliant to TLS1.2, it will presumably fallback to a required ciphersuites for the latest supported TLS version. The language also allows for new requirements for new TLS versions, with the same expected falFrom netconf-bounces@ietf.org Mon Sep 29 12:00:48 2008 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 86A533A6B66; Mon, 29 Sep 2008 12:00:48 -0700 (PDT) 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 838D83A6B66 for ; Mon, 29 Sep 2008 12:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQYfRCnqpFP7 for ; Mon, 29 Sep 2008 12:00:46 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 36C7428C127 for ; Mon, 29 Sep 2008 12:00:43 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id LiUp1a00D16AWCUA9j0f33; Mon, 29 Sep 2008 19:00:39 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id Lj0d1a00C4HwxpC8Sj0e7a; Mon, 29 Sep 2008 19:00:39 +0000 X-Authority-Analysis: v=1.0 c=1 a=NK_fnipnCRsA:10 a=bH-OIGKTXmwA:10 a=48vgC7mUAAAA:8 a=-rfTg5z2wFw-5FXC_EwA:9 a=lWFTstjybw6zWNkJIB4A:7 a=_0l0SF-wvBmQ9uUo5PxkXsiOA1YA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David B Harrington" To: , References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 15:00:37 -0400 Message-ID: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> Thread-Index: AckgFhy4+T7oOvKsR8mFow0ayzn08QCTihgA Cc: netconf@ietf.org Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, In syslog WG, we worked with the AD to decide what text was needed regarding ciphersuite support. We removed ciphersuite text that was redundant with TLS specs, and simplified ciphersuite support to this: TLS typically uses certificates [RFC5280] to authenticate peers. Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported. All the major toolkits also know how to do TLS1.0 and TLS1.1 required suites, and many suites hve been updated to support the TLS1.2 required suite. If an implmentation is non-compliant to TLS1.2, it will presumably fallback to a required ciphersuites for the latest supported TLS version. The language also allows for new requirements for new TLS versions, with the same expectlback effect to the TLS1.2 required suite. draft-ietf-syslog-transport-tls-14.txt will be out soon. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Friday, September 26, 2008 4:25 PM > To: j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > > Dear Juergen, > > Thank you for your comments. Responses are in-line. > > >> With this mail we want to start a WGLC for the draft NETCONF over > >> TLS, which is proposed to publish as a Proposed Standard RFC. > > > I have read and here are my > comments: > > > a) I am wondering about PSK support. RFC 4279 says in the > > applicability statement: > > > > The ciphersuites defined in this document are intended for a rather > > limited set of applications, usually involving only a very small > > number of clients and servers. Even in such environments, other > > alternatives may be more appropriate. > > > > With NETMOD deployed on many bridges and routers and some host > > systems in the future, we might have a small number of clients with > > a large number of servers and a key management problem. > > > Summary: I think the document has improved quite a bit > since its early > > days. I am still not 100% convinced about the PSK support > and it being > > required to implement. > > Is it sufficient to use the key word "MAY" as following to > make optional > the PSK use? Or do you prefer to entirely remove PSK related > text? In the > first case: > > OLD: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 > describes how > the client and server mutually authenticate one another > using a pre- > shared key (PSK). > > NEW: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 > describes how > the client and server MAY mutually authenticate one another using a > pre-shared key (PSK). ^^^ > > > b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA > > (please add a reference to RFC 4279 where this cipher suite is > > defined to help the reader) but does not spell out any other cipher > > suite requirement, essentially making > > TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps > > there needs to be more text about required to implement cipher > > suites or pointers to "standard" required to implement TLS cipher > > suites that apply here as well. > > Yes, this is true. With TLS, and in the absence of an > application profile > standard specifying otherwise, a TLS-compliant application > MUST implement > a cipher suite, which varies with the TLS version, i.e.: > > TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA > TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA > TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA > > Please don't hesitate to propose a better text, here is a tentative: > > OLD: > > A compliant implementation of the protocol specified in > this document > MUST implement the cipher suite > TLS_DHE_PSK_WITH_AES_128_CBC_SHA and > MAY implement any TLS cipher suite that provides mutual > authentication. > > NEW: > > A compliant implementation of the protocol specified in > this document > MAY implement any TLS cipher suite that provides mutual > authentication. > > For authentication based on PSKs, a compliant implementation MUST > implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. > > Fro authentication based on public key certificates, a compliant > implementation MUST implement the 'mandatory cipher suite' > specified by > each TLS version (e.g. with TLS 1.2, the mandotary cipher suite is > TLS_RSA_WITH_AES_128_CBC_SHA). > > > c) I suggest to remove "simple" from the text in the introduction. > > OK. > > > d) What does "highly recommended" mean in terms of IETF terminology? > > Is this the same as RECOMMENDED? I suggest to stick to the well > > defined and understood IETF terminology. > > OK. > > Best regards, > Badra > _______________________________________________ > 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 ed fallback effect to the TLS1.2 required suite. draft-ietf-syslog-transport-tls-14.txt will be out soon. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Friday, September 26, 2008 4:25 PM > To: j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt > > Dear Juergen, > > Thank you for your comments. Responses are in-line. > > >> With this mail we want to start a WGLC for the draft NETCONF over > >> TLS, which is proposed to publish as a Proposed Standard RFC. > > > I have read and here are my > comments: > > > a) I am wondering about PSK support. RFC 4279 says in the > > applicability statement: > > > > The ciphersuites defined in this document are intended for a rather > > limited set of applications, usually involving only a very small > > number of clients and servers. Even in such environments, other > > alternatives may be more appropriate. > > > > With NETMOD deployed on many bridges and routers and some host > > systems in the future, we might have a small number of clients with > > a large number of servers and a key management problem. > > > Summary: I think the document has improved quite a bit > since its early > > days. I am still not 100% convinced about the PSK support > and it being > > required to implement. > > Is it sufficient to use the key word "MAY" as following to > make optional > the PSK use? Or do you prefer to entirely remove PSK related > text? In the > first case: > > OLD: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 > describes how > the client and server mutually authenticate one another > using a pre- > shared key (PSK). > > NEW: > > Section 3.1 describes how the client authenticates the server if > public key certificates are provided by the server, section 3.2 > describes how the server authenticates the client if public key > certificates are provided by the client, and section 3.3 > describes how > the client and server MAY mutually authenticate one another using a > pre-shared key (PSK). ^^^ > > > b) Section 4 requires to implement TLS_DHE_PSK_WITH_AES_128_CBC_SHA > > (please add a reference to RFC 4279 where this cipher suite is > > defined to help the reader) but does not spell out any other cipher > > suite requirement, essentially making > > TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps > > there needs to be more text about required to implement cipher > > suites or pointers to "standard" required to implement TLS cipher > > suites that apply here as well. > > Yes, this is true. With TLS, and in the absence of an > application profile > standard specifying otherwise, a TLS-compliant application > MUST implement > a cipher suite, which varies with the TLS version, i.e.: > > TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA > TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA > TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA > > Please don't hesitate to propose a better text, here is a tentative: > > OLD: > > A compliant implementation of the protocol specified in > this document > MUST implement the cipher suite > TLS_DHE_PSK_WITH_AES_128_CBC_SHA and > MAY implement any TLS cipher suite that provides mutual > authentication. > > NEW: > > A compliant implementation of the protocol specified in > this document > MAY implement any TLS cipher suite that provides mutual > authentication. > > For authentication based on PSKs, a compliant implementation MUST > implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. > > Fro authentication based on public key certificates, a compliant > implementation MUST implement the 'mandatory cipher suite' > specified by > each TLS version (e.g. with TLS 1.2, the mandotary cipher suite is > TLS_RSA_WITH_AES_128_CBC_SHA). > > > c) I suggest to remove "simple" from the text in the introduction. > > OK. > > > d) What does "highly recommended" mean in terms of IETF terminology? > > Is this the same as RECOMMENDED? I suggest to stick to the well > > defined and understood IETF terminology. > > OK. > > Best regards, > Badra > _______________________________________________ > 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 Mon Sep 29 12:10:20 2008 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 400FD3A6870; Mon, 29 Sep 2008 12:10:20 -0700 (PDT) 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 2BB303A6870 for ; Mon, 29 Sep 2008 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Wbl1AzJp10+S for ; Mon, 29 Sep 2008 12:10:18 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 477F13A67A5 for ; Mon, 29 Sep 2008 12:10:17 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id LiY91a0020FhH24A5jAHxC; Mon, 29 Sep 2008 19:10:17 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id LjAE1a00S4HwxpC8UjAFuf; Mon, 29 Sep 2008 19:10:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=r4FD010rjhwA:10 a=nmih3Sw-o_AA:10 a=48vgC7mUAAAA:8 a=7BE655bt_n4Mym1yBlYA:9 a=GWwI6bh4kofAVMVNlnAA:7 a=7jiW5wO5lrDZZZLlfA2Ds6WdEiwA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 15:10:14 -0400 Message-ID: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> Thread-Index: Ackgq6Scy+RBqdNcQGqweJqyVrCNRABunVcQ Cc: =?iso-8859-1?B?J8In?= Subject: Re: [Netconf] =?iso-8859-1?q?=A0=A0WGLC=A0for=A0draft-ietf-netconf-t_?= =?iso-8859-1?q?_ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) has updated that section to make a clearer distinction between the TLS actions and the application actions. Transport sender and transport receiver refer to syslog application fuctionality, and they coordinate the closure actions. = A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A transport sender (TLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the transport receiver (TLS server) side. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (TLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the transport sender side. When the transport sender (TLS client) has received the close_notify alert from the transport receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org = > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Saturday, September 27, 2008 9:50 AM > To: j.schoenwaelder@jacobs-university.de > Cc: =C2 > Subject: [Netconf] Re: WGLC for draft-ietf-netconf-t ls-04.txt > = > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang = > 90002624 wrote: > >> Hi, > >> in section 2, it says, > >> "The other party MUST respond with a close_notify alert of > >> its own and close down the connection immediately, discarding any > >> pending writes" > >> I wanna ask why immediately instead of sending pening writes before > >> close down the connection. > > > > And I like to add whether it is normal practice that the = > TLS teardown > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > discusses closure alerts in TLS 1.2 and I like to understand why we > > need additional text for NETCONF over TLS. > = > = > I think we should correct that. What about adopting the text = > of section > 4.4 of syslog-tls > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpo > rt-tls-13.txt). > = > "A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any NETCONF messages = > later. It > MUST send a TLS close_notify alert before closing the = > connection. A > client MAY choose to not wait for the server's = > close_notify alert and > simply close the connection, thus generating an incomplete close on > the server side. Once the server gets a close_notify from the > client, it MUST reply with a close_notify unless it becomes aware > that the connection has already been closed by the client = > (e.g., the > closure was indicated by TCP). > = > When no data is received from a connection for a long time = > (where the > application decides what "long" means), a server MAY close the > connection. The server MUST attempt to initiate an exchange of > close_notify alerts with the client before closing the connection. > Servers that are unprepared to receive any more data MAY close the > connection after sending the close_notify alert, thus generating an > incomplete close on the client side. When the client has received > the close_notify alert from the server and still has = > pending data to > send, it SHOULD send the pending data before sending the = > close_notify > alert." > = > Best regards, > _______________________________________________ > 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 Mon Sep 29 12:10:20 2008 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 400FD3A6870; Mon, 29 Sep 2008 12:10:20 -0700 (PDT) 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 2BB303A6870 for ; Mon, 29 Sep 2008 12:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=1.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 Wbl1AzJp10+S for ; Mon, 29 Sep 2008 12:10:18 -0700 (PDT) Received: from QMTA05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by core3.amsl.com (Postfix) with ESMTP id 477F13A67A5 for ; Mon, 29 Sep 2008 12:10:17 -0700 (PDT) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA05.emeryville.ca.mail.comcast.net with comcast id LiY91a0020FhH24A5jAHxC; Mon, 29 Sep 2008 19:10:17 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id LjAE1a00S4HwxpC8UjAFuf; Mon, 29 Sep 2008 19:10:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=r4FD010rjhwA:10 a=nmih3Sw-o_AA:10 a=48vgC7mUAAAA:8 a=7BE655bt_n4Mym1yBlYA:9 a=GWwI6bh4kofAVMVNlnAA:7 a=7jiW5wO5lrDZZZLlfA2Ds6WdEiwA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=zeshHG33Dl4A:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> Date: Mon, 29 Sep 2008 15:10:14 -0400 Message-ID: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> Thread-Index: Ackgq6Scy+RBqdNcQGqweJqyVrCNRABunVcQ Cc: =?iso-8859-1?B?J8In?= Subject: Re: [Netconf] =?iso-8859-1?q?=A0=A0WGLC=A0for=A0draft-ietf-netconf-t_?= =?iso-8859-1?q?_ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) has updated that section to make a clearer distinction between the TLS actions and the application actions. Transport sender and transport receiver refer to syslog application fuctionality, and they coordinate the closure actions. = A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A transport sender (TLS client) MAY choose to not wait for the transport receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the transport receiver (TLS server) side. Once the transport receiver gets a close_notify from the transport sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the transport sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a transport receiver MAY close the connection. The transport receiver (TLS server) MUST attempt to initiate an exchange of close_notify alerts with the transport sender before closing the connection. Transport receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the transport sender side. When the transport sender (TLS client) has received the close_notify alert from the transport receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: netconf-bounces@ietf.org = > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > Sent: Saturday, September 27, 2008 9:50 AM > To: j.schoenwaelder@jacobs-university.de > Cc: =C2 > Subject: [Netconf] Re: WGLC for draft-ietf-netconf-t ls-04.txt > = > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang = > 90002624 wrote: > >> Hi, > >> in section 2, it says, > >> "The other party MUST respond with a close_notify alert of > >> its own and close down the connection immediately, discarding any > >> pending writes" > >> I wanna ask why immediately instead of sending pening writes before > >> close down the connection. > > > > And I like to add whether it is normal practice that the = > TLS teardown > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > discusses closure alerts in TLS 1.2 and I like to understand why we > > need additional text for NETCONF over TLS. > = > = > I think we should correct that. What about adopting the text = > of section > 4.4 of syslog-tls > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpo > rt-tls-13.txt). > = > "A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any NETCONF messages = > later. It > MUST send a TLS close_notify alert before closing the = > connection. A > client MAY choose to not wait for the server's = > close_notify alert and > simply close the connection, thus generating an incomplete close on > the server side. Once the server gets a close_notify from the > client, it MUST reply with a close_notify unless it becomes aware > that the connection has already been closed by the client = > (e.g., the > closure was indicated by TCP). > = > When no data is received from a connection for a long time = > (where the > application decides what "long" means), a server MAY close the > connection. The server MUST attempt to initiate an exchange of > close_notify alerts with the client before closing the connection. > Servers that are unprepared to receive any more data MAY close the > connection after sending the close_notify alert, thus generating an > incomplete close on the client side. When the client has received > the close_notify alert from the server and still has = > pending data to > send, it SHOULD send the pending data before sending the = > close_notify > alert." > = > Best regards, > _______________________________________________ > 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 Mon Sep 29 12:14:08 2008 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 8C11C3A690A; Mon, 29 Sep 2008 12:14:08 -0700 (PDT) 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 E3FAE3A67D8 for ; Mon, 29 Sep 2008 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8WWgTtyRKQD for ; Mon, 29 Sep 2008 12:14:07 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E9AEA3A67A5 for ; Mon, 29 Sep 2008 12:14:06 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TKEB4r803032; Mon, 29 Sep 2008 21:14:11 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 21:13:06 +0200 (CEST) Message-ID: <59731.88.164.98.77.1222715586.squirrel@www.isima.fr> In-Reply-To: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 21:13:06 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 21:14:11 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear David, > In syslog WG, we worked with the AD to decide what text was needed > regarding ciphersuite support. We removed ciphersuite text that was > redundant with TLS specs, and simplified ciphersuite support to this: > > TLS typically uses certificates [RFC5280] to authenticate peers. > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. Thank you for this better text. I will certainly integrate it entirely. However, there is still a need to add a simple sentence on the PSK authentication (the document optionally enable PSK authentication): For authentication based on PSKs, a compliant implementation MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 12:14:08 2008 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 8C11C3A690A; Mon, 29 Sep 2008 12:14:08 -0700 (PDT) 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 E3FAE3A67D8 for ; Mon, 29 Sep 2008 12:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8WWgTtyRKQD for ; Mon, 29 Sep 2008 12:14:07 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E9AEA3A67A5 for ; Mon, 29 Sep 2008 12:14:06 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TKEB4r803032; Mon, 29 Sep 2008 21:14:11 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 21:13:06 +0200 (CEST) Message-ID: <59731.88.164.98.77.1222715586.squirrel@www.isima.fr> In-Reply-To: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 21:13:06 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 21:14:11 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Dear David, > In syslog WG, we worked with the AD to decide what text was needed > regarding ciphersuite support. We removed ciphersuite text that was > redundant with TLS specs, and simplified ciphersuite support to this: > > TLS typically uses certificates [RFC5280] to authenticate peers. > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. Thank you for this better text. I will certainly integrate it entirely. However, there is still a need to add a simple sentence on the PSK authentication (the document optionally enable PSK authentication): For authentication based on PSKs, a compliant implementation MUST implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 12:59:44 2008 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 4C4173A6B2E; Mon, 29 Sep 2008 12:59:44 -0700 (PDT) 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 94DAC3A693C for ; Mon, 29 Sep 2008 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBx78vcYuIJO for ; Mon, 29 Sep 2008 12:59:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 835C03A6781 for ; Mon, 29 Sep 2008 12:59:41 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TKxgWN995352; Mon, 29 Sep 2008 21:59:42 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 21:58:37 +0200 (CEST) Message-ID: <60137.88.164.98.77.1222718317.squirrel@www.isima.fr> In-Reply-To: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <00bc01c92267$0205f310$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 21:58:37 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 21:59:43 +0100 (WEST) Cc: =?utf-8?Q?=C2_'=C3=82'=C2?= Subject: Re: [Netconf] =?utf-8?b?77+977+9V0dMQ++/vWZvcu+/vWRyYWZ0LWlldGYtbmV0?= =?utf-8?q?con__f-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi David, > FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) > has updated that section to make a clearer distinction between the TLS > actions and the application actions. Transport sender and transport > receiver refer to syslog application fuctionality, and they coordinate > the closure actions. > > A transport sender MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It > MUST send a TLS close_notify alert before closing the connection. > A > transport sender (TLS client) MAY choose to not wait for the > transport receiver's close_notify alert and simply close the > connection, thus generating an incomplete close on the transport > receiver (TLS server) side. Once the transport receiver gets a > close_notify from the transport sender, it MUST reply with a > close_notify unless it becomes aware that the connection has > already > been closed by the transport sender (e.g., the closure was > indicated > by TCP). > > When no data is received from a connection for a long time (where > the > application decides what "long" means), a transport receiver MAY > close the connection. The transport receiver (TLS server) MUST > attempt to initiate an exchange of close_notify alerts with the > transport sender before closing the connection. Transport > receivers > that are unprepared to receive any more data MAY close the > connection > after sending the close_notify alert, thus generating an incomplete > close on the transport sender side. When the transport sender (TLS > client) has received the close_notify alert from the transport > receiver and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. > The same text is being used for NETCONF over TLS, with one exception, we need to describe when to close connection for both sides (when client doesn't want to initial any rpc operation or when the server found there is no data on the wire for a long time). (I sent the text to the mailing list this morning: http://www.ietf.org/mail-archive/web/netconf/current/msg03838.html) Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 12:59:44 2008 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 4C4173A6B2E; Mon, 29 Sep 2008 12:59:44 -0700 (PDT) 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 94DAC3A693C for ; Mon, 29 Sep 2008 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBx78vcYuIJO for ; Mon, 29 Sep 2008 12:59:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 835C03A6781 for ; Mon, 29 Sep 2008 12:59:41 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TKxgWN995352; Mon, 29 Sep 2008 21:59:42 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 21:58:37 +0200 (CEST) Message-ID: <60137.88.164.98.77.1222718317.squirrel@www.isima.fr> In-Reply-To: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <00bc01c92267$0205f310$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 21:58:37 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 21:59:43 +0100 (WEST) Cc: =?utf-8?Q?=C2_'=C3=82'=C2?= Subject: Re: [Netconf] =?utf-8?b?77+977+9V0dMQ++/vWZvcu+/vWRyYWZ0LWlldGYtbmV0?= =?utf-8?q?con__f-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi David, > FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) > has updated that section to make a clearer distinction between the TLS > actions and the application actions. Transport sender and transport > receiver refer to syslog application fuctionality, and they coordinate > the closure actions. > > A transport sender MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It > MUST send a TLS close_notify alert before closing the connection. > A > transport sender (TLS client) MAY choose to not wait for the > transport receiver's close_notify alert and simply close the > connection, thus generating an incomplete close on the transport > receiver (TLS server) side. Once the transport receiver gets a > close_notify from the transport sender, it MUST reply with a > close_notify unless it becomes aware that the connection has > already > been closed by the transport sender (e.g., the closure was > indicated > by TCP). > > When no data is received from a connection for a long time (where > the > application decides what "long" means), a transport receiver MAY > close the connection. The transport receiver (TLS server) MUST > attempt to initiate an exchange of close_notify alerts with the > transport sender before closing the connection. Transport > receivers > that are unprepared to receive any more data MAY close the > connection > after sending the close_notify alert, thus generating an incomplete > close on the transport sender side. When the transport sender (TLS > client) has received the close_notify alert from the transport > receiver and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. > The same text is being used for NETCONF over TLS, with one exception, we need to describe when to close connection for both sides (when client doesn't want to initial any rpc operation or when the server found there is no data on the wire for a long time). (I sent the text to the mailing list this morning: http://www.ietf.org/mail-archive/web/netconf/current/msg03838.html) Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Mon Sep 29 14:08:22 2008 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 0BAF73A6AD9; Mon, 29 Sep 2008 14:08:22 -0700 (PDT) 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 39CDD3A6A81 for ; Mon, 29 Sep 2008 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTB+OT9pfcBD for ; Mon, 29 Sep 2008 14:08:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B39AD3A6A43 for ; Mon, 29 Sep 2008 14:08:18 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TM8LpP761998; Mon, 29 Sep 2008 23:08:21 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 23:07:16 +0200 (CEST) Message-ID: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> In-Reply-To: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 23:07:16 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 23:08:21 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Here is a tentative to decide what text was needed regarding ciphersuite support. 4. Cipher Suite Requirements Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides mutual authentication. Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported. In the case of the pre-shared key authentication (described in Section 3.3), implementations are REQUIRED to support the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. Comments? Best regards, Badra > Hi, > > In syslog WG, we worked with the AD to decide what text was needed > regarding ciphersuite support. We removed ciphersuite text that was > redundant with TLS specs, and simplified ciphersuite support to this: > > TLS typically uses certificates [RFC5280] to authenticate peers. > Implementations MUST From netconf-bounces@ietf.org Mon Sep 29 14:08:22 2008 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 0BAF73A6AD9; Mon, 29 Sep 2008 14:08:22 -0700 (PDT) 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 39CDD3A6A81 for ; Mon, 29 Sep 2008 14:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTB+OT9pfcBD for ; Mon, 29 Sep 2008 14:08:19 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id B39AD3A6A43 for ; Mon, 29 Sep 2008 14:08:18 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8TM8LpP761998; Mon, 29 Sep 2008 23:08:21 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Mon, 29 Sep 2008 23:07:16 +0200 (CEST) Message-ID: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> In-Reply-To: <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> Date: Mon, 29 Sep 2008 23:07:16 +0200 (CEST) From: badra@isima.fr To: =?utf-8?Q?David=C2_B=C2_Harrington=C2?= User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 29 Sep 2008 23:08:21 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?b?IFJFOsKgwqBXR0xDwqBmb3LCoGRyYWZ0LWlldGYtbmV0?= =?utf-8?q?conf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, Here is a tentative to decide what text was needed regarding ciphersuite support. 4. Cipher Suite Requirements Implementation of the protocol specified in this document MAY implement any TLS cipher suite that provides mutual authentication. Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to support the mandatory to implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to future versions of TLS, in which case the mandatory to implement cipher suite for the implemented version MUST be supported. In the case of the pre-shared key authentication (described in Section 3.3), implementations are REQUIRED to support the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. Comments? Best regards, Badra > Hi, > > In syslog WG, we worked with the AD to decide what text was needed > regarding ciphersuite support. We removed ciphersuite text that was > redundant with TLS specs, and simplified ciphersuite support to this: > > TLS typically uses certificates [RFC5280] to authenticate peers. > Implementationssupport TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > All the major toolkits also know how to do TLS1.0 and TLS1.1 required > suites, and many suites hve been updated to support the TLS1.2 > required suite. If an implmentation is non-compliant to TLS1.2, it > will presumably fallback to a required ciphersuites for the latest > supported TLS version. The language also allows for new requirements > for new TLS versions, with the same expected fallback effect to the > TLS1.2 required suite. > > draft-ietf-syslog-transport-tls-14.txt will be out soon. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr >> Sent: Friday, September 26, 2008 4:25 PM >> To: j.schoenwaelder@jacobs-university.de >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt >> >> Dear Juergen, >> >> Thank you for your comments. Responses are in-line. >> >> >> With this mail we want to start a WGLC for the draft NETCONF over >> >> TLS, which is proposed to publish as a Proposed Standard RFC. >> >> > I have read and here are my >> comments: >> >> > a) I am wondering about PSK support. RFC 4279 says in the >> > applicability statement: >> > >> > The ciphersuites defined in this document are intended for a > rather >> > limited set of applications, usually involving only a very small >> > number of clients and servers. Even in such environments, other >> > alternatives may be more appropriate. >> > >> > With NETMOD deployed on many bridges and routers and some host >> > systems in the future, we might have a small number of clients > with >> > a large number of servers and a key management problem. >> >> > Summary: I think the document has improved quite a bit >> since its early >> > days. I am still not 100% convinced about the PSK support >> and it being >> > required to implement. >> >> Is it sufficient to use the key word "MAY" as following to >> make optional >> the PSK use? Or do you prefer to entirely remove PSK related >> text? In the >> first case: >> >> OLD: >> >> Section 3.1 describes how the client authenticates the server if >> public key certificates are provided by the server, section 3.2 >> describes how the server authenticates the client if public key >> certificates are provided by the client, and section 3.3 >> describes how >> the client and server mutually authenticate one another >> using a pre- >> shared key (PSK). >> >> NEW: >> >> Section 3.1 describes how the client authenticates the server if >> public key certificates are provided by the server, section 3.2 >> describes how the server authenticates the client if public key >> certificates are provided by the client, and section 3.3 >> describes how >> the client and server MAY mutually authenticate one another using > a >> pre-shared key (PSK). ^^^ >> >> > b) Section 4 requires to implement > TLS_DHE_PSK_WITH_AES_128_CBC_SHA >> > (please add a reference to RFC 4279 where this cipher suite is >> > defined to help the reader) but does not spell out any other > cipher >> > suite requirement, essentially making >> > TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps >> > there needs to be more text about required to implement cipher >> > suites or pointers to "standard" required to implement TLS cipher >> > suites that apply here as well. >> >> Yes, this is true. With TLS, and in the absence of an >> application profile >> standard specifying otherwise, a TLS-compliant application >> MUST implement >> a cipher suite, which varies with the TLS version, i.e.: >> >> TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA >> TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA >> TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> >> Please don't hesitate to propose a better text, here is a tentative: >> >> OLD: >> >> A compliant implementation of the protocol specified in >> this document >> MUST implement the cipher suite >> TLS_DHE_PSK_WITH_AES_128_CBC_SHA and >> MAY implement any TLS cipher suite that provides mutual >> authentication. >> >> NEW: >> >> A compliant implementation of the protocol specified in >> this document >> MAY implement any TLS cipher suite that provides mutual >> authentication. >> >> For authentication based on PSKs, a compliant implementation MUST >> implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. >> >> Fro authentication based on public key certificates, a compliant >> implementation MUST implement the 'mandatory cipher suite' >> specified by >> each TLS version (e.g. with TLS 1.2, the mandotary cipher suite > is >> TLS_RSA_WITH_AES_128_CBC_SHA). >> >> > c) I suggest to remove "simple" from the text in the introduction. >> >> OK. >> >> > d) What does "highly recommended" mean in terms of IETF > terminology? >> > Is this the same as RECOMMENDED? I suggest to stick to the well >> > defined and understood IETF terminology. >> >> OK. >> >> Best regards, >> Badra >> _______________________________________________ >> 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 MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > All the major toolkits also know how to do TLS1.0 and TLS1.1 required > suites, and many suites hve been updated to support the TLS1.2 > required suite. If an implmentation is non-compliant to TLS1.2, it > will presumably fallback to a required ciphersuites for the latest > supported TLS version. The language also allows for new requirements > for new TLS versions, with the same expected fallback effect to the > TLS1.2 required suite. > > draft-ietf-syslog-transport-tls-14.txt will be out soon. > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > >> -----Original Message----- >> From: netconf-bounces@ietf.org >> [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr >> Sent: Friday, September 26, 2008 4:25 PM >> To: j.schoenwaelder@jacobs-university.de >> Cc: netconf@ietf.org >> Subject: Re: [Netconf] WGLC for draft-ietf-netconf-tls-04.txt >> >> Dear Juergen, >> >> Thank you for your comments. Responses are in-line. >> >> >> With this mail we want to start a WGLC for the draft NETCONF over >> >> TLS, which is proposed to publish as a Proposed Standard RFC. >> >> > I have read and here are my >> comments: >> >> > a) I am wondering about PSK support. RFC 4279 says in the >> > applicability statement: >> > >> > The ciphersuites defined in this document are intended for a > rather >> > limited set of applications, usually involving only a very small >> > number of clients and servers. Even in such environments, other >> > alternatives may be more appropriate. >> > >> > With NETMOD deployed on many bridges and routers and some host >> > systems in the future, we might have a small number of clients > with >> > a large number of servers and a key management problem. >> >> > Summary: I think the document has improved quite a bit >> since its early >> > days. I am still not 100% convinced about the PSK support >> and it being >> > required to implement. >> >> Is it sufficient to use the key word "MAY" as following to >> make optional >> the PSK use? Or do you prefer to entirely remove PSK related >> text? In the >> first case: >> >> OLD: >> >> Section 3.1 describes how the client authenticates the server if >> public key certificates are provided by the server, section 3.2 >> describes how the server authenticates the client if public key >> certificates are provided by the client, and section 3.3 >> describes how >> the client and server mutually authenticate one another >> using a pre- >> shared key (PSK). >> >> NEW: >> >> Section 3.1 describes how the client authenticates the server if >> public key certificates are provided by the server, section 3.2 >> describes how the server authenticates the client if public key >> certificates are provided by the client, and section 3.3 >> describes how >> the client and server MAY mutually authenticate one another using > a >> pre-shared key (PSK). ^^^ >> >> > b) Section 4 requires to implement > TLS_DHE_PSK_WITH_AES_128_CBC_SHA >> > (please add a reference to RFC 4279 where this cipher suite is >> > defined to help the reader) but does not spell out any other > cipher >> > suite requirement, essentially making >> > TLS_DHE_PSK_WITH_AES_128_CBC_SHA the common denominator. Perhaps >> > there needs to be more text about required to implement cipher >> > suites or pointers to "standard" required to implement TLS cipher >> > suites that apply here as well. >> >> Yes, this is true. With TLS, and in the absence of an >> application profile >> standard specifying otherwise, a TLS-compliant application >> MUST implement >> a cipher suite, which varies with the TLS version, i.e.: >> >> TLS 1.2: TLS_RSA_WITH_AES_128_CBC_SHA >> TLS 1.1: TLS_RSA_WITH_3DES_EDE_CBC_SHA >> TLS 1.0: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA >> >> Please don't hesitate to propose a better text, here is a tentative: >> >> OLD: >> >> A compliant implementation of the protocol specified in >> this document >> MUST implement the cipher suite >> TLS_DHE_PSK_WITH_AES_128_CBC_SHA and >> MAY implement any TLS cipher suite that provides mutual >> authentication. >> >> NEW: >> >> A compliant implementation of the protocol specified in >> this document >> MAY implement any TLS cipher suite that provides mutual >> authentication. >> >> For authentication based on PSKs, a compliant implementation MUST >> implement the cipher suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA. >> >> Fro authentication based on public key certificates, a compliant >> implementation MUST implement the 'mandatory cipher suite' >> specified by >> each TLS version (e.g. with TLS 1.2, the mandotary cipher suite > is >> TLS_RSA_WITH_AES_128_CBC_SHA). >> >> > c) I suggest to remove "simple" from the text in the introduction. >> >> OK. >> >> > d) What does "highly recommended" mean in terms of IETF > terminology? >> > Is this the same as RECOMMENDED? I suggest to stick to the well >> > defined and understood IETF terminology. >> >> OK. >> >> Best regards, >> Badra >> _______________________________________________ >> 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 Mon Sep 29 14:20:15 2008 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 075053A6AEF; Mon, 29 Sep 2008 14:20:15 -0700 (PDT) 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 068F43A6AEF for ; Mon, 29 Sep 2008 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wYYlIC0xqIW6 for ; Mon, 29 Sep 2008 14:20:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E9A663A6834 for ; Mon, 29 Sep 2008 14:20:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 429DDC0007; Mon, 29 Sep 2008 23:20:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qRbbsRG5upMY; Mon, 29 Sep 2008 23:20:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F38CC0013; Mon, 29 Sep 2008 23:20:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 056027D5705; Mon, 29 Sep 2008 23:20:18 +0200 (CEST) Date: Mon, 29 Sep 2008 23:20:18 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080929212018.GA23773@elstar.local> Mail-Followup-To: badra@isima.fr, David? B? Harrington? , ? References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt 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, Sep 29, 2008 at 11:07:16PM +0200, badra@isima.fr wrote: > Here is a tentative to decide what text was needed regarding ciphersuite > support. > > 4. Cipher Suite Requirements > > Implementation of the protocol specified in this document MAY > implement any TLS cipher suite that provides mutual authentication. > > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > In the case of the pre-shared key authentication (described in > Section 3.3), implementations are REQUIRED to support the cipher > suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. Fine with me. /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 Sep 29 14:20:15 2008 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 075053A6AEF; Mon, 29 Sep 2008 14:20:15 -0700 (PDT) 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 068F43A6AEF for ; Mon, 29 Sep 2008 14:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 wYYlIC0xqIW6 for ; Mon, 29 Sep 2008 14:20:08 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E9A663A6834 for ; Mon, 29 Sep 2008 14:20:07 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 429DDC0007; Mon, 29 Sep 2008 23:20:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qRbbsRG5upMY; Mon, 29 Sep 2008 23:20:19 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F38CC0013; Mon, 29 Sep 2008 23:20:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 056027D5705; Mon, 29 Sep 2008 23:20:18 +0200 (CEST) Date: Mon, 29 Sep 2008 23:20:18 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080929212018.GA23773@elstar.local> Mail-Followup-To: badra@isima.fr, David? B? Harrington? , ? References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr> <00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC??for??draft-ietf-netconf-t ls-04.txt 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, Sep 29, 2008 at 11:07:16PM +0200, badra@isima.fr wrote: > Here is a tentative to decide what text was needed regarding ciphersuite > support. > > 4. Cipher Suite Requirements > > Implementation of the protocol specified in this document MAY > implement any TLS cipher suite that provides mutual authentication. > > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > In the case of the pre-shared key authentication (described in > Section 3.3), implementations are REQUIRED to support the cipher > suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. Fine with me. /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 Sep 30 06:02:10 2008 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 4D9273A6834; Tue, 30 Sep 2008 06:02:10 -0700 (PDT) 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 6BD6E3A66B4 for ; Tue, 30 Sep 2008 06:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8WWDEgETkfY for ; Tue, 30 Sep 2008 06:02:08 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6486C3A6834 for ; Tue, 30 Sep 2008 06:02:08 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000MKOEW5P1@usaga01-in.huawei.com> for netconf@ietf.org; Tue, 30 Sep 2008 06:02:29 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000F93EW39N@usaga01-in.huawei.com> for netconf@ietf.org; Tue, 30 Sep 2008 06:02:29 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Tue, 30 Sep 2008 21:02:10 +0800 Date: Tue, 30 Sep 2008 21:02:10 +0800 From: fanhuaxiang 90002624 In-reply-to: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> To: David Harrington Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <00bc01c92267$0205f310$0600a8c0@china.huawei.com> Cc: '?' Subject: Re: [Netconf] WGLC for draft-ietf-netconf-t ls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Hi, > > FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) > has updated that section to make a clearer distinction between the TLS > actions and the application actions. Transport sender and transport > receiver refer to syslog application fuctionality, and they coordinate > the closure actions. > > A transport sender MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It > MUST send a TLS close_notify alert before closing the connection. > A > transport sender (TLS client) MAY choose to not wait for the > transport receiver's close_notify alert and simply close the > connection, thus generating an incomplete close on the transport > receiver (TLS server) side. Once the transport receiver gets a > close_notify from the transport sender, it MUST reply with a > close_notify unless it becomes aware that the connection has > already > been closed by the transport sender (e.g., the closure was > indicated > by TCP). > > When no data is received from a connection for a long time (where > the > application decides what "long" means), a transport receiver MAY > close the connection. The transport receiver (TLS server) MUST > attempt to initiate an exchange of close_notify alerts with the > transport sender before closing the connection. Transport > receivers > that are unprepared to receive any more data MAY close the > connection > after sending the close_notify alert, thus generating an incomplete > close on the transport sender side. When the transport sender (TLS > client) has received the close_notify alert from the transport > receiver and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. wouldn't the last sentence contradict what specified in TLS rfc? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > > Sent: Saturday, September 27, 2008 9:50 AM > > To: j.schoenwaelder@jacobs-university.de > > Cc: ? > > Subject: [Netconf] Re: WGLC for draft-ietf-netconf-t ls-04.txt > > > > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang > > 90002624 wrote: > > >> Hi, > > >> in section 2, it says, > > >> "The other party MUST respond with a close_notify alert of > > >> its own and close down the connection immediately, discarding any > > >> pending writes" > > >> I wanna ask why immediately instead of sending pening writes > before > > >> close down the connection. > > > > > > And I like to add whether it is normal practice that the > > TLS teardown > > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > > discusses closure alerts in TLS 1.2 and I like to understand why > we > > > need additional text for NETCONF over TLS. > > > > > > I think we should correct that. What about adopting the text > > of section > > 4.4 of syslog-tls > > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpo > > rt-tls-13.txt). > > > > "A TLS client MUST close the associated TLS connection if the > > connection is not expected to deliver any NETCONF messages > > later. It > > MUST send a TLS close_notify alert before closing the > > connection. A > > client MAY choose to not wait for the server's > > close_notify alert and > > simply close the connection, thus generating an incomplete close > on > > the server side. Once the server gets a close_notify from the > > client, it MUST reply with a close_notify unless it becomes aware > > that the connection has already been closed by the client > > (e.g., the > > closure was indicated by TCP). > > > > When no data is received from a connection for a long time > > (where the > > application decides what "long" means), a server MAY close the > > connection. The server MUST attempt to initiate an exchange of > > close_notify alerts with the client before closing the > connection. > > Servers that are unprepared to receive any more data MAY close > the > > connection after sending the close_notify alert, thus generating > an > > incomplete close on the client side. When the client has > received > > the close_notify alert from the server and still has > > pending data to > > send, it SHOULD send the pending data before sending the > > close_notify > > alert." > > > > Best regards, > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 06:02:10 2008 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 4D9273A6834; Tue, 30 Sep 2008 06:02:10 -0700 (PDT) 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 6BD6E3A66B4 for ; Tue, 30 Sep 2008 06:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8WWDEgETkfY for ; Tue, 30 Sep 2008 06:02:08 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6486C3A6834 for ; Tue, 30 Sep 2008 06:02:08 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000MKOEW5P1@usaga01-in.huawei.com> for netconf@ietf.org; Tue, 30 Sep 2008 06:02:29 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8000F93EW39N@usaga01-in.huawei.com> for netconf@ietf.org; Tue, 30 Sep 2008 06:02:29 -0700 (PDT) Received: from [172.24.1.3] (Forwarded-For: [220.249.46.106]) by szxmc04-in.huawei.com (mshttpd); Tue, 30 Sep 2008 21:02:10 +0800 Date: Tue, 30 Sep 2008 21:02:10 +0800 From: fanhuaxiang 90002624 In-reply-to: <00bc01c92267$0205f310$0600a8c0@china.huawei.com> To: David Harrington Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: el Content-disposition: inline X-Accept-Language: el Priority: normal References: <20080927090622.GA431@elstar.local> <59304.88.164.98.77.1222523373.squirrel@www.isima.fr> <00bc01c92267$0205f310$0600a8c0@china.huawei.com> Cc: '?' Subject: Re: [Netconf] WGLC for draft-ietf-netconf-t ls-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org Hi, > Hi, > > FYI. draft-ietf-syslog-transport-tls-14 (currently under AD review) > has updated that section to make a clearer distinction between the TLS > actions and the application actions. Transport sender and transport > receiver refer to syslog application fuctionality, and they coordinate > the closure actions. > > A transport sender MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. > It > MUST send a TLS close_notify alert before closing the connection. > A > transport sender (TLS client) MAY choose to not wait for the > transport receiver's close_notify alert and simply close the > connection, thus generating an incomplete close on the transport > receiver (TLS server) side. Once the transport receiver gets a > close_notify from the transport sender, it MUST reply with a > close_notify unless it becomes aware that the connection has > already > been closed by the transport sender (e.g., the closure was > indicated > by TCP). > > When no data is received from a connection for a long time (where > the > application decides what "long" means), a transport receiver MAY > close the connection. The transport receiver (TLS server) MUST > attempt to initiate an exchange of close_notify alerts with the > transport sender before closing the connection. Transport > receivers > that are unprepared to receive any more data MAY close the > connection > after sending the close_notify alert, thus generating an incomplete > close on the transport sender side. When the transport sender (TLS > client) has received the close_notify alert from the transport > receiver and still has pending data to send, it SHOULD send the > pending data before sending the close_notify alert. wouldn't the last sentence contradict what specified in TLS rfc? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > > -----Original Message----- > > From: netconf-bounces@ietf.org > > [mailto:netconf-bounces@ietf.org] On Behalf Of badra@isima.fr > > Sent: Saturday, September 27, 2008 9:50 AM > > To: j.schoenwaelder@jacobs-university.de > > Cc: ? > > Subject: [Netconf] Re: WGLC for draft-ietf-netconf-t ls-04.txt > > > > > On Sat, Sep 27, 2008 at 02:05:51PM +0800, fanhuaxiang > > 90002624 wrote: > > >> Hi, > > >> in section 2, it says, > > >> "The other party MUST respond with a close_notify alert of > > >> its own and close down the connection immediately, discarding any > > >> pending writes" > > >> I wanna ask why immediately instead of sending pening writes > before > > >> close down the connection. > > > > > > And I like to add whether it is normal practice that the > > TLS teardown > > > procedure is application protocol specific. RFC 5246 section 7.2.1 > > > discusses closure alerts in TLS 1.2 and I like to understand why > we > > > need additional text for NETCONF over TLS. > > > > > > I think we should correct that. What about adopting the text > > of section > > 4.4 of syslog-tls > > (http://www.ietf.org/internet-drafts/draft-ietf-syslog-transpo > > rt-tls-13.txt). > > > > "A TLS client MUST close the associated TLS connection if the > > connection is not expected to deliver any NETCONF messages > > later. It > > MUST send a TLS close_notify alert before closing the > > connection. A > > client MAY choose to not wait for the server's > > close_notify alert and > > simply close the connection, thus generating an incomplete close > on > > the server side. Once the server gets a close_notify from the > > client, it MUST reply with a close_notify unless it becomes aware > > that the connection has already been closed by the client > > (e.g., the > > closure was indicated by TCP). > > > > When no data is received from a connection for a long time > > (where the > > application decides what "long" means), a server MAY close the > > connection. The server MUST attempt to initiate an exchange of > > close_notify alerts with the client before closing the > connection. > > Servers that are unprepared to receive any more data MAY close > the > > connection after sending the close_notify alert, thus generating > an > > incomplete close on the client side. When the client has > received > > the close_notify alert from the server and still has > > pending data to > > send, it SHOULD send the pending data before sending the > > close_notify > > alert." > > > > Best regards, > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 09:02:13 2008 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 064B23A6B5A; Tue, 30 Sep 2008 09:02:13 -0700 (PDT) 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 C855C3A6AD3 for ; Tue, 30 Sep 2008 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 D0pjbhc-7LbU for ; Tue, 30 Sep 2008 09:02:11 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 125F128C137 for ; Tue, 30 Sep 2008 09:02:08 -0700 (PDT) X-Trace: 141971093/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.250 X-SBRS: None X-RemoteIP: 213.116.60.250 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACfq4UjVdDz6/2dsb2JhbACDRTmIVrIZA4Fk X-IronPort-AV: E=Sophos;i="4.33,338,1220223600"; d="scan'208";a="141971093" X-IP-Direction: IN Received: from 1cust250.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.250]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Sep 2008 17:02:19 +0100 Message-ID: <001301c9230c$7ed77940$0601a8c0@allison> From: "tom.petch" To: , =?iso-8859-1?Q?David=C2_B=C2_Harrington=C2?= References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> Date: Tue, 30 Sep 2008 15:33:47 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: =?iso-8859-1?B?wg==?= Subject: Re: [Netconf] =?iso-8859-1?q?=C2=A0=C2=A0WGLC=C2=A0for=C2=A0draft-iet?= =?iso-8859-1?q?f-netconf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: To: "David=C2 B=C2 Harrington=C2" Cc: "=C2" Sent: Monday, September 29, 2008 11:07 PM Subject: [Netconf] RE:=C2 =C2 WGLC=C2 for=C2 draft-ietf-netconf-t ls-04.txt > Here is a tentative to decide what text was needed regarding ciphersuite > support. > > 4. Cipher Suite Requirements > > Implementation of the protocol specified in this document MAY > implement any TLS cipher suite that provides mutual authentication. > > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > In the case of the pre-shared key authentication (described in > Section 3.3), implementations are REQUIRED to support the cipher > suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. > > Comments? > Best regards, > Badra > I think that you need more than this, somewhere in the document, giving the applicability of the two very different suites, when is one appropriate, wh= en the other. As it stands, I get the feeling that I am being told that you r= eally should be using PSK but that someone, perhaps that nasty old security directorate, has insisted we conform to BCP0061 and so have had to include = the other as well:-) But as to what that text might look like, I am less clear. Tom Petch _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 09:02:13 2008 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 064B23A6B5A; Tue, 30 Sep 2008 09:02:13 -0700 (PDT) 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 C855C3A6AD3 for ; Tue, 30 Sep 2008 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 D0pjbhc-7LbU for ; Tue, 30 Sep 2008 09:02:11 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 125F128C137 for ; Tue, 30 Sep 2008 09:02:08 -0700 (PDT) X-Trace: 141971093/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.250 X-SBRS: None X-RemoteIP: 213.116.60.250 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFACfq4UjVdDz6/2dsb2JhbACDRTmIVrIZA4Fk X-IronPort-AV: E=Sophos;i="4.33,338,1220223600"; d="scan'208";a="141971093" X-IP-Direction: IN Received: from 1cust250.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.250]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Sep 2008 17:02:19 +0100 Message-ID: <001301c9230c$7ed77940$0601a8c0@allison> From: "tom.petch" To: , =?iso-8859-1?Q?David=C2_B=C2_Harrington=C2?= References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> Date: Tue, 30 Sep 2008 15:33:47 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: =?iso-8859-1?B?wg==?= Subject: Re: [Netconf] =?iso-8859-1?q?=C2=A0=C2=A0WGLC=C2=A0for=C2=A0draft-iet?= =?iso-8859-1?q?f-netconf-t__ls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org ----- Original Message ----- From: To: "David=C2 B=C2 Harrington=C2" Cc: "=C2" Sent: Monday, September 29, 2008 11:07 PM Subject: [Netconf] RE:=C2 =C2 WGLC=C2 for=C2 draft-ietf-netconf-t ls-04.txt > Here is a tentative to decide what text was needed regarding ciphersuite > support. > > 4. Cipher Suite Requirements > > Implementation of the protocol specified in this document MAY > implement any TLS cipher suite that provides mutual authentication. > > Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to > support the mandatory to implement cipher suite, which is > TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to > future versions of TLS, in which case the mandatory to implement > cipher suite for the implemented version MUST be supported. > > In the case of the pre-shared key authentication (described in > Section 3.3), implementations are REQUIRED to support the cipher > suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. > > Comments? > Best regards, > Badra > I think that you need more than this, somewhere in the document, giving the applicability of the two very different suites, when is one appropriate, wh= en the other. As it stands, I get the feeling that I am being told that you r= eally should be using PSK but that someone, perhaps that nasty old security directorate, has insisted we conform to BCP0061 and so have had to include = the other as well:-) But as to what that text might look like, I am less clear. Tom Petch _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 09:23:43 2008 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 6BFFC3A6BD8; Tue, 30 Sep 2008 09:23:43 -0700 (PDT) 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 B06D93A6BD8 for ; Tue, 30 Sep 2008 09:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GyIpwXtd4me for ; Tue, 30 Sep 2008 09:23:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3E63A6BD0 for ; Tue, 30 Sep 2008 09:23:40 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UHNvVI503892; Tue, 30 Sep 2008 18:23:57 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 18:22:49 +0200 (CEST) Message-ID: <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> In-Reply-To: <001301c9230c$7ed77940$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> Date: Tue, 30 Sep 2008 18:22:49 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 18:23:57 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> 4. Cipher Suite Requirements >> >> Implementation of the protocol specified in this document MAY >> implement any TLS cipher suite that provides mutual authentication. >> >> Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to >> support the mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to >> future versions of TLS, in which case the mandatory to implement >> cipher suite for the implemented version MUST be supported. >> >> In the case of the pre-shared key authentication (described in >> Section 3.3), implementations are REQUIRED to support the cipher >> suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. >> >> Comments? >> Best regards, >> Badra >> > > I think that you need more than this, somewhere in the document, giving > the > applicability of the two very different suites, when is one appropriate, > when > the other. As it stands, I get the feeling that I am being told that you > really > should be using PSK but that someone, perhaps that nasty old security > directorate, has insisted we conform to BCP0061 and so have had to include > the > other as well:-) I think the "applicability" or the benefits of using pre-shared key based authentication have been explained in the Introduction of [RFC4279]. To recall of them, would be sufficient to insert the following text at the end of the first paragraph of Section 3? (The use of PSK is a MAY, not a SHOULD) "The benefits of pre-shared symmetric-key vs. public-/private-key pair based authentication for the key exchange in TLS have been explained in the Introduction of [RFC4279]". Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 09:23:43 2008 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 6BFFC3A6BD8; Tue, 30 Sep 2008 09:23:43 -0700 (PDT) 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 B06D93A6BD8 for ; Tue, 30 Sep 2008 09:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.46 X-Spam-Level: X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7GyIpwXtd4me for ; Tue, 30 Sep 2008 09:23:41 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3E63A6BD0 for ; Tue, 30 Sep 2008 09:23:40 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UHNvVI503892; Tue, 30 Sep 2008 18:23:57 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 18:22:49 +0200 (CEST) Message-ID: <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> In-Reply-To: <001301c9230c$7ed77940$0601a8c0@allison> References: <50947.88.164.98.77.1222460713.squirrel@www.isima.fr><00bb01c92265$a9c7ba90$0600a8c0@china.huawei.com> <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> Date: Tue, 30 Sep 2008 18:22:49 +0200 (CEST) From: badra@isima.fr To: "=?utf-8?Q?tom.petch=C2?=" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 18:23:57 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: Re: [Netconf] =?utf-8?q?WGLC=C2=A0for=C2=A0draft-ietf-netconf-tls-04?= =?utf-8?q?=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> 4. Cipher Suite Requirements >> >> Implementation of the protocol specified in this document MAY >> implement any TLS cipher suite that provides mutual authentication. >> >> Implementations MUST support TLS 1.2 [RFC5246] and are REQUIRED to >> support the mandatory to implement cipher suite, which is >> TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to >> future versions of TLS, in which case the mandatory to implement >> cipher suite for the implemented version MUST be supported. >> >> In the case of the pre-shared key authentication (described in >> Section 3.3), implementations are REQUIRED to support the cipher >> suite TLS_DHE_PSK_WITH_AES_128_CBC_SHA RFC4279]. >> >> Comments? >> Best regards, >> Badra >> > > I think that you need more than this, somewhere in the document, giving > the > applicability of the two very different suites, when is one appropriate, > when > the other. As it stands, I get the feeling that I am being told that you > really > should be using PSK but that someone, perhaps that nasty old security > directorate, has insisted we conform to BCP0061 and so have had to include > the > other as well:-) I think the "applicability" or the benefits of using pre-shared key based authentication have been explained in the Introduction of [RFC4279]. To recall of them, would be sufficient to insert the following text at the end of the first paragraph of Section 3? (The use of PSK is a MAY, not a SHOULD) "The benefits of pre-shared symmetric-key vs. public-/private-key pair based authentication for the key exchange in TLS have been explained in the Introduction of [RFC4279]". Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 10:34:21 2008 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 77D6D3A6BBE; Tue, 30 Sep 2008 10:34:21 -0700 (PDT) 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 ACCE73A6BBE for ; Tue, 30 Sep 2008 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qz4wJhAF+Zvt for ; Tue, 30 Sep 2008 10:34:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B51353A6AD3 for ; Tue, 30 Sep 2008 10:34:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B60FC004F; Tue, 30 Sep 2008 19:33:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CYOfj8FOz3-v; Tue, 30 Sep 2008 19:33:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA692C0023; Tue, 30 Sep 2008 19:33:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 217DB7D6C77; Tue, 30 Sep 2008 19:33:50 +0200 (CEST) Date: Tue, 30 Sep 2008 19:33:50 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080930173350.GA25831@elstar.local> Mail-Followup-To: badra@isima.fr, "tom.petch?" , ? References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] WGLC??for??draft-ietf-netconf-tls-04.txt 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, Sep 30, 2008 at 06:22:49PM +0200, badra@isima.fr wrote: > I think the "applicability" or the benefits of using pre-shared key based > authentication have been explained in the Introduction of [RFC4279]. To > recall of them, would be sufficient to insert the following text at the > end of the first paragraph of Section 3? (The use of PSK is a MAY, not a > SHOULD) > > "The benefits of pre-shared symmetric-key vs. public-/private-key pair > based authentication for the key exchange in TLS have been explained in > the Introduction of [RFC4279]". If you add an explicit pointer to the benefits of PSKs by pointing to the Introduction of RFC 4279, then I like to request that you also add an explicit pointer to the applicability statement contained in section 1.1 of RFC 4279. The text starts as follows: The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. I assume we have agreement that PSKs following RFC 4279 are on optional to implement feature and my preference would be to trust implementors that they go and read RFC 4279 and then decide wether PSKs are in their interest or not without highlighting any benefits of drawbacks in the NETCONF transport mapping itself. /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 Sep 30 10:34:21 2008 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 77D6D3A6BBE; Tue, 30 Sep 2008 10:34:21 -0700 (PDT) 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 ACCE73A6BBE for ; Tue, 30 Sep 2008 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 qz4wJhAF+Zvt for ; Tue, 30 Sep 2008 10:34:20 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B51353A6AD3 for ; Tue, 30 Sep 2008 10:34:12 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B60FC004F; Tue, 30 Sep 2008 19:33:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id CYOfj8FOz3-v; Tue, 30 Sep 2008 19:33:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA692C0023; Tue, 30 Sep 2008 19:33:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 217DB7D6C77; Tue, 30 Sep 2008 19:33:50 +0200 (CEST) Date: Tue, 30 Sep 2008 19:33:50 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080930173350.GA25831@elstar.local> Mail-Followup-To: badra@isima.fr, "tom.petch?" , ? References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] WGLC??for??draft-ietf-netconf-tls-04.txt 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, Sep 30, 2008 at 06:22:49PM +0200, badra@isima.fr wrote: > I think the "applicability" or the benefits of using pre-shared key based > authentication have been explained in the Introduction of [RFC4279]. To > recall of them, would be sufficient to insert the following text at the > end of the first paragraph of Section 3? (The use of PSK is a MAY, not a > SHOULD) > > "The benefits of pre-shared symmetric-key vs. public-/private-key pair > based authentication for the key exchange in TLS have been explained in > the Introduction of [RFC4279]". If you add an explicit pointer to the benefits of PSKs by pointing to the Introduction of RFC 4279, then I like to request that you also add an explicit pointer to the applicability statement contained in section 1.1 of RFC 4279. The text starts as follows: The ciphersuites defined in this document are intended for a rather limited set of applications, usually involving only a very small number of clients and servers. Even in such environments, other alternatives may be more appropriate. I assume we have agreement that PSKs following RFC 4279 are on optional to implement feature and my preference would be to trust implementors that they go and read RFC 4279 and then decide wether PSKs are in their interest or not without highlighting any benefits of drawbacks in the NETCONF transport mapping itself. /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 Sep 30 10:41:57 2008 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 030573A6A32; Tue, 30 Sep 2008 10:41:57 -0700 (PDT) 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 341343A6A32 for ; Tue, 30 Sep 2008 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wClWRwW0B88 for ; Tue, 30 Sep 2008 10:41:54 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7893A6A2E for ; Tue, 30 Sep 2008 10:41:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UIgH7A504018; Tue, 30 Sep 2008 19:42:17 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 19:41:09 +0200 (CEST) Message-ID: <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> In-Reply-To: <20080930173350.GA25831@elstar.local> References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> Date: Tue, 30 Sep 2008 19:41:09 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 19:42:17 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?q?_Re=3A=C2=A0=C2=A0WGLC_for_draft-ietf-netconf?= =?utf-8?q?-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> I think the "applicability" or the benefits of using pre-shared key >> based >> authentication have been explained in the Introduction of [RFC4279]. To >> recall of them, would be sufficient to insert the following text at the >> end of the first paragraph of Section 3? (The use of PSK is a MAY, not a >> SHOULD) >> >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair >> based authentication for the key exchange in TLS have been explained in >> the Introduction of [RFC4279]". > > If you add an explicit pointer to the benefits of PSKs by pointing to > the Introduction of RFC 4279, then I like to request that you also add > an explicit pointer to the applicability statement contained in > section 1.1 of RFC 4279. The text starts as follows: > > The ciphersuites defined in this document are intended for a rather > limited set of applications, usually involving only a very small > number of clients and servers. Even in such environments, other > alternatives may be more appropriate. No problem. What about: "The application statement and the benefits of using the pre-shared key based authentication have been explained in the Introduction of [RFC4279]". Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 10:41:57 2008 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 030573A6A32; Tue, 30 Sep 2008 10:41:57 -0700 (PDT) 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 341343A6A32 for ; Tue, 30 Sep 2008 10:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wClWRwW0B88 for ; Tue, 30 Sep 2008 10:41:54 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7893A6A2E for ; Tue, 30 Sep 2008 10:41:54 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UIgH7A504018; Tue, 30 Sep 2008 19:42:17 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 19:41:09 +0200 (CEST) Message-ID: <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> In-Reply-To: <20080930173350.GA25831@elstar.local> References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> Date: Tue, 30 Sep 2008 19:41:09 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 19:42:17 +0100 (WEST) Cc: =?utf-8?Q?=C2?= Subject: [Netconf] =?utf-8?q?_Re=3A=C2=A0=C2=A0WGLC_for_draft-ietf-netconf?= =?utf-8?q?-tls-04=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> I think the "applicability" or the benefits of using pre-shared key >> based >> authentication have been explained in the Introduction of [RFC4279]. To >> recall of them, would be sufficient to insert the following text at the >> end of the first paragraph of Section 3? (The use of PSK is a MAY, not a >> SHOULD) >> >> "The benefits of pre-shared symmetric-key vs. public-/private-key pair >> based authentication for the key exchange in TLS have been explained in >> the Introduction of [RFC4279]". > > If you add an explicit pointer to the benefits of PSKs by pointing to > the Introduction of RFC 4279, then I like to request that you also add > an explicit pointer to the applicability statement contained in > section 1.1 of RFC 4279. The text starts as follows: > > The ciphersuites defined in this document are intended for a rather > limited set of applications, usually involving only a very small > number of clients and servers. Even in such environments, other > alternatives may be more appropriate. No problem. What about: "The application statement and the benefits of using the pre-shared key based authentication have been explained in the Introduction of [RFC4279]". Best regards, Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 10:54:27 2008 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 3EA4F28C1B6; Tue, 30 Sep 2008 10:54:27 -0700 (PDT) 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 C717028C1B6 for ; Tue, 30 Sep 2008 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 f5d9SZx9HuuK for ; Tue, 30 Sep 2008 10:54:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CFDCE28C186 for ; Tue, 30 Sep 2008 10:54:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94817C0056; Tue, 30 Sep 2008 19:54:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MTQtftATAVNa; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40CB0C0023; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DC117D6DA1; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Date: Tue, 30 Sep 2008 19:54:23 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080930175423.GC25831@elstar.local> Mail-Followup-To: badra@isima.fr, cfinss@dial.pipex.com, ? References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 30, 2008 at 07:41:09PM +0200, badra@isima.fr wrote: > No problem. What about: > "The application statement and the benefits of using the pre-shared > key based authentication have been explained in the Introduction of > [RFC4279]". Or: "For details concerning pre-shared key based authentication see [RFC4279]". Less is more. /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 Sep 30 10:54:27 2008 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 3EA4F28C1B6; Tue, 30 Sep 2008 10:54:27 -0700 (PDT) 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 C717028C1B6 for ; Tue, 30 Sep 2008 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 f5d9SZx9HuuK for ; Tue, 30 Sep 2008 10:54:22 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id CFDCE28C186 for ; Tue, 30 Sep 2008 10:54:21 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94817C0056; Tue, 30 Sep 2008 19:54:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MTQtftATAVNa; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40CB0C0023; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8DC117D6DA1; Tue, 30 Sep 2008 19:54:23 +0200 (CEST) Date: Tue, 30 Sep 2008 19:54:23 +0200 From: Juergen Schoenwaelder To: badra@isima.fr Message-ID: <20080930175423.GC25831@elstar.local> Mail-Followup-To: badra@isima.fr, cfinss@dial.pipex.com, ? References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ? Subject: Re: [Netconf] ????WGLC for draft-ietf-netconf-tls-04.txt 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, Sep 30, 2008 at 07:41:09PM +0200, badra@isima.fr wrote: > No problem. What about: > "The application statement and the benefits of using the pre-shared > key based authentication have been explained in the Introduction of > [RFC4279]". Or: "For details concerning pre-shared key based authentication see [RFC4279]". Less is more. /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 Sep 30 11:15:19 2008 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 3EF893A6BCD; Tue, 30 Sep 2008 11:15:19 -0700 (PDT) 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 841A53A6BCD for ; Tue, 30 Sep 2008 11:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IcrGUXs5+7C for ; Tue, 30 Sep 2008 11:15:16 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 932783A6B5A for ; Tue, 30 Sep 2008 11:15:16 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UJFAwZ970754; Tue, 30 Sep 2008 20:15:10 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 20:14:02 +0200 (CEST) Message-ID: <55510.88.164.98.77.1222798442.squirrel@www.isima.fr> In-Reply-To: <20080930175423.GC25831@elstar.local> References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> <20080930175423.GC25831@elstar.local> Date: Tue, 30 Sep 2008 20:14:02 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 20:15:10 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgIFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRj?= =?utf-8?q?onf-tls-04__=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> No problem. What about: >> "The application statement and the benefits of using the pre-shared >> key based authentication have been explained in the Introduction of >> [RFC4279]". > > Or: > > "For details concerning pre-shared key based authentication see > [RFC4279]". > > Less is more. > > /js OK. I will insert this sentence at the end of 1st paragraph, Section 3 Thanks. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From netconf-bounces@ietf.org Tue Sep 30 11:15:19 2008 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 3EF893A6BCD; Tue, 30 Sep 2008 11:15:19 -0700 (PDT) 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 841A53A6BCD for ; Tue, 30 Sep 2008 11:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-0.996, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IcrGUXs5+7C for ; Tue, 30 Sep 2008 11:15:16 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 932783A6B5A for ; Tue, 30 Sep 2008 11:15:16 -0700 (PDT) Received: from www.isima.fr (www-data@www.isima.fr [193.55.95.79]) by sp.isima.fr (8.13.8/8.13.8) with SMTP id m8UJFAwZ970754; Tue, 30 Sep 2008 20:15:10 +0100 Received: from 88.164.98.77 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Tue, 30 Sep 2008 20:14:02 +0200 (CEST) Message-ID: <55510.88.164.98.77.1222798442.squirrel@www.isima.fr> In-Reply-To: <20080930175423.GC25831@elstar.local> References: <61043.88.164.98.77.1222722436.squirrel@www.isima.fr> <001301c9230c$7ed77940$0601a8c0@allison> <54288.88.164.98.77.1222791769.squirrel@www.isima.fr> <20080930173350.GA25831@elstar.local> <55259.88.164.98.77.1222796469.squirrel@www.isima.fr> <20080930175423.GC25831@elstar.local> Date: Tue, 30 Sep 2008 20:14:02 +0200 (CEST) From: badra@isima.fr To: j.schoenwaelder@jacobs-university.de User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 X-Priority: 3 Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 30 Sep 2008 20:15:10 +0100 (WEST) Cc: netconf@ietf.org Subject: [Netconf] =?utf-8?b?IFJlOsKgIFdHTEPCoGZvcsKgZHJhZnQtaWV0Zi1uZXRj?= =?utf-8?q?onf-tls-04__=2Etxt?= X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: netconf-bounces@ietf.org Errors-To: netconf-bounces@ietf.org >> No problem. What about: >> "The application statement and the benefits of using the pre-shared >> key based authentication have been explained in the Introduction of >> [RFC4279]". > > Or: > > "For details concerning pre-shared key based authentication see > [RFC4279]". > > Less is more. > > /js OK. I will insert this sentence at the end of 1st paragraph, Section 3 Thanks. Best regards Badra _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf