--- 1/draft-ietf-netconf-notification-10.txt	2007-11-12 20:12:07.000000000 +0100
+++ 2/draft-ietf-netconf-notification-11.txt	2007-11-12 20:12:07.000000000 +0100
@@ -1,18 +1,19 @@
+
 Network Working Group                                        S. Chisholm
 Internet-Draft                                                    Nortel
 Intended status: Standards Track                              H. Trevino
-Expires: April 19, 2008                                            Cisco
-                                                        October 17, 2007
+Expires: May 14, 2008                                              Cisco
+                                                       November 11, 2007
 
                       NETCONF Event Notifications
-                 draft-ietf-netconf-notification-10.txt
+                 draft-ietf-netconf-notification-11.txt
 
 Status of this Memo
 
    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
@@ -23,21 +24,21 @@
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
-   This Internet-Draft will expire on April 19, 2008.
+   This Internet-Draft will expire on May 14, 2008.
 
 Copyright Notice
 
    Copyright (C) The IETF Trust (2007).
 
 Abstract
 
    This document defines mechanisms that provide an asynchronous message
    notification delivery service for the NETCONF protocol.  This is an
    optional capability built on top of the base NETCONF definition.
@@ -85,20 +86,21 @@
      6.4.  New Operations . . . . . . . . . . . . . . . . . . . . . . 35
      6.5.  Modifications to Existing Operations . . . . . . . . . . . 35
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 36
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 37
    9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
    10. Normative References . . . . . . . . . . . . . . . . . . . . . 39
    Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 40
      A.1.  Version -08  . . . . . . . . . . . . . . . . . . . . . . . 40
      A.2.  Version -09  . . . . . . . . . . . . . . . . . . . . . . . 42
      A.3.  Version -10  . . . . . . . . . . . . . . . . . . . . . . . 44
+     A.4.  Version -11  . . . . . . . . . . . . . . . . . . . . . . . 44
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
    Intellectual Property and Copyright Statements . . . . . . . . . . 46
 
 1.  Introduction
 
    [NETCONF] can be conceptually partitioned into four layers:
 
         Layer                            Example
     +-------------+      +-------------------------------------------+
     |   Content   |      |     Configuration data                    |
@@ -348,21 +350,21 @@
          out of range, pattern mismatch.
 
 2.1.1.1.  Usage Example
 
    The following demonstrates creating a simple subscription.  More
    complex examples can be found in section 5.
 
    <netconf:rpc message-id="101"
          xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"/>
        <create-subscription
-           xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+           xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
        </create-subscription>
    </netconf:rpc>
 
 2.2.  Sending Event Notifications
 
    Once the subscription has been set up, the NETCONF server sends the
    event notifications asynchronously over the connection.
 
 2.2.1.  <notification>
 
@@ -690,41 +692,41 @@
 
    This Schema is used to learn about the event streams supported on the
    system.  It also contains the definition of the <replayComplete> and
    <notificationComplete> notifications, which are sent to indicate that
    an event replay has sent all applicable notifications and that the
    subscription has terminated, respectively.
 
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
-    xmlns:ncEvent="urn:ietf:params:netconf:capability:notification:1.0"
+    xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0"
     xmlns:manageEvent="urn:ietf:params:xml:ns:netmod:notification"
     targetNamespace="urn:ietf:params:xml:ns:netmod:notification"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified"
     xml:lang="en" version="1.0">
     <xs:annotation>
         <xs:documentation xml:lang="en">
             A schema that can be used to learn about current
             event streams. It also contains the replayComplete
             and notificationComplete  notification.
         </xs:documentation>
     </xs:annotation>
 
 <xs:import namespace="http://www.w3.org/XML/1998/namespace"
         schemaLocation="http://www.w3.org/2001/xml.xsd"/>
 <xs:import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
     schemaLocation=
      "http://www.iana.org/assignments/xml-registry/schema/netconf.xsd"/>
 <xs:import namespace=
