RFC Editor edit list for approved netconf drafts
Andy Bierman <ietf@andybierman.com> Thu, 08 June 2006 21:27 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS2j-0000Qz-Ja for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 17:27:53 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoS2j-0005Xm-0w for netconf-archive@lists.ietf.org; Thu, 08 Jun 2006 17:27:53 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-netconf@ops.ietf.org>) id 1FoRyH-0008dq-Sl for netconf-data@psg.com; Thu, 08 Jun 2006 21:23:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1
Received: from [205.178.146.51] (helo=omr1.networksolutionsemail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <ietf@andybierman.com>) id 1FoRyE-0008cy-LE for netconf@ops.ietf.org; Thu, 08 Jun 2006 21:23:15 +0000
Received: from mail.networksolutionsemail.com ([10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k58LNCZS001224 for <netconf@ops.ietf.org>; Thu, 8 Jun 2006 17:23:13 -0400
Received: (qmail 15607 invoked by uid 78); 8 Jun 2006 21:22:13 -0000
Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@24.24.133.237) by 10.49.36.64 with SMTP; 8 Jun 2006 21:22:13 -0000
Message-ID: <448894FF.1060006@andybierman.com>
Date: Thu, 08 Jun 2006 14:22:07 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: "Netconf (E-mail)" <netconf@ops.ietf.org>
Subject: RFC Editor edit list for approved netconf drafts
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-netconf@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Hi, Somebody asked for this edit list earlier. It is available from the ID-Tracker as well. Is this list complete? =========================== We are currently working on an edit for the subtree filter. (prot-12, bottom of page 22, sec. 6.2.5) Since everybody who commented agreed that the intent of the WG for an empty subtree filter is not reflected in the text, 1 or 2 sentences reflecting the WG intent will be submitted as another 'rfc edit' request. The text will indicate that a containment node at a particular level, that has any nested content-select or attribute-select nodes, will be removed from the results if all of these nested boolean expressions evaluate to 'false' results. This will also allow us to write text in the Notifications draft that says "a subtree filter set that results in an empty <data> element indicates that the notification MUST NOT be generated by the agent." ============================ thanks, Andy ------ for the draft-ietf-netconf-ssh-06.txt document ---------- - In section 3, page 3 (last line) and 4: OLD: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, if a subsystem cannot be used, it should be possible for a client to skip over any system messages that are sent at shell start-up by searching for a NETCONF <hello> element. Note that this may not avoid problems if system messages are recieved later in the session. NEW: SSHv1. Running NETCONF as an SSH subsystem avoids the need for the script to recognize shell prompts or skip over extraneous information, such as a system message that is sent at shell start-up. However, even when a subsystem is used, some extraneous messages may be printed by the user's start-up scripts. Implementations MUST skip over these messages by searching for an 'xml' start directive, which MUST be followed by a <hello> element in the 'NETCONF' namespace. - In section 5, page 6, line 4 in 1st para: OLD: ...and terminate the SSH session. NEW: ...and close the SSH session channel. ----- in the draft-ietf-netconf-prot-12.txt document ---------- Page 16: OLD: The following <rpc-reply> illustrates the case of returning multiple <rpc-error> elements. NEW: The following <rpc-reply> illustrates the case of returning multiple <rpc-error> elements. Note that the data models used in the examples in this section use the <name> element to distinguish between multiple instances of the <interface> element. On page 34: OLD: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the filter element contains an XPath expression. NEW: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression. Page 39, bottom: OLD: Example: Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: NEW: Example: The <edit-config> examples in this section utilize a simple data model, in which multiple instances of the 'interface' element may be present, and an instance is distinguished by the 'name' element within each 'interface' element. Set the MTU to 1500 on an interface named "Ethernet0/0" in the running configuration: On page 46: OLD: A lock MUST not be granted if any of the following conditions are true: * a lock is already held by another NETCONF session or another ^^^^^^^ entity NEW: A lock MUST not be granted if any of the following conditions are true: * a lock is already held by any NETCONF session or another entity On page 50: OLD: If the NETCONF peer supports the :xpath capability (Section 8.9), the value 'xpath' may be used to indicate that the filter element contains an XPath expression. NEW: If the NETCONF peer supports the :xpath capability (Section 8.9), the value "xpath" may be used to indicate that the select attribute on the filter element contains an XPath expression. On page 67: OLD: The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", the contents of the filter element will be treated as an xpath expression and used to filter the returned data. NEW: The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the type attribute of the filter element. When the type attribute is set to "xpath", a select attribute MUST be present on the filter element. The select attribute will be treated as an XPath expression and used to filter the returned data. The filter element itself MUST be empty in this case. On page 67: OLD: <filter type="xpath"> <!-- get the user named fred --> top/users/user[name="fred"] </filter> NEW: <!-- get the user named fred --> <filter type="xpath" select="top/users/user[name='fred']"/> On page 81: OLD: <xs:attribute name="type" type="FilterType" default="subtree"/> NEW: <xs:attribute name="type" type="FilterType" default="subtree"/> <!-- if type="xpath", the xpath expression appears in the select element --> <xs:attribute name="select"/> -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>
- RFC Editor edit list for approved netconf drafts Andy Bierman
- Re: RFC Editor edit list for approved netconf dra… Martin Bjorklund
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman
- Re: RFC Editor edit list for approved netconf dra… Martin Bjorklund
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman
- Re: RFC Editor edit list for approved netconf dra… Martin Bjorklund
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman
- RE: RFC Editor edit list for approved netconf dra… Romascanu, Dan (Dan)
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman
- Re: RFC Editor edit list for approved netconf dra… Andy Bierman