draft-ietf-netconf-notification-11.txt   draft-ietf-netconf-notification-12.txt 
Network Working Group S. Chisholm Network Working Group S. Chisholm
Internet-Draft Nortel Internet-Draft Nortel
Intended status: Standards Track H. Trevino Intended status: Standards Track H. Trevino
Expires: May 14, 2008 Cisco Expires: August 28, 2008 Cisco
November 11, 2007 February 25, 2008
NETCONF Event Notifications NETCONF Event Notifications
draft-ietf-netconf-notification-11.txt draft-ietf-netconf-notification-12.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 14, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines mechanisms that provide an asynchronous message This document defines mechanisms that provide an asynchronous message
notification delivery service for the NETCONF protocol. This is an notification delivery service for the NETCONF protocol. This is an
optional capability built on top of the base NETCONF definition. optional capability built on top of the base NETCONF definition.
This document defines the capabilities and operations necessary to This document defines the capabilities and operations necessary to
support this service. support this service.
Table of Contents Table of Contents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
6.5. Modifications to Existing Operations . . . . . . . . . . . 35 6.5. Modifications to Existing Operations . . . . . . . . . . . 35
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38
10. Normative References . . . . . . . . . . . . . . . . . . . . . 39 10. Normative References . . . . . . . . . . . . . . . . . . . . . 39
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40
A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 40
A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 42
A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 44
A.4. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44 A.4. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 A.5. Vesrion -12 . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
[NETCONF] can be conceptually partitioned into four layers: [NETCONF] can be conceptually partitioned into four layers:
Layer Example Layer Example
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| Content | | Configuration data | | Content | | Configuration data |
+-------------+ +-------------------------------------------+ +-------------+ +-------------------------------------------+
| | | |
skipping to change at page 6, line 30 skipping to change at page 6, line 30
interest in receiving event notifications from a NETCONF server by interest in receiving event notifications from a NETCONF server by
creating a subscription to receive event notifications. The NETCONF creating a subscription to receive event notifications. The NETCONF
server replies to indicate whether the subscription request was server replies to indicate whether the subscription request was
successful and, if it was successful, begins sending the event successful and, if it was successful, begins sending the event
notifications to the NETCONF client as the events occur within the notifications to the NETCONF client as the events occur within the
system. These event notifications will continue to be sent until system. These event notifications will continue to be sent until
either the NETCONF session is terminated or the subscription either the NETCONF session is terminated or the subscription
terminates for some other reason. The event notification terminates for some other reason. The event notification
subscription allows a number of options to enable the NETCONF client subscription allows a number of options to enable the NETCONF client
to specify which events are of interest. These are specified when to specify which events are of interest. These are specified when
the subscription is created. the subscription is created. Note that a subscription cannot be
modified once created.
The NETCONF server MUST accept and process the <close-session> The NETCONF server MUST accept and process the <close-session>
operation, even while the notification subscription is active. The operation, even while the notification subscription is active. The
NETCONF server MAY accept and process other commands, otherwise they NETCONF server MAY accept and process other commands, otherwise they
will be rejected and the server MUST send a 'resource-denied' error. will be rejected and the server MUST send a 'resource-denied' error.
A NETCONF server advertises support of the ability to process other A NETCONF server advertises support of the ability to process other
commands via the interleave capability. commands via the interleave capability.
2. Notification-Related Operations 2. Notification-Related Operations
skipping to change at page 10, line 26 skipping to change at page 10, line 26
interest (i.e., meeting the specified filtering criteria) has interest (i.e., meeting the specified filtering criteria) has
occurred. An event notification is a complete and well-formed XML occurred. An event notification is a complete and well-formed XML
document. Note that <notification> is not an RPC method but document. Note that <notification> is not an RPC method but
rather the top level element identifying the one-way message as a rather the top level element identifying the one-way message as a
notification. notification.
Parameters: Parameters:
eventTime eventTime
The time the event was generated by the event source The time the event was generated by the event source. This
parameter is of type dateTime.
Also contains notification-specific tagged content, if any. With Also contains notification-specific tagged content, if any. With
the exception of <eventTime>, the content of the notification is the exception of <eventTime>, the content of the notification is
beyond the scope of this document. beyond the scope of this document.
Response: Response:
No response. Not applicable. No response. Not applicable.
2.3. Terminating the Subscription 2.3. Terminating the Subscription
skipping to change at page 14, line 20 skipping to change at page 14, line 20
The following example shows retrieving the list of available event The following example shows retrieving the list of available event
stream list using the <get> operation. stream list using the <get> operation.
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get> <get>
<filter type="subtree"> <filter type="subtree">
<netconf xmlns="urn:ietf:params:xml:ns:netmod:notification"> <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
<streams/> <streams/>
<netconf> </netconf>
</filter> </filter>
</get> </get>
</rpc> </rpc>
The NETCONF server returns a list of event streams available for The NETCONF server returns a list of event streams available for
subscription: NETCONF, SNMP, and syslog-critical in this example. subscription: NETCONF, SNMP, and syslog-critical in this example.
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<data> <data>
<netconf xmlns="urn:ietf:params:xml:ns:netmod:notification"> <netconf xmlns="urn:ietf:params:xml:ns:netmod:notification">
skipping to change at page 30, line 4 skipping to change at page 30, line 4
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="event" <xs:element name="event"
type="eventType" type="eventType"
substitutionGroup="ncEvent:notificationContent"/> substitutionGroup="ncEvent:notificationContent"/>
</xs:schema> </xs:schema>
The above fictional notification definition could result in the The above fictional notification definition could result in the
following is a sample notification list, which is used in the following sample notification list, which is used in the examples in
examples in this section. this section.
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2007-07-08T00:01:00Z</eventTime> <eventTime>2007-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event/1.0"> <event xmlns="http://example.com/event/1.0">
<eventClass>fault</eventClass> <eventClass>fault</eventClass>
<reportingEntity> <reportingEntity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reportingEntity> </reportingEntity>
<severity>major</severity> <severity>major</severity>
skipping to change at page 37, line 7 skipping to change at page 37, line 7
permitted to view one element in the content of the notification, the permitted to view one element in the content of the notification, the
notification is not sent to that user. notification is not sent to that user.
If a subscription is created with a <stopTime>, the NETCONF session If a subscription is created with a <stopTime>, the NETCONF session
will return to being a normal command-response NETCONF session when will return to being a normal command-response NETCONF session when
the replay is completed. It is the responsibility of the NETCONF the replay is completed. It is the responsibility of the NETCONF
client to close this session when it is no longer of use. client to close this session when it is no longer of use.
8. IANA Considerations 8. IANA Considerations
-- Editor note to IANA/RFC-Editor: we request that you make these
assignments, in which case it is to be documented as below
This document registers three URIs for the NETCONF XML namespace in This document registers three URIs for the NETCONF XML namespace in
the IETF XML registry [RFC3688]. the IETF XML registry [RFC3688].
Following the format in RFC 3688, IANA has made the following Following the format in RFC 3688, IANA has made the following
registration. registration. Note that the capability urns as also compliant to
[NETCONF] section 10.3.
URI: urn:ietf:params:netconf:capability:notification:1.0 +--------------------+----------------------------------------------+
| Index | Capability Identifier |
+--------------------+----------------------------------------------+
| :notification | urn:ietf:params:netconf:capability: |
| | notification:1.0 |
| | |
| :interleave | urn:ietf:params:netconf:capability: |
| | interleave:1.0 |
+--------------------+----------------------------------------------+
URI: urn:ietf:params:xml:ns:netmod:notification URI: urn:ietf:params:xml:ns:netmod:notification
URI: urn:ietf:params:xml:ns:netconf:notification:1.0 URI: urn:ietf:params:xml:ns:netconf:notification:1.0
URI: urn:ietf:params:netconf:capability:interleave:1.0
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
In addition, IANA registered the following XML Schema, the definition
of which can be found in Section 4:
http://www.iana.org/assignments/xml-registry/schema/notification.xsd
9. Acknowledgements 9. Acknowledgements
Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing
their input into the early work on this document. In addition, the their input into the early work on this document. In addition, the
editors would like to acknowledge input at the Vancouver editing editors would like to acknowledge input at the Vancouver editing
session from the following people: Orly Nicklass, James Balestriere, session from the following people: Orly Nicklass, James Balestriere,
Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington,
Dave Partain, Ray Atarashi and David Perkins and the following Dave Partain, Ray Atarashi and David Perkins and the following
additional people from the Montreal editing session: Balazs Lengyel, additional people from the Montreal editing session: Balazs Lengyel,
Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen,
Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig,
Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William
Chow. We would also like to thank Li Yan for his numerous reviews. Chow. We would also like to thank Li Yan for his numerous reviews as
well as Suresh Krishnan for his gen-art review of the document.
10. Normative References 10. Normative References
[NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January [RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January
2004. 2004.
[XML] World Wide Web Consortium, "Extensible Markup Language [XML] World Wide Web Consortium, "Extensible Markup Language
(XML) 1.0", W3C XML, February 1998, (XML) 1.0", W3C XML, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[XML Schema] [XML Schema]
Fallside, D. and P. Walmsley, "XML Schema Part 0: Primer Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
Second Edition", W3C XML Schema, October 2004. "XML Schema Part 1: Structures Second Edition", W3C http:/
/www.w3.org/TR/2004/REC-xmlschema-1-20041028/
structures.html, October 2004.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", Version 1.0",
W3C http://www.w3.org/TR/1999/REC-xpath-19991116, W3C http://www.w3.org/TR/1999/REC-xpath-19991116,
November 1999. November 1999.
Appendix A. Change Log Appendix A. Change Log
-- Editor note to RFC-Editor: we request that you remove this section
before publishing.
A.1. Version -08 A.1. Version -08
1. Removed named profiles 1. Removed named profiles
2. Removed eventClass that was accidentally included in the 2. Removed eventClass that was accidentally included in the
definition of the replayComplete notification definition of the replayComplete notification
3. Deleted data wrapper from notification 3. Deleted data wrapper from notification
4. Changed replayLogStartTime to have a minOccurs of 0. It will 4. Changed replayLogStartTime to have a minOccurs of 0. It will
skipping to change at page 44, line 46 skipping to change at page 45, line 4
4. Corrected targetNamespace in Netconf Notification XSD 4. Corrected targetNamespace in Netconf Notification XSD
5. Fixed typos and made minor edits. 5. Fixed typos and made minor edits.
A.4. Version -11 A.4. Version -11
1. Fixed namespaces 1. Fixed namespaces
2. In section 6.5, fixed error message Error-info 2. In section 6.5, fixed error message Error-info
3. In section 6.1 clarify that if the interleave capability is 3. In section 6.1 clarify that if the interleave capability is
supported, then the server must respond to requests. supported, then the server must respond to requests.
A.5. Vesrion -12
1. Add to section 1.3 the clarification "Note that a subscription
cannot be modified once created."
2. In section 2.2.1, in the description of eventTime, added the
following text: "This parameter is of type dateTime."
3. Fixed several typos.
4. Added the following text to the IANA considerations section: "--
Editor note to IANA/RFC-Editor: we request that you make these
assignments, in which case it is top be documented as below" "
5. Replaced/Updated XML Schema reference to be " [XML Schema]
Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., "XML Schema
Part 1: Structures Second Edition", W3C Recommendation, 28
October 2004 <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
structures.html> "
6. Add instructions to RFC editor to remove change log before
publication
7. Added IANA registration item for http://www.iana.org/assignments/
xml-registry/schema/notification.xsd
8. Clarified in the IANA considerations section that the capability
URIs were complaint to RFC4741 section 10.3
Authors' Addresses Authors' Addresses
Sharon Chisholm Sharon Chisholm
Nortel Nortel
3500 Carling Ave 3500 Carling Ave
Nepean, Ontario K2H 8E9 Nepean, Ontario K2H 8E9
Canada Canada
Email: schishol@nortel.com Email: schishol@nortel.com
skipping to change at page 46, line 7 skipping to change at page 47, line 7
Cisco Cisco
Suite 400 Suite 400
9155 E. Nichols Ave 9155 E. Nichols Ave
Englewood, CO 80112 Englewood, CO 80112
USA USA
Email: htrevino@cisco.com Email: htrevino@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 20 change blocks. 
21 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/