-    "urn:ietf:params:netconf:capability:notification:1.0"
+    "urn:ietf:params:xml:ns:netconf:notification:1.0"
       schemaLocation=
 "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>
 <!-- The above  schemaLocation value is a placeholder and the actual
                                       value will be assigned by IANA -->
 
 <xs:element name="netconf" type="manageEvent:Netconf"/>
 
 <xs:complexType name="Netconf">
   <xs:sequence>
       <xs:element name="streams" >
@@ -1118,24 +1120,24 @@
    state.
 
    Examples in this section are generated from the following fictional
    Schema.
 
  <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema targetNamespace="http://example.com/event/1.0"
     xmlns="http://example.com/event/1.0"
     elementFormDefault="qualified"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
-    xmlns:ncEvent="urn:ietf:params:netconf:capability:notification:1.0">
+    xmlns:ncEvent="urn:ietf:params:xml:ns:netconf:notification:1.0">
 
     <xs:import namespace=
-        "urn:ietf:params:netconf:capability:notification:1.0"
+        "urn:ietf:params:xml:ns:netconf:notification:1.0"
         schemaLocation=
 "http://www.iana.org/assignments/xml-registry/schema/notification.xsd"/>
 
     <xs:complexType name="eventType">
         <xs:complexContent>
             <xs:extension base="ncEvent:NotificationContentType">
                 <xs:sequence>
                     <xs:element name="eventClass" />
                     <xs:element name="reportingEntity">
                         <xs:complexType>
@@ -1158,57 +1160,57 @@
         type="eventType"
         substitutionGroup="ncEvent:notificationContent"/>
 
 </xs:schema>
 
    The above fictional notification definition could result in the
    following is a sample notification list, which is used in the
    examples in this section.
 
    <notification
-      xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+      xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2007-07-08T00:01:00Z</eventTime>
       <event xmlns="http://example.com/event/1.0">
          <eventClass>fault</eventClass>
          <reportingEntity>
              <card>Ethernet0</card>
          </reportingEntity>
          <severity>major</severity>
        </event>
    </notification>
 
    <notification
-     xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+     xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2007-07-08T00:02:00Z</eventTime>
       <event xmlns="http://example.com/event/1.0">
           <eventClass>fault</eventClass>
           <reportingEntity>
               <card>Ethernet2</card>
           </reportingEntity>
           <severity>critical</severity>
        </event>
    </notification>
 
    <notification
-     xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+     xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
       <eventTime>2007-07-08T00:04:00Z</eventTime>
       <event xmlns="http://example.com/event/1.0">
           <eventClass>fault</eventClass>
           <reportingEntity>
                <card>ATM1</card>
            </reportingEntity>
            <severity>minor</severity>
       </event>
    </notification>
 
    <notification
-     xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+     xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
      <eventTime>2007-07-08T00:10:00Z</eventTime>
      <event xmlns="http://example.com/event/1.0">
          <eventClass>state</eventClass>
          <reportingEntity>
              <card>Ethernet0</card>
          </reportingEntity>
          <operState>enabled</operState>
       </event>
    </notification>
 
@@ -1225,21 +1227,21 @@
    The following example illustrates how to select fault events which
    have severities of critical, major, or minor.  The filtering criteria
    evaluation is as follows:
 
    ((fault & severity=critical) | (fault & severity=major) | (fault &
    severity=minor))
 
       <netconf:rpc netconf:message-id="101"
               xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
         <create-subscription
-            xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+              xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
           <filter netconf:type="subtree">
             <event xmlns="http://example.com/event/1.0">
               <eventClass>fault</eventClass>
               <severity>critical</severity>
             </event>
             <event xmlns="http://example.com/event/1.0">
               <eventClass>fault</eventClass>
               <severity>major</severity>
             </event>
             <event xmlns="http://example.com/event/1.0">
