NETCONF Configuration Protocol
RFC 4741

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    netconf mailing list <netconf@ietf.org>, 
    netconf chair <netconf-chairs@tools.ietf.org>
Subject: Protocol Action: 'NETCONF Configuration Protocol' to 
         Proposed Standard 

The IESG has approved the following documents:

- 'Using the NETCONF Configuration Protocol over Secure Shell (SSH) '
   <draft-ietf-netconf-ssh-07.txt> as a Proposed Standard
- 'NETCONF Configuration Protocol '
   <draft-ietf-netconf-prot-13.txt> as a Proposed Standard

These documents are products of the Network Configuration Working Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-13.txt

Technical Summary
 
  NETCONF Configuration Protocol

  The NETCONF configuration protocol defined in this document provides
  mechanisms to install, manipulate, and delete the configuration of
  network devices.  It uses an Extensible Markup Language (XML) based
  data encoding for the configuration data as well as the protocol
  messages.  The NETCONF protocol operations are realized on top of a
  simple Remote Procedure Call (RPC) layer.

  Using the NETCONF Configuration Protocol over Secure Shell (SSH)

  This document describes a method for invoking and running the NETCONF
  configuration protocol within a Secure Shell (SSH) session as an SSH
  subsystem.

  Note:  The WG could not decide on a single transport mapping for
  NETCONF, because different types of programmers want to use the
  protocol.  Therefore, NETCONF defines three transport mappings: 
  SSH, BEEP, and SOAP, where SSH is the mandatory-to-implement
  protocol. 

Working Group Summary
 
  The NETCONF Working Group has consensus to publish these documents
  as a Proposed Standard.  

Protocol Quality

  It is likely that there are several implementations of these
  documents in various stages of completion at this time.
  Several major equipment vendors have indicated interest in
  supporting this document, and some non-commercial
  implementations are also expected.
  An interoperability event (just prior to Paris IETF) was held
  in which 4 implementations participated and feedback was
  considered in revisions of these documents.

  Bert Wijnen reviewed these documents for the IESG.


Note to RFC Editor

I appologize for the pretty extensive changes, but this was the
only way to get this document approved before I am stepping down
as AD (thanks, Bert)

Please make the following changes:

------ 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"/> 

IANA Note

-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, March 23, 2006 14:39
To: Bert Wijnen; iana@iana.org
Subject: Port request for draft-ietf-netconf-ssh-06.txt


Hi,

Please assign a port number < 1024 for the NETCONF
protocol over the Secure Shell protocol, as specified
in section 7 of this document.

thanks,
Andy