Netconf Working Group                                     Weijing Chen 
Internet Draft                                             Keith Allen 
Expiration Date: February 2004                                SBC Labs 
                                                                       
                                                           August 2003 
 
 
 
                    XML Network Management Interface 
                   draft-weijing-netconf-interface-01 
    
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of [RFC2026]. 
    
   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. 
    
Abstract 
    
   This document specifies an XML network management interface between 
   a network managing system and a network managed system.  The XML 
   network management interface is intended for use in diverse network 
   environments where transport, data and operating model requirements 
   vary greatly.  It is unlikely that a single transport, data and 
   operating model specification will meet the needs of all anticipated 
   service operators.  Therefore, the XML network management interface 
   is partitioned into layered components. 
    
 
Table of Contents 
 
   1.   Introduction.................................................2 
   2.   Protocol Operations..........................................4 
   2.1.   Operation Descriptions......................................4 
   2.1.1.  Get Operation............................................4 
   2.1.2.  Perform Operation........................................7 
 
 
Chen and Allen          Expires February 2004                [Page 1] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   2.1.3.  Abort Operation.........................................11 
   2.1.4.  Notification............................................12 
   2.2.   Protocol Operations XML Schema.............................13 
   3.   Capabilities................................................20 
   3.1.   Capabilities Exchange......................................20 
   3.2.   Capabilities Schema........................................21 
   4.   An Example Operating Model..................................23 
   4.1.   Operating Model Descriptions...............................23 
   4.2.   Operating Model Schema.....................................25 
   5.   Security Consideration......................................30 
   6.   References..................................................30 
   7.   Authors' Addresses..........................................30 
    
 
1.   Introduction 
 
   This document specifies an XML network management interface between 
   a network managing system and a network managed system.  The XML 
   network management interface is intended for use in diverse network 
   environments where transport, data and operating model requirements 
   vary greatly.  It is unlikely that a single transport, data and 
   operating model specification will meet the needs of all anticipated 
   service operators.  Therefore, the XML network management interface 
   is partitioned into the following layered components. 
    
    
   +---------------------------------------------+ 
   |  Data and Operating Model XML Schema:       | 
   |    Standard                                 | 
   |    CLI                +---------------------+ 
   |    Proprietary        |  Capabilities       | 
   |                       |  XML Schema         | 
   +-----------------------+---------------------+ 
   |  Protocol Operations: Operation XML Schema  | 
   |    <get-request/get-response>       | 
   |    <perform-request/perform-response>       | 
   |    <abort-request/abort-response>           | 
   |    <notif/notif-confirm>                    | 
   +---------------------------------------------+ 
   |  Protocol Transport:                        | 
   |    BEEP, SOAP/HTTP, SSH                     | 
   +---------------------------------------------+ 
 
   Starting at the bottom of the figure and working up, the binding of 
   the protocol operations to the protocol transport is out of scope of 
   this document.  Separate documents will describe different protocol 
   bindings. 
    
 
 
Chen and Allen           Expire February 2004                 [Page 2] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   This document describes the protocol operations, the second layer up 
   in the figure above.  The protocol operations are specified in XML 
   schema, which describe each operation message construct. 
    
   Some protocol capabilities are optional or not specified by this 
   document.  The protocol capabilities supported by a managed system 
   are described in a capabilities XML dataset.  This allows a managing 
   system to discover the actual functionality implemented in the 
   managed system.  The schema for this XML dataset is specified in 
   this document. 
    
   Examples of data and operating models are described in this document 
   using XML schema, too.  This document, though, does not attempt to 
   define a standard data or operating model. 
    
   The dividing of interface functionality allows the formal 
   verification of interface messages against interface specifications 
   using available general purpose XML toolkits as in the following: 
    
    
              Protocol     Data/Operating 
              Operation    Model                    XML 
              Schema       Schema                   Instance 
                 \           /                      Dataset 
                  \         /                        /    \ 
                   \       /                        /      \ 
                +---+-----+--+               +-----+--+     \ 
   Interface    | XML Schema |    w/ XPath   | XPath  |      \ 
   ------------>| Validator  |-----+-------->| Parser |--->Application 
   Message      +-----+------+     |         +-------++ 
                      |            |                 | 
                      |            |     w/o XPath   | 
                      |            +-----------------+---->Application 
                      |                              |          | 
       Error <--------+------------------------------+----------+ 
    
    
   The interface XML message can be validated against the protocol 
   operation XML schema and specific data and operating model XML 
   schema using a general purpose XML schema validator.  If the system 
   supports XPath and the interface XML message contains XPath 
   elements, the validated XML message can be parsed and validated 
   against live XML instance datasets in the system using an XPath 
   parser.  Thereafter the processed XML message is passed on to the 
   management application for further processing. 
    
    
 
 
Chen and Allen           Expire February 2004                 [Page 3] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
2.   Protocol Operations 
   The protocol operations consist of four basic operations:  get, 
   perform, abort, and notification.  Each operation has a request and 
   response message correlated with a unique message id. 
    
2.1. Operation Descriptions 
    