@@ -1252,21 +1254,21 @@
 
    The following example illustrates how to select state or config
    EventClasses or fault events that are related to card Ethernet0.  The
    filtering criteria evaluation is as follows:
 
    ( state | config | ( fault & ( card=Ethernet0)))
 
 <netconf:rpc netconf:message-id="101"
                 xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
       <create-subscription
-          xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+          xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
         <filter netconf:type="subtree">
           <event xmlns="http://example.com/event/1.0">
             <eventClass>state</eventClass>
           </event>
           <event xmlns="http://example.com/event/1.0">
             <eventClass>config</eventClass>
           </event>
           <event xmlns="http://example.com/event/1.0">
             <eventClass>fault</eventClass>
             <reportingEntity>
@@ -1282,54 +1284,54 @@
    The following [XPATH] example illustrates how to select fault
    EventClass notifications that have severities of critical, major, or
    minor.  The filtering criteria evaluation is as follows:
 
    ((fault) & ((severity=critical) | (severity=major) | (severity =
    minor)))
 
     <netconf:rpc netconf:message-id="101"
               xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
       <create-subscription
-            xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+              xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
         <filter netconf:type="xpath"
                 xmlns:ex="http://example.com/event/1.0"
            select="/ex:event[ex:eventClass='fault' and
                 (ex:severity='minor' or ex:severity='major'
                      or ex:severity='critical')]"/>
       </create-subscription>
     </netconf:rpc>
 
    The following example illustrates how to select state and config
    EventClasses or fault events of any severity that come from card
    Ethernet0.  The filtering criteria evaluation is as follows:
 
    ( state | config | (fault & card=Ethernet0))
 
       <netconf:rpc message-id="101"
               xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0">
         <create-subscription
-           xmlns="urn:ietf:params:netconf:capability:notification:1.0">
+           xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
              <filter netconf:type="xpath"
                      xmlns:ex="http://example.com/event/1.0"
                 select="/ex:event[
                    (ex:eventClass='state' or ex:eventClass='config') or
                    ((ex:eventClass='fault' and ex:card='Ethernet0'))]"/>
        </create-subscription>
      </netconf:rpc>
 
 6.  Interleave Capability
 
 6.1.  Description
 
    The Interleave capability indicates that the NETCONF peer supports
    the ability to interleave other NETCONF operations within a
-   Notification subscription.  This means the NETCONF server is able to
+   Notification subscription.  This means the NETCONF server MUST
    receive, process and respond to NETCONF requests on a session with an
    active notification subscription.
 
 6.2.  Dependencies
 
    This capability is dependant on the notification capability being
    supported.
 
 6.3.  Capability Identifier
 
@@ -1346,21 +1348,21 @@
 
    When a <create-subscription> is sent while another subscription is
    active on that session, the following error will be returned:
 
       Tag: operation-failed
 
       Error-type: protocol
 
       Severity: error
 
-      Error-info: <bad-element>: startTime
+      Error-info: none
 
       Description: Request could not be completed because the requested
       operation failed for some reason not covered by any other error
       condition.
 
 7.  Security Considerations
 
    The security considerations from the base [NETCONF] document also
    apply to the Notification capability.
 
@@ -1679,20 +1681,29 @@
        future.
 
    2.  Added interleave capability
 
    3.  Clarified create-subscription error messages.
 
    4.  Corrected targetNamespace in Netconf Notification XSD
 
    5.  Fixed typos and made minor edits.
 
+A.4.  Version -11
+
+   1.  Fixed namespaces
+
+   2.  In section 6.5, fixed error message Error-info
+
+   3.  In section 6.1 clarify that if the interleave capability is
+       supported, then the server must respond to requests.
+
 Authors' Addresses
 
    Sharon Chisholm
    Nortel
    3500 Carling Ave
    Nepean, Ontario  K2H 8E9
    Canada
 
    Email: schishol@nortel.com