Subject: RFC Editor edit list for approved netconf drafts

From: Andy Bierman <[email-masked]>
Date: Thu, 08 Jun 2006 14:22:07 -0700

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 11 Jun 2006 20:35:45 +0200 (CEST)

> It is available from the ID-Tracker as well.

What about the schema issues that were discussed in
http://ops.ietf.org/lists/netconf/netconf.2006/msg00512.html, and then
in some more recent thread?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Jun 2006 09:27:32 -0700

> in some more recent thread?

What is the proposed text for the RFC Edit?

Are there any issues with <filter> now, or just <config> ?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Jun 2006 23:20:12 +0200 (CEST)

> What is the proposed text for the RFC Edit?

I must say that I'm not sure that this is the right change, but I
think that the easiest way to fix this is to change the
dataInlineType, configInlineType and filterInlineType to be
xs:extension of xs:anyType instead of xs:restriction, i.e. instead of

     <xs:complexType name="configInlineType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType"/>
       </xs:complexContent>
     </xs:complexType>

which, as far as I understand it, restricts configInlineType to be
'empty', we should have

     <xs:complexType name="configInlineType">
       <xs:complexContent>
         <xs:extension base="xs:anyType"/>
       </xs:complexContent>
     </xs:complexType>

(and same for dataInlineType and filterInlineType).

> Are there any issues with <filter> now, or just <config> ?

Yes, see above.

This change is verified with the validator in libxml2.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2006 09:15:23 -0700

> xs:extension of xs:anyType instead of xs:restriction, i.e. instead of

I don't know the correct XSD text either.
Since this entire exercise is for the benefit
of XSD tools, we need somebody who uses those tools
to find the text that works.

I really dislike the way some of the
XML constructs in NETCONF were done.  Using element
names instead of strings for config names, using
extra nesting layers (e.g. <url>) in some choices,
The <filter> element, etc.

The XSD needs to reflect these characteristics for <filter> (but cannot):

  - The element must be empty if the 'type' attribute
    is equal to "xpath".

  - The 'select' attribute must be present if the type
    attribute is equal to "xpath", and must not be present
    if it is equal to "subtree".

  - If the 'type' attribute is equal to "subtree", then
    the element content may be non-empty.

  - Mixed mode content is not allowed in the <filter> element,
    so if it is non-empty it must contain only XML child nodes
    and not text (from any namespace).

  - Since XML treats whitespace as content, the following filters
    are different:

    1) legal, empty:    <filter type="subtree"></filter>
    2) illegal, text:   <filter type="subtree"> </filter>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 13 Jun 2006 21:09:31 +0200 (CEST)

> to find the text that works.

As I wrote, I did test it with libxml2.

Furthermore, if this construct is used (i.e. xs:extension) the
original filter definition validates just fine even for xpath,
i.e. there would be no need to add the 'select' attribute.  (Not that I
have any problems with the 'select' attribute).

>     2) illegal, text:   <filter type="subtree"> </filter>

I don't follow that logic.  Are you suggesting that this is special
only for the empty filter, but not when you have some subelements?
Thus, would

  <filter type="subtree"><top xmlns="http://foo.com"/></filter>

be identical to 

  <filter type="subtree">
    <top xmlns="http://foo.com"/>
  </filter>

or not?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2006 14:32:33 -0700

>     <top xmlns="http://foo.com"/>

No it is not special.
It is just whitespace between a start and end tag,
not between two start tags.  Your example is correct.
Whitespace from start to start tag or end to start tag is ignored.

<filter> </filter>

<filter>
</filter>

Both of these elements contain whitespace; they are not empty.
This test applies only to simpleTypes.  I don't actually
reject this. I check for it, and treat the construct as
an empty tag.  You can force the parser to take a whitespace
string using double quotes:  <foo>" "</foo>.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 13 Jun 2006 15:00:26 -0700

>..

Sorry for the confusion.
The <filter> element does not allow mixed content,
so it much contain a complexType or be empty.
The filter examples below would be true if
mixed content was allowed.  Since it is not,
the whitespace content will not be interpreted as a simpleType.

Andy