2.1.1.    Get Operation 
   <get-request messageId="message id" 
                category="all/config/state" 
                subordinate="all/direct"/> 
     ... any 
   </get-request> 
    
   <get-response messageId="message id"> 
     <error> 
       <protocol-error code=""> 
         ... any 
       </protocol-error> 
       <application-error code=""> 
         ... any 
       </application-error> 
     </error> 
     ... any 
   </get-response> 
    
   A "get-request" message is a request from the managing system to the 
   managed system to obtain specific information.  The "messageId" 
   attribute MUST uniquely identify the request message and is used to 
   correlate the request and response messages.  The "category" 
   attribute indicates the type of data that this "get-request" message 
   requests.  "all" means all the data, "config" means configuration 
   data, and "state" means state data.  It is recommended that each 
   element in the data and operating model schema SHOULD have an 
   attribute "category" with a fixed value from the type "Category" to 
   indicate what type of data this element is.  The "subordinate" 
   attribute indicates the scope of subordinate elements which the 
   "get-request" expects in the return.  It has the value of "all" or 
   "direct".  "all" means all levels of the subordinate elements, 
   "direct" means only direct subordinate elements.  The target element 
   of the "get-request" MUST be the longest matched sub-element in the 
   targeted XML configuration datastore. 
    
   A "get-response" message is a response from the managed system to 
   the managing system to return requested information.  The 
   "messageId" attribute MUST be the same message id of the 
   corresponding request message, which is used to correlate the 
   request and response messages. 
    
 
 
Chen and Allen           Expire February 2004                 [Page 4] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   The sub-element of the "get-request" and "get-response" message is 
   defined as <xsd:any/> in the protocol operation XML schema.  The 
   <any> element enables the data and operating model designers to 
   create interface messages containing elements beyond what was 
   specified by the protocol operation XML schema.  It empowers the 
   model designers with the ability to define data and operating models 
   appropriate to the system being managed.  The validation of the 
   whole interface message can be done by a general-purpose XML 
   validator with operation XML schema, data and operating model XML 
   schema. 
    
   The following example retrieves an XML snippet of configuration data 
   for interfaces with "up" "adminStatus" from the startup 
   configuration datastore.  The protocol operation XML schema is 
   defined in the namespace "http://www.ietf.org/netconf/operations".  
   The data and operating model XML schema is defined in the namespace 
   "http://example.com/schema".   
   <get-request messageId="09233523-567b" 
                category="config" 
                subordinate="all" 
                xmlns="http://www.ietf.org/netconf/operations" 
                xmlns:example="http://example.com/schema"> 
     <example:startupConfig> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface> 
             <address/> 
             <adminStatus>"up"</adminStaus> 
           </example:interface> 
         </example:area> 
       </example:ospf> 
     </example:startupConfig> 
   </get-request> 
    
   <get-response messageId="09233523-567b" 
                 xmlns="http://www.ietf.org/netconf/operations" 
                 xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:startupConfig> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface name="Ethernet1/5"> 
             <address>"192.116.67.5"</address> 
             <adminStatus>"up"</adminStatus> 
           </example:interface> 
           <example:interface name="Ethernet2/2"> 
             <address>"135.104.57.3"</address> 
 
 
Chen and Allen           Expire February 2004                 [Page 5] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
             <adminStatus>"up"</adminStatus> 
           </example:interface> 
         </example:area> 
       </example:ospf> 
     </example:startupConfig> 
   </get-response> 
    
   The following example retrieves the entire running configuration, 
   which could be loaded back to the device later to restore the device 
   configuration.  Note that the attribute "category" has a value of 
   "config", which instructs the device not to retrieve any state 
   information elements since they are not configurable. 
   <get-request messageId="09233523-567b" 
                category="config" 
                subordinate="all" 
                xmlns="http://www.ietf.org/netconf/operations" 
                xmlns:example="http://example.com/schema"> 
     <example:runningConfig> 
     </example:runningConfig> 
   </get-request> 
    
   <get-response messageId="09233523-567b" 
                 xmlns="http://www.ietf.org/netconf/operations" 
                 xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:runningConfig> 
       XML configuration data goes here ... 
     </example:runningConfig> 
   </get-response> 
    
   However, the following example only retrieves the top level running 
   configuration, which could be the starting points for later 
   navigation. 
   <get-request messageId="09233523-567b" 
                category="config" 
                subordinate="direct" 
                xmlns="http://www.ietf.org/netconf/operations" 
                xmlns:example="http://example.com/schema"> 
     <example:runningConfig> 
     </example:runningConfig> 
   </get-request> 
    
   <get-response messageId="09233523-567b" 
                 xmlns="http://www.ietf.org/netconf/operations" 
                 xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
 
 
Chen and Allen           Expire February 2004                 [Page 6] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       <application-error code="noError"/> 
     </error> 
     <example:runningConfig> 
       top level XML configuration data goes here ... 
     </example:runningConfig> 
   </get-response> 
    
   The following example retrieves an XML snippet of device performance 
   data that is state information in the running configuration. 
   <get-request messageId="09233523-567b" 
                category="state" 
                subordinate="all" 
                xmlns="http://www.ietf.org/netconf/operations" 
                xmlns:example="http://example.com/schema"> 
     <example:runningConfig> 
       <example:interface name="Ethernet0/1"> 
         <example:statistics/>  
       </example:interface> 
     </example:runningConfig> 
   </get-request> 
    
   <get-response messageId="09233523-567b" 
                 xmlns="http://www.ietf.org/netconf/operations" 
                 xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:runningConfig> 
       <example:interface name="Ethernet0/1"> 
         <example:statistics> 
           <inPackets>9456823</inPackets> 
           <inOctets>1228484566</inOctets> 
           <inErrors>4326</inErrors> 
           <outPackets>4821050</outPackets> 
           <outOctets>634712154</outOctets> 
           <outErrors>2096</outErrors> 
         <example:statistics>  
       </example:interface> 
     </example:runningConfig> 
   </get-response> 
    
    
2.1.2.    Perform Operation 
   <perform-request messageId="message id" 
                    transaction="stop-on-error/ 
                                 continue-on-error/ 
                                 rollback-on-error"/> 
     ... any 
   </perform-request> 
 
 
Chen and Allen           Expire February 2004                 [Page 7] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
    
   <perform-response messageId="message id"> 
     <error> 
       <protocol-error code=""> 
         ... any 
       </protocol-error> 
       <application-error code=""> 
         ... any 
       </application-error> 
     </error> 
     ... any 
   </perform-response> 
    
   A "perform-request" message is a request from the managing system to 
   the managed system for a specific action.  The "messageId" attribute 
   MUST uniquely identify the request message and is used to correlate 
   the request and response messages.  The "transaction" attribute 
   describes the desired message transaction handling as one of the 
   following: stop on error, continue on error, or rollback on error.   
    
   The actual action SHOULD be described by the data and operating 
   model.  The recommendation is that an attribute named "action" in 
   the targeted element SHOULD specify the actual action (this is 
   referred to as "action-as-attribute").  The protocol operation XML 
   schema has defined an "Action" type with these permitted values: 
   nop, create, delete, replace, merge, copy, validate, lock, unlock.  
   Each object element in the data and operating model schema SHOULD 
   have an attribute "action" of the type "Action" to indicate what 
   actions on this object (element) are permitted.  The data and 
   operating model XML schema MAY extend or restrict the permitted 
   value of the "Action" type through the XML attribute type definition 
   mechanism. 
    
   The action-as-attribute approach places operation behavior 
   definitions in the data and operating model, not in the protocol 
   operation layer, resulting in a more object-oriented approach.  The 
   object reference is identified by XML element tree or XPath (if 
   supported) in the message but the operation behaviors that may be 
   performed on that object are determined by the object’s definition 
   (i.e. the data and operating model XML schema). 
    
   A "perform-response" message is a response from the managed system 
   to the managing system to return the results of the "perform-
   request" operation.  The "messageId" attribute MUST be the same 
   message id of the corresponding request message, which is used to 
   correlate the request and response message. 
    
   The action-as-attribute approach must be considered in the response 
   message.  Elements with an attribute named "action" of type "Action" 
   MUST have a value of "nop" in the perform-response message.  The 
 
 
Chen and Allen           Expire February 2004                 [Page 8] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   value "nop" SHOULD be defined in data and operating model schema as 
   the default value for attributes named "action" of type "Action."  
   This will relieve the managed system from including the attribute in 
   its response. 
    
   The sub-element of the "perform-request" and "perform-response" 
   message is defined as <xsd:any/> in the protocol operation XML 
   schema, as with the "get-request" and "get-response". 
    
   The following example modifies the OSPF "hello-interval" of an 
   Ethernet interface in the running configuration.  The protocol 
   operation XML schema is defined in the namespace 
   "http://www.ietf.org/netconf/operations".  The data and operating 
   model XML schema is defined in the namespace 
   "http://example.com/schema".  The attribute "action" is closely 
   associated with the targeted element and specified by the data model 
   instead of the protocol operation model, which makes the interface 
   flexible and extensible. 
    
   The following example only modifies the "hello-interval". 
   <perform-request messageId="09233523-567b" 
                    transaction="continue-on-error" 
                    xmlns="http://www.ietf.org/netconf/operations" 
                    xmlns:example="http://example.com/schema"> 
     <example:runningConfig> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface action="modify" 
                              name="Ethernet1/5"> 
             <hello-interval>10</hello-interval> 
           </example:interface> 
         </example:area> 
       </example:ospf> 
     </example:runningConfig> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
                     xmlns="http://www.ietf.org/netconf/operations" 
                     xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:runningConfig> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface name="Ethernet1/5"> 
             <hello-interval>10</hello-interval> 
           </example:interface> 
         </example:area> 
 
 
Chen and Allen           Expire February 2004                 [Page 9] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       </example:ospf> 
     </example:runningConfig> 
   </perform-response> 
    
   The following example creates the OSPF area 0 with a specified 
   interface and "hello-interval". 
   <perform-request messageId="09233523-567b" 
                    transaction="stop-on-error" 
                    xmlns="http://www.ietf.org/netconf/operations" 
                    xmlns:example="http://example.com/schema"> 
     <example:runningConfig> 
       <example:ospf name="process 1"> 
         <example:area action="create" name="area 0"> 
           <example:interface name="Ethernet1/5"> 
             <hello-interval>10</hello-interval> 
           </example:interface> 
         </example:area> 
        </example:ospf> 
     </example:runningConfig> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
                     xmlns="http://www.ietf.org/netconf/operations" 
                     xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:runningConfig name="active"> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface name="Ethernet1/5"> 
             <hello-interval>10</hello-interval> 
           </example:interface> 
         </example:area> 
       </example:ospf> 
     </example:runningConfig> 
   </perform-response> 
    
   The following example modifies the configuration through non-XML 
   content (i.e. plain text).  Note that the attribute "action" has a 
   value of "cli", which is specific to this data model 
   "http://example.com/cli".  
   <perform-request messageId="09233523-567b" 
                    transaction="stop-on-error" 
                    xmlns="http://www.ietf.org/netconf/operations" 
                    xmlns:example="http://example.com/cli"> 
     <example:cli xmlns="http://example.com/cli" action="cli"> 
       enable 
       config terminal 
 
 
Chen and Allen           Expire February 2004                [Page 10] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       ip vrf v7:yellow-s 
       rd 64000:10004 
       route-target export 64000:5003 
       route-target import 64000:5002 
       maximum routes 500 80 
     </example:cli> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
                     xmlns="http://www.ietf.org/netconf/operations" 
                     xmlns:example="http://example.com/cli"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <example:cli xmlns="http://example.com/cli"> 
     </example:cli> 
   </perform-response> 
    
    
2.1.3.    Abort Operation 
    
   <abort-request messageId="message id of targeted request"/> 
    
   <abort-response messageId="message id of targeted request"> 
     <error> 
       <protocol-error code=""> 
         ... any 
       </protocol-error> 
       <application-error code=""> 
         ... any 
       </application-error> 
     </error> 
     ... any 
   </abort-response> 
    
   An "abort-request" message is a request from the managing system to 
   the managed system to prematurely terminate a previously issued 
   "perform-request" message identified by the "messageId".  For an 
   abort operation to be effective, the "abort-request" message MAY be 
   sent through a transport channel separate from the "perform-request" 
   message.  Otherwise the abort-request message could be queued behind 
   the intended "perform-request" message in the same channel. 
    
   An "abort-response" message is a response from the managed system to 
   the managing system to return the results of the "abort-request" 
   operation.  The "messageId" attribute MUST be the same message id of 
   the corresponding request message, which is used to correlate the 
   request and response message. 
    
 
 
Chen and Allen           Expire February 2004                [Page 11] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   In addition to returning the abort-response message, a managed 
   system MUST return a response to the original request (either a get-
   response or perform-response) with a protocol error code indicating 
   the operation was aborted. 
    
   The following example aborts a previous perform-request message and 
   receives a failure response. 
   <abort-request messageId="09233523-567b" 
                  xmlns="http://www.ietf.org/netconf/operations"/> 
    
   <abort-response messageId="09233523-567b"> 
                   xmlns="http://www.ietf.org/netconf/operations"/> 
     <error> 
       <protocol-error code="operationFailure"/> 
       <application-error code="noError"/> 
     </error> 
   </abort-response> 
    
    
2.1.4.    Notification 
    
   <notif messageId="message id"> 
     ... any 
   </notif> 
    
   <notif-confirm messageId="message id"> 
     <error> 
       <protocol-error code=""> 
         ... any 
       </protocol-error> 
       <application-error code=""> 
         ... any 
       </application-error> 
     </error> 
     ... any 
   </notif-confirm> 
    
   A "notif" message is a notification from the managed system to the 
   managing system to announce asynchronous events such as alarms, 
   configuration changes, etc.  Ideally, the transport channel for 
   notification messages MAY be separate from normal operation 
   messages. 
    
   A "notif-confirm" message is a confirmation from the managing system 
   to the managed system to acknowledge the receipt of a notification.  
   The "messageId" attribute MUST be the same message id as the 
   corresponding notification message, which is used to correlate the 
   notification and confirmation message. 
    
 
 
Chen and Allen           Expire February 2004                [Page 12] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   The following example shows a managed system sending an XML-based 
   syslog alarm to a managing system.  The managing system sends a 
   confirmation back to the managed system. 
   <notif messageId="09233523-567b" 
          xmlns="http://www.ietf.org/netconf/operations" 
          xmlns:example="http://example.com/schema" 
          xmlns:syslog="http://www.ietf.org/netconf/syslog"> 
     <example:runningConfig> 
       <example:ospf name="process 1"> 
         <example:area name="area 0"> 
           <example:interface name="Ethernet1/5"> 
             <example:notification> 
               <syslog:syslog> 
                 <syslog:date>Sep 26, 2002</syslog:date> 
                 <syslog:time>16:32:02.848</syslog:time> 
                 <syslog:facility>OSPF</syslog:facility> 
                 <syslog:subfacility>config</syslog:subfacility> 
                 <syslog:severity>5</syslog:severity> 
                 <syslog:description> 
                   hello interval changed 
                 </syslog:description> 
               </syslog:syslog> 
             </example:notification> 
           </example:interface> 
         </example:area> 
       </example:ospf> 
     </example:runningConfig> 
   </notif> 
    
   <notif-confirm messageId="09233523-567b" 
                  xmlns="http://www.ietf.org/netconf/operations" 
                  xmlns:example="http://example.com/schema"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
   </notif-confirm> 
    
    
2.2. Protocol Operations XML Schema 
   The formal specification of the interface protocol operations is 
   defined in XML schema, which describes each operation message 
   construct. 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema targetNamespace="http://www.ietf.org/netconf/operations" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   xmlns="http://www.ietf.org/netconf/operations" 
   elementFormDefault="qualified" attributeFormDefault="unqualified"> 
     <xs:simpleType name="Category"> 
 
 
Chen and Allen           Expire February 2004                [Page 13] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       <xs:annotation> 
         <xs:documentation>"Category" indicates the type of data: "all" 
   for all data, "config" for configuration data (e.g. 
   administativeState), "state" for state data (e.g. operationalState, 
   routing table).</xs:documentation> 
       </xs:annotation> 
       <xs:restriction base="xs:string"> 
         <xs:enumeration value="all"/> 
         <xs:enumeration value="config"/> 
         <xs:enumeration value="state"/> 
       </xs:restriction> 
     </xs:simpleType> 
     <xs:simpleType name="Action"> 
       <xs:annotation> 
         <xs:documentation>"Action" indicates the type of action that 
   the managing system performs on the configuration of the managed 
   system.</xs:documentation> 
       </xs:annotation> 
       <xs:restriction base="xs:string"> 
         <xs:enumeration value="nop"/> 
         <xs:enumeration value="create"/> 
         <xs:enumeration value="delete"/> 
         <xs:enumeration value="replace"/> 
         <xs:enumeration value="merge"/> 
         <xs:enumeration value="copy"/> 
         <xs:enumeration value="validate"/> 
         <xs:enumeration value="lock"/> 
         <xs:enumeration value="unlock"/> 
       </xs:restriction> 
     </xs:simpleType> 
     <xs:simpleType name="ProtocolErrorCode"> 
       <xs:annotation> 
         <xs:documentation>"ProtocolErrorCode" indicates the type of 
   error that occurs in the protocol layer.</xs:documentation> 
       </xs:annotation> 
       <xs:restriction base="xs:string"> 
         <xs:enumeration value="noError"/> 
         <xs:enumeration value="xmlValidationFailure"/> 
         <xs:enumeration value="operationFailure"/> 
       </xs:restriction> 
     </xs:simpleType> 
     <xs:simpleType name="ApplicationErrorCode"> 
       <xs:annotation> 
         <xs:documentation>"ApplicationErrorCode" indicates the type of 
   error that occurs in the application layer.</xs:documentation> 
       </xs:annotation> 
       <xs:restriction base="xs:string"> 
         <xs:enumeration value="noError"/> 
         <xs:enumeration value="xmlValidationFailure"/> 
         <xs:enumeration value="xpathParseFailure"/> 
 
 
Chen and Allen           Expire February 2004                [Page 14] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
         <xs:enumeration value="badArguments"/> 
       </xs:restriction> 
     </xs:simpleType> 
     <xs:complexType name="ProtocolError"> 
       <xs:annotation> 
         <xs:documentation>"ProtocolError" describes the errors that 
   occur in the protocol layer.</xs:documentation> 
       </xs:annotation> 
       <xs:sequence> 
         <xs:any minOccurs="0"> 
           <xs:annotation> 
             <xs:documentation>Detailed XML contents or text of the 
   protocol errors,  depending on the data model.</xs:documentation> 
           </xs:annotation> 
         </xs:any> 
       </xs:sequence> 
       <xs:attribute name="code" type="ProtocolErrorCode"/> 
     </xs:complexType> 
     <xs:complexType name="ApplicationError"> 
       <xs:annotation> 
         <xs:documentation>"ApplicationError" describes the errors that 
   occur in the application layer.</xs:documentation> 
       </xs:annotation> 
       <xs:sequence> 
         <xs:any minOccurs="0"> 
           <xs:annotation> 
             <xs:documentation>Detailed XML contents or text of the 
   application errors, depending on the data model.</xs:documentation> 
           </xs:annotation> 
         </xs:any> 
       </xs:sequence> 
       <xs:attribute name="code" type="ApplicationErrorCode"/> 
     </xs:complexType> 
     <xs:complexType name="Error"> 
       <xs:annotation> 
         <xs:documentation>"Error" describes the errors that occur in 
   the application or protocol interaction.</xs:documentation> 
       </xs:annotation> 
       <xs:sequence> 
         <xs:element name="protocol-error" type="ProtocolError"/> 
         <xs:element name="application-error" type="ApplicationError"/> 
       </xs:sequence> 
     </xs:complexType> 
     <xs:element name="get-request"> 
       <xs:annotation> 
         <xs:documentation>A "get-request" message is a request from 
   the managing system to the managed system to obtain specific 
   information.  The "messageId" attribute MUST uniquely identify the 
   request message and is used to correlate the request and response 
   messages.  The "category" attribute indicates the type of data that 
 
 
Chen and Allen           Expire February 2004                [Page 15] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   this "get-request" message requests.  "all" means all the data, 
   "config" means configuration data, and "state" means state data.  It 
   is recommended that each element in the data and operating model 
   schema SHOULD have an attribute "category" with a fixed value from 
   the type "Category" to indicate what type of data this element is.  
   The "subordinate" attribute indicates the scope of subordinate 
   elements which the "get-request" expects in the return.  It has the 
   value of "all" or "direct".  "all" means all levels of the 
   subordinate elements, "direct" means only direct subordinate 
   elements.  </xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   request, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
         <xs:attribute name="category" type="Category" use="required"/> 
         <xs:attribute name="subordinate" use="required"> 
           <xs:simpleType> 
             <xs:restriction base="xs:string"> 
               <xs:enumeration value="all"/> 
               <xs:enumeration value="direct"/> 
             </xs:restriction> 
           </xs:simpleType> 
         </xs:attribute> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="get-response"> 
       <xs:annotation> 
         <xs:documentation>A "get-response" message is a response from 
   the managed system to the managing system to return requested 
   information.  The "messageId" attribute MUST be the same message id 
   of the corresponding request message, which is used to correlate the 
   request and response messages.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="error" type="Error"/> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   response, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
 
 
Chen and Allen           Expire February 2004                [Page 16] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="perform-request"> 
       <xs:annotation> 
         <xs:documentation>A "perform-request" message is a request 
   from the managing system to the managed system for a specific 
   action.  The "messageId" attribute MUST uniquely identify the 
   request message and is used to correlate the request and response 
   messages.  The "transaction" attribute describes the desired message 
   transaction handling as one of the following: stop on error, 
   continue on error, or rollback on error.    The actual action SHOULD 
   be described by the data and operating model.  The recommendation is 
   that an attribute named "action" in the targeted element SHOULD 
   specify the actual action (this is referred to as "action-as-
   attribute").  The protocol operation XML schema has defined an 
   "Action" type with these permitted values: nop, create, delete, 
   replace, merge, copy, validate, lock, unlock.  Each object element 
   in the data and operating model schema SHOULD have an attribute 
   "action" of the type "Action" to indicate what actions on this 
   object (element) are permitted.  The data and operating model XML 
   schema MAY extend or restrict the permitted value of the "Action" 
   type through the XML attribute type definition 
   mechanism.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   request, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
         <xs:attribute name="transaction" use="required"> 
           <xs:simpleType> 
             <xs:restriction base="xs:string"> 
               <xs:enumeration value="stop-on-error"/> 
               <xs:enumeration value="continue-on-error"/> 
               <xs:enumeration value="rollback-on-error"/> 
             </xs:restriction> 
           </xs:simpleType> 
         </xs:attribute> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="perform-response"> 
 
 
Chen and Allen           Expire February 2004                [Page 17] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       <xs:annotation> 
         <xs:documentation>A "perform-response" message is a response 
   from the managed system to the managing system to return the results 
   of the "perform-request" operation.  The "messageId" attribute MUST 
   be the same message id of the corresponding request message, which 
   is used to correlate the request and response message.  The action-
   as-attribute approach must be considered in the response message.  
   Elements with an attribute named "action" of type "Action" MUST have 
   a value of "nop" in the perform-response message.  The value "nop" 
   SHOULD be defined in data and operating model schema as the default 
   value for attributes named "action" of type "Action."  This will 
   relieve the managed system from including the attribute in its 
   response. </xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="error" type="Error"/> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   response, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="abort-request"> 
       <xs:annotation> 
         <xs:documentation>An "abort-request" message is a request from 
   the managing system to the managed system to prematurely terminate a 
   previously issued "perform-request" message identified by the 
   "messageId".  For an abort operation to be effective, the "abort-
   request" message MAY be sent through a transport channel separate 
   from the "perform-request" message.  Otherwise the abort-request 
   message could be queued behind the intended "perform-request" 
   message in the same channel.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="abort-response"> 
       <xs:annotation> 
         <xs:documentation>An "abort-response" message is a response 
   from the managed system to the managing system to return the results 
   of the "abort-request" operation.  The "messageId" attribute MUST be 
   the same message id of the corresponding request message, which is 
 
 
Chen and Allen           Expire February 2004                [Page 18] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   used to correlate the request and response 
   message.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="error" type="Error"/> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   response, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="notif"> 
       <xs:annotation> 
         <xs:documentation>A "notif" message is a notification from the 
   managed system to the managing system to announce asynchronous 
   events such as alarms, configuration changes, etc.  Ideally, the 
   transport channel for notification messages MAY be separate from 
   normal operation messages.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   notification, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
     <xs:element name="notif-confirm"> 
       <xs:annotation> 
         <xs:documentation>A "notif-confirm" message is a confirmation 
   from the managing system to the managed system to acknowledge the 
   receipt of a notification.  The "messageId" attribute MUST be the 
   same message id as the corresponding notification message, which is 
   used to correlate the notification and confirmation 
   message.</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="error" type="Error"/> 
 
 
Chen and Allen           Expire February 2004                [Page 19] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
           <xs:any minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Detailed XML contents or text of the 
   confirmation, depending on the data model.</xs:documentation> 
             </xs:annotation> 
           </xs:any> 
         </xs:sequence> 
         <xs:attribute name="messageId" type="xs:string" 
   use="required"/> 
       </xs:complexType> 
     </xs:element> 
   </xs:schema> 
    
    
3.   Capabilities 
    
3.1. Capabilities Exchange 
   The optional functions and schema that may be supported by a managed 
   system are described in a capabilities XML dataset.  This allows a 
   managing system to discover the specific protocol operations 
   capabilities of a managed system.  The capabilities XML dataset MUST 
   be supported by the end systems.  The schema for the capabilities 
   XML data is described here. 
    
   The "capabilities" element of the managed system has three sub-
   elements: "notification", "notifSchema", and "modelSchema".  The 
   "notification" element describes the notification functionality 
   supported by the managed system, which is a list with the following 
   possible values: "notif-nonconfirm" or "notif-confirm".  A value of 
   "nonconfirm" means the managed system supports non-confirmed 
   notifications.  A value of "notif-confirm" means the managed system 
   supports confirmed notifications.  The list may have zero, one or 
   both values. 
    
   The "notifSchema" specifies the notification XML schemas supported 
   by the managed system.  Its value is a list of URLs. 
    
   The "modelSchema", specifies the data and operating model XML 
   schemas supported by the managed system.  Its value is a list of 
   URLs. 
    
   The following example shows a pair of systems exchanging the 
   capabilities through the protocol operations.  It is expected that 
   this exchange would be the very first interface interaction once the 
   end systems establish communications. 
   <get-request xmlns="http://www.ietf.org/netconf/operations"     
                xmlns:cap="http://www.ietf.org/netconf/capabilities"     
                category="all" 
                subordinate="all"> 
     <cap:capabilities/> 
 
 
Chen and Allen           Expire February 2004                [Page 20] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   </get-request> 
    
   <get-response xmlns="http://www.ietf.org/netconf/operations"  
                 xmlns:cap="http://www.ietf.org/netconf/capabilities"  
                 messageId="09233523-567b"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <cap:capabilities> 
       <cap:notification>notif-nonconfirm</cap:notification> 
       <cap:modelSchema> 
         http://example.com/schema  
         http://acme.com/schema 
       </cap:modelSchema> 
       <cap:notifSchema>http://example.com/syslog</cap:notifSchema> 
     </cap:capabilities> 
   </get-response> 
    
    
3.2. Capabilities Schema 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema 
   targetNamespace="http://www.ietf.org/netconf/capabilities" 
   xmlns="http://www.ietf.org/netconf/capabilities" 
   xmlns:ops="http://www.ietf.org/netconf/operations" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   elementFormDefault="qualified" attributeFormDefault="unqualified"> 
     <xs:import namespace="http://www.ietf.org/netconf/operations" 
   schemaLocation="netconf-operations.xsd"/> 
     <xs:simpleType name="NotificationCapabilities"> 
       <xs:annotation> 
         <xs:documentation>Notification capabilities of the managed 
   system</xs:documentation> 
       </xs:annotation> 
       <xs:list> 
         <xs:simpleType> 
           <xs:restriction base="xs:string"> 
             <xs:enumeration value="notif-nonconfirm"/> 
             <xs:enumeration value="notif-confirm"/> 
           </xs:restriction> 
         </xs:simpleType> 
       </xs:list> 
     </xs:simpleType> 
     <xs:simpleType name="SchemaCapabilities"> 
       <xs:annotation> 
         <xs:documentation>XML schemas of the managed 
   system</xs:documentation> 
       </xs:annotation> 
 
 
Chen and Allen           Expire February 2004                [Page 21] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
       <xs:list itemType="xs:anyURI"/> 
     </xs:simpleType> 
     <xs:element name="capabilities"> 
       <xs:annotation> 
         <xs:documentation>Capabilities of the managed 
   system</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="notification" minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Notification capabilities of the 
   managed system</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:simpleContent> 
                 <xs:extension base="NotificationCapabilities"> 
                   <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="state"/> 
                   <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                 </xs:extension> 
               </xs:simpleContent> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="modelSchema" minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Data model XML schemas of the managed 
   system</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:simpleContent> 
                 <xs:extension base="SchemaCapabilities"> 
                   <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="state"/> 
                   <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                 </xs:extension> 
               </xs:simpleContent> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="notifSchema" minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Notification data XML schemas of the 
   managed system</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:simpleContent> 
                 <xs:extension base="SchemaCapabilities"> 
 
 
Chen and Allen           Expire February 2004                [Page 22] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
                   <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="state"/> 
                   <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                 </xs:extension> 
               </xs:simpleContent> 
             </xs:complexType> 
           </xs:element> 
         </xs:sequence> 
         <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="state"/> 
         <xs:attribute name="action" type="ops:Action" use="optional" 
   fixed="nop"/> 
       </xs:complexType> 
     </xs:element> 
   </xs:schema> 
    
    
4.   An Example Operating Model 
    
4.1. Operating Model Descriptions 
   This is an example of a typical operating model.  It shows how a 
   particular operating model can fit into the overall interface 
   framework. 
    
   This operating model supports three manageable configuration 
   datastores: candidate configuration, startup configuration, and 
   running configuration.  It also supports one or more text-based 
   named configuration files. 
    
   Following the recommendation of the protocol operations, the 
   "category" attribute has the fixed value "all" for the manageable 
   configuration datastore.  Also the "action" attribute of the 
   manageable configuration datastore takes the "Action" type without 
   any restriction. 
    
   The named configuration files only support limited manageability.  
   The "category" attribute has the fixed value "config".  The "action" 
   attribute is a type of "Action" but restricts the allowable values 
   to: "nop", "create", "delete", and "copy". 
    
   The "source" sub-element of the configuration specifies the name of 
   configuration files or datastores from which the configuration is 
   created or copied.  The "lockedBy" sub-element of the manageable 
   configuration datastore identifies the session of the current lock 
   holder.  The "content" sub-element of the named configuration file 
   contains the text file content. 
    
   The following example copies the candidate configuration to running 
   configuration. 
 
 
Chen and Allen           Expire February 2004                [Page 23] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   <perform-request messageId="09233523-567b" 
                    xmlns="http://www.ietf.org/netconf" 
             xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <operating:runningConfig action="copy"> 
       <source>candidate</source> 
     </operating:runningConfig> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
                     xmlns="http://www.ietf.org/netconf/operations" 
          xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <operating:runningConfig> 
       copied configuration data goes here ... 
     </operating:runningConfig> 
   </perform-response> 
    
   The following example validates the startup configuration. 
   <perform-request messageId="09233523-567b" 
                    xmlns="http://www.ietf.org/netconf" 
             xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <operating:startupConfig action="validate"> 
     </operating:startupConfig> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
                     xmlns="http://www.ietf.org/netconf/operations" 
          xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <operating:startupConfig> 
       configuration data goes here if needed ... 
     </operating:startupConfig> 
   </perform-response> 
    
   The following example locks the running configuration for multiple 
   operations later on. 
   <perform-request messageId="09233523-567b" 
                    xmlns="http://www.ietf.org/netconf" 
             xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <operating:runningConfig action="lock"> 
     </operating:runningConfig> 
   </perform-request> 
    
   <perform-response messageId="09233523-567b" 
 
 
Chen and Allen           Expire February 2004                [Page 24] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
                     xmlns="http://www.ietf.org/netconf/operations" 
          xmlns:operating="http://www.ietf.org/netconf/operating"> 
     <error> 
       <protocol-error code="noError"/> 
       <application-error code="noError"/> 
     </error> 
     <operating:startupConfig> 
       <lockedBy>session id</lockedBy> 
     </operating:startupConfig> 
   </perform-response> 
    
    
4.2. Operating Model Schema 
    
   <?xml version="1.0" encoding="UTF-8"?> 
   <xs:schema targetNamespace="http://www.ietf.org/netconf/operating" 
   xmlns="http://www.ietf.org/netconf/operating" 
   xmlns:ops="http://www.ietf.org/netconf/operations" 
   xmlns:xs="http://www.w3.org/2001/XMLSchema" 
   elementFormDefault="qualified" attributeFormDefault="unqualified"> 
     <xs:import namespace="http://www.ietf.org/netconf/operations" 
   schemaLocation="netconf-operations.xsd"/> 
     <xs:element name="device"> 
       <xs:annotation> 
         <xs:documentation>Operating model of managed 
   device</xs:documentation> 
       </xs:annotation> 
       <xs:complexType> 
         <xs:sequence> 
           <xs:element name="candidateConfig" minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Candidate configuration 
   datastore</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="source" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Source name of configuration 
   file or datastore for the candidate configuration</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="config"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
 
 
Chen and Allen           Expire February 2004                [Page 25] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="lockedBy" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Session identification of the 
   lock holder</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="state"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:any> 
                   <xs:annotation> 
                     <xs:documentation>Detailed XML contents of the 
   candidate configuration, dependant on the data 
   model.</xs:documentation> 
                   </xs:annotation> 
                 </xs:any> 
               </xs:sequence> 
               <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="all"/> 
               <xs:attribute name="action" use="optional" 
   default="nop"> 
                 <xs:simpleType> 
                   <xs:restriction base="ops:Action"> 
                     <xs:enumeration value="nop"/> 
                     <xs:enumeration value="create"/> 
                     <xs:enumeration value="delete"/> 
                     <xs:enumeration value="replace"/> 
                     <xs:enumeration value="merge"/> 
                     <xs:enumeration value="validate"/> 
                     <xs:enumeration value="copy"/> 
                   </xs:restriction> 
                 </xs:simpleType> 
               </xs:attribute> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="startupConfig" minOccurs="0"> 
             <xs:annotation> 
               <xs:documentation>Startup configuration 
   datastore</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
 
 
Chen and Allen           Expire February 2004                [Page 26] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
               <xs:sequence> 
                 <xs:element name="source" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Source name of configuration 
   file or datastore for the startup configuration</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="config"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="lockedBy" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Session identification of the 
   lock holder</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="state"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:any> 
                   <xs:annotation> 
                     <xs:documentation>Detailed XML contents of the 
   startup configuration, dependant on the data 
   model</xs:documentation> 
                   </xs:annotation> 
                 </xs:any> 
               </xs:sequence> 
               <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="all"/> 
               <xs:attribute name="action" type="ops:Action" 
   use="optional" default="nop"/> 
             </xs:complexType> 
           </xs:element> 
           <xs:element name="runningConfig" minOccurs="0"> 
             <xs:annotation> 
 
 
Chen and Allen           Expire February 2004                [Page 27] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
               <xs:documentation>Running configuration 
   datastore</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="source" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Source name of configuration 
   file or datastore for the running configuration</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="config"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="lockedBy" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Session identification of the 
   lock holder</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="state"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:any> 
                   <xs:annotation> 
                     <xs:documentation>Detailed XML contents of the 
   running configuration, dependant on the data 
   model.</xs:documentation> 
                   </xs:annotation> 
                 </xs:any> 
               </xs:sequence> 
               <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="all"/> 
               <xs:attribute name="action" type="ops:Action" 
   use="optional" default="nop"/> 
             </xs:complexType> 
 
 
Chen and Allen           Expire February 2004                [Page 28] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
           </xs:element> 
           <xs:element name="namedConfig" minOccurs="0" 
   maxOccurs="unbounded"> 
             <xs:annotation> 
               <xs:documentation>Named configuration 
   file</xs:documentation> 
             </xs:annotation> 
             <xs:complexType> 
               <xs:sequence> 
                 <xs:element name="source" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Source name of configuration 
   file or datastore for this configuration file</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="config"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
                 <xs:element name="content" minOccurs="0"> 
                   <xs:annotation> 
                     <xs:documentation>Plain text contents of the 
   configuration file</xs:documentation> 
                   </xs:annotation> 
                   <xs:complexType> 
                     <xs:simpleContent> 
                       <xs:extension base="xs:string"> 
                         <xs:attribute name="category" 
   type="ops:Category" use="optional" fixed="config"/> 
                         <xs:attribute name="action" type="ops:Action" 
   use="optional" fixed="nop"/> 
                       </xs:extension> 
                     </xs:simpleContent> 
                   </xs:complexType> 
                 </xs:element> 
               </xs:sequence> 
               <xs:attribute name="category" type="ops:Category" 
   use="optional" fixed="config"/> 
               <xs:attribute name="action" use="optional" 
   default="nop"> 
                 <xs:simpleType> 
                   <xs:restriction base="ops:Action"> 
                     <xs:enumeration value="nop"/> 
                     <xs:enumeration value="create"/> 
 
 
Chen and Allen           Expire February 2004                [Page 29] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
                     <xs:enumeration value="delete"/> 
                     <xs:enumeration value="copy"/> 
                   </xs:restriction> 
                 </xs:simpleType> 
               </xs:attribute> 
               <xs:attribute name="name" type="xs:string" 
   use="optional" default="nop"/> 
             </xs:complexType> 
           </xs:element> 
         </xs:sequence> 
       </xs:complexType> 
     </xs:element> 
   </xs:schema> 
    
    
5.   Security Consideration 
    
   Security concerns regarding network management interfaces are very 
   sensitive by their nature. 
    
   The interface protocol operations specified here do not explicitly 
   address security.  They rely on the underlying protocol transport 
   and upper layer data model to provide proper security protection. 
    
    
6.   References 
    
   [RFC2119] "Key words for use in RFCs to Indicate Requirement 
   Levels", Bradner, S., March 1997. 
    
   [XML1.0] "Extensible Markup Language (XML) 1.0 (Second Edition)", 
   W3C REC-xml-20001006, October 2000.  
    
   [XML Schema-1] "XML Schema Part 1: Structures", W3C REC-xmlschema-1-
   20010502, May 2001. 
    
   [XML Schema-2] "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2-
   20010502, May 2001. 
    
   [WSDL1.1] "Web Services Description Language (WSDL) 1.1", W3C NOTE-
   wsdl-20010315, March 2001. 
    
   [XPath1.0] "XML Path Language (XPath) Version 1.0", W3C REC-xpath-
   19991116, November 1999. 
    
    
7.   Authors' Addresses 
    
   Weijing Chen 
   SBC Labs 
 
 
Chen and Allen           Expire February 2004                [Page 30] 
Internet Draft    draft-weijing-netconf-interface-01       August 2003 
 
 
   9505 Arboretum Blvd. 
   Austin, Texas 78759 
   Phone: +1 512 372 5710 
   Email: wchen@labs.sbc.com 
    
   Keith Allen 
   SBC Labs 
   9505 Arboretum Blvd. 
   Austin, Texas 78759 
   Phone: +1 512 372 5741 
   Email: kallen@labs.sbc.com 
    
 
 
 
Chen and Allen           Expire February 2004                [Page 31]