idnits 2.17.1 draft-ietf-netconf-notification-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1915. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 580 has weird spacing: '...netconf xmlns...' == Line 722 has weird spacing: '...omplete notif...' == Line 733 has weird spacing: '...e above schem...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2008) is 5810 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4741 (ref. 'NETCONF') (Obsoleted by RFC 6241) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPATH' Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Chisholm 3 Internet-Draft Nortel 4 Intended status: Standards Track H. Trevino 5 Expires: November 30, 2008 Cisco 6 May 29, 2008 8 NETCONF Event Notifications 9 draft-ietf-netconf-notification-13.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 30, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines mechanisms that provide an asynchronous message 43 notification delivery service for the NETCONF protocol. This is an 44 optional capability built on top of the base NETCONF definition. 45 This document defines the capabilities and operations necessary to 46 support this service. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 52 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 53 1.3. Event Notifications in NETCONF . . . . . . . . . . . . . . 6 54 2. Notification-Related Operations . . . . . . . . . . . . . . . 7 55 2.1. Subscribing to Receive Event Notifications . . . . . . . . 7 56 2.1.1. . . . . . . . . . . . . . . . . 7 57 2.2. Sending Event Notifications . . . . . . . . . . . . . . . 10 58 2.2.1. . . . . . . . . . . . . . . . . . . . . 10 59 2.3. Terminating the Subscription . . . . . . . . . . . . . . . 10 60 3. Supporting Concepts . . . . . . . . . . . . . . . . . . . . . 11 61 3.1. Capabilities Exchange . . . . . . . . . . . . . . . . . . 11 62 3.1.1. Capability Identifier . . . . . . . . . . . . . . . . 11 63 3.1.2. Capability Example . . . . . . . . . . . . . . . . . . 11 64 3.2. Event Streams . . . . . . . . . . . . . . . . . . . . . . 11 65 3.2.1. Event Stream Definition . . . . . . . . . . . . . . . 13 66 3.2.2. Event Stream Content Format . . . . . . . . . . . . . 13 67 3.2.3. Default Event Stream . . . . . . . . . . . . . . . . . 13 68 3.2.4. Event Stream Sources . . . . . . . . . . . . . . . . . 13 69 3.2.5. Event Stream Discovery . . . . . . . . . . . . . . . . 13 70 3.3. Notification Replay . . . . . . . . . . . . . . . . . . . 16 71 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16 72 3.3.2. Creating a Subscription with Replay . . . . . . . . . 17 73 3.4. Notification Management Schema . . . . . . . . . . . . . . 17 74 3.5. Subscriptions Data . . . . . . . . . . . . . . . . . . . . 21 75 3.6. Filter Mechanics . . . . . . . . . . . . . . . . . . . . . 21 76 3.6.1. Filtering . . . . . . . . . . . . . . . . . . . . . . 21 77 3.7. Message Flow . . . . . . . . . . . . . . . . . . . . . . . 21 78 4. XML Schema for Event Notifications . . . . . . . . . . . . . . 24 79 5. Filtering Examples . . . . . . . . . . . . . . . . . . . . . . 28 80 5.1. Subtree Filtering . . . . . . . . . . . . . . . . . . . . 31 81 5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 32 82 6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 34 83 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 34 84 6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 34 85 6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 34 86 6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 34 87 6.5. Modifications to Existing Operations . . . . . . . . . . . 34 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 35 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 38 91 10. Normative References . . . . . . . . . . . . . . . . . . . . . 39 92 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 40 93 A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 40 94 A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 42 95 A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 44 96 A.4. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 44 97 A.5. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 45 98 A.6. Version -13 . . . . . . . . . . . . . . . . . . . . . . . 45 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 100 Intellectual Property and Copyright Statements . . . . . . . . . . 49 102 1. Introduction 104 [NETCONF] can be conceptually partitioned into four layers: 106 Layer Example 107 +-------------+ +-------------------------------------------+ 108 | Content | | Configuration data | 109 +-------------+ +-------------------------------------------+ 110 | | 111 +-------------+ +-------------------------------------------+ 112 | Operations | | , | 113 +-------------+ +-------------------------------------------+ 114 | | | 115 +-------------+ +-----------------------------+ | 116 | RPC | | , | | 117 +-------------+ +-----------------------------+ | 118 | | | 119 +-------------+ +-------------------------------------------+ 120 | Transport | | BEEP, SSH, SSL, console | 121 | Protocol | | | 122 +-------------+ +-------------------------------------------+ 124 Figure 1 126 This document defines mechanisms which provide an asynchronous 127 message notification delivery service for the [NETCONF] protocol. 128 This is an optional capability built on top of the base NETCONF 129 definition. This memo defines the capabilities and operations 130 necessary to support this service. 132 1.1. Definition of Terms 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 Element: An [XML] Element. 140 Subscription: An agreement and method to receive event notifications 141 over a NETCONF session. A concept related to the delivery of 142 notifications (if there are any to send) involving destination and 143 selection of notifications. It is bound to the lifetime of a 144 session. 146 Operation: This term is used to refer to NETCONF protocol operations 147 [NETCONF]. Within this document, operation refers to NETCONF 148 protocol operations defined in support of NETCONF notifications. 150 Event: An event is something that happens which may be of interest - 151 a configuration change, a fault, a change in status, crossing a 152 threshold, or an external input to the system, for example. Often 153 this results in an asynchronous message, sometimes referred to as 154 a notification or event notification, being sent to interested 155 parties to notify them that this event has occurred. 157 Replay: The ability to send/re-send previously logged notifications 158 upon request. These notifications are sent asynchronously. This 159 feature is implemented by the NETCONF server and invoked by the 160 NETCONF client. 162 Stream: An event stream is a set of event notifications matching 163 some forwarding criteria and available to NETCONF clients for 164 subscription. 166 Filter: A parameter that indicates which subset of all possible 167 events are of interest. A filter is defined as one or more filter 168 element [NETCONF], which each identifies a portion of the overall 169 filter. 171 1.2. Motivation 173 The motivation for this work is to enable the sending of asynchronous 174 messages that are consistent with the data model (content) and 175 security model used within a NETCONF implementation. 177 The scope of the work aims meeting the following operational needs: 179 o Initial release should ensure it supports notifications in support 180 of configuration operations. 182 o It should be possible to use the same data model for notifications 183 as for configuration operations. 185 o Solution should support a reasonable message size limit (i.e., not 186 too short) 188 o The notifications should be carried over a connection-oriented 189 delivery mechanism. 191 o A subscription mechanism for notifications should be provided. 192 This takes into account that a NETCONF server does not send 193 notifications before being asked to do so and that it is the 194 NETCONF client who initiates the flow of notifications. 196 o A filtering mechanism for sending notifications should be put in 197 place within the NETCONF server. 199 o The information contained in a notification should be sufficient 200 so that it can be analyzed independent of the transport mechanism. 201 In other words the data content fully describes a notification; 202 protocol information is not needed to understand a notification. 204 o The server should have the capability to replay locally logged 205 notifications. 207 1.3. Event Notifications in NETCONF 209 This memo defines a mechanism whereby the NETCONF client indicates 210 interest in receiving event notifications from a NETCONF server by 211 creating a subscription to receive event notifications. The NETCONF 212 server replies to indicate whether the subscription request was 213 successful and, if it was successful, begins sending the event 214 notifications to the NETCONF client as the events occur within the 215 system. These event notifications will continue to be sent until 216 either the NETCONF session is terminated or the subscription 217 terminates for some other reason. The event notification 218 subscription allows a number of options to enable the NETCONF client 219 to specify which events are of interest. These are specified when 220 the subscription is created. Note that a subscription cannot be 221 modified once created. 223 The NETCONF server MUST accept and process the 224 operation, even while the notification subscription is active. The 225 NETCONF server MAY accept and process other commands, otherwise they 226 will be rejected and the server MUST send a 'resource-denied' error. 227 A NETCONF server advertises support of the ability to process other 228 commands via the interleave capability. 230 2. Notification-Related Operations 232 2.1. Subscribing to Receive Event Notifications 234 The event notification subscription is initiated by the NETCONF 235 client and responded to by the NETCONF server. A subscription is 236 bound to a single stream for the lifetime of the subscription. When 237 the event notification subscription is created, the events of 238 interest are specified. 240 Content for an event notification subscription can be selected by 241 applying user-specified filters. 243 2.1.1. 245 Description: 247 This operation initiates an event notification subscription which 248 will send asynchronous event notifications to the initiator of the 249 command until the subscription terminates. 251 Parameters: 253 Stream: 255 An optional parameter, , that indicates which stream of 256 events is of interest. If not present, events in the default 257 NETCONF stream will be sent. 259 Filter: 261 An optional parameter, , that indicates which subset of 262 all possible events is of interest. The format of this 263 parameter is the same as that of the filter parameter in the 264 NETCONF protocol operations. If not present, all events not 265 precluded by other parameters will be sent. See section 3.6 266 for more information on filters. 268 Start Time: 270 A parameter, , used to trigger the replay feature 271 and indicate that the replay should start at the time 272 specified. If is not present, this is not a replay 273 subscription. It is not valid to specify start times that are 274 later than the current time. If the specified is 275 earlier than the log can support, the replay will begin with 276 the earliest available notification. This parameter is of type 277 dateTime and compliant to [RFC3339]. Implementations must 278 support time zones. 280 Stop Time: 282 An optional parameter, , used with the optional 283 replay feature to indicate the newest notifications of 284 interest. If stop time is not present, the notifications will 285 continue until the subscription is terminated. Must be used 286 with and be later than . Values of in 287 the future are valid. This parameter is of type dateTime and 288 compliant to [RFC3339]. Implementations must support time 289 zones. 291 Positive Response: 293 If the NETCONF server can satisfy the request, the server sends an 294 element. 296 Negative Response: 298 An element is included within the if the 299 request cannot be completed for any reason. Subscription requests 300 will fail if a filter with invalid syntax is provided or if the 301 name of a non-existent stream is provided. 303 If a is specified in a request without having specified 304 a , the following error is returned: 306 Tag: missing-element 308 Error-type: protocol 310 Severity: error 312 Error-info: : startTime 314 Description: An expected element is missing. 316 If the optional replay feature is requested but it is not 317 supported by the NETCONF server, the following error is returned: 319 Tag: operation-failed 321 Error-type: protocol 322 Severity: error 324 Error-info: none 326 Description: Request could not be completed because the 327 requested operation failed for some reason not covered by any 328 other error condition 330 If a is requested which is earlier then the specified 331 , the following error is returned: 333 Tag: bad-element 335 Error-type: protocol 337 Severity: error 339 Error-info: : stopTime 341 Description: An element value is not correct; e.g., wrong type, 342 out of range, pattern mismatch. 344 If a is requested which is later then the current 345 time, the following error is returned: 347 Tag: bad-element 349 Error-type: protocol 351 Severity: error 353 Error-info: : startTime 355 Description: An element value is not correct; e.g., wrong type, 356 out of range, pattern mismatch. 358 2.1.1.1. Usage Example 360 The following demonstrates creating a simple subscription. More 361 complex examples can be found in section 5. 363 365 367 368 370 2.2. Sending Event Notifications 372 Once the subscription has been set up, the NETCONF server sends the 373 event notifications asynchronously over the connection. 375 2.2.1. 377 Description: 379 An event notification is sent to the client who initiated a 380 command asynchronously when an event of 381 interest (i.e., meeting the specified filtering criteria) has 382 occurred. An event notification is a complete and well-formed XML 383 document. Note that is not an RPC method but 384 rather the top level element identifying the one-way message as a 385 notification. 387 Parameters: 389 eventTime 391 The time the event was generated by the event source. This 392 parameter is of type dateTime and compliant to [RFC3339]. 393 Implementations must support time zones. 395 Also contains notification-specific tagged content, if any. With 396 the exception of , the content of the notification is 397 beyond the scope of this document. 399 Response: 401 No response. Not applicable. 403 2.3. Terminating the Subscription 405 Closing of the event notification subscription can be done by using 406 the operation from the subscriptions session or 407 terminating the NETCONF session ( ) or the underlying 408 transport session from another session. If a stop time is provided 409 when the subscription is created, the subscription will terminate 410 after the stop time is reached. In this case, the NETCONF session 411 will still be an active session. 413 3. Supporting Concepts 415 3.1. Capabilities Exchange 417 The ability to process and send event notifications is advertised 418 during the capability exchange between the NETCONF client and server. 420 3.1.1. Capability Identifier 422 "urn:ietf:params:netconf:capability:notification:1.0" 424 3.1.2. Capability Example 426 427 428 429 urn:ietf:params:xml:ns:netconf:base:1.0 430 431 432 urn:ietf:params:netconf:capability:startup:1.0 433 434 435 urn:ietf:params:netconf:capability:notification:1.0 436 437 438 4 439 441 3.2. Event Streams 443 An event stream is defined as a set of event notifications matching 444 some forwarding criteria. 446 Figure 2 illustrates the notification flow and concepts identified in 447 this document. It does not mandate and/or preclude an 448 implementation. The following is observed from the diagram below: 449 System components (c1..cn) generate event notifications which are 450 passed to a central component for classification and distribution. 451 The central component inspects each event notification and matches 452 the event notification against the set of stream definitions. When a 453 match occurs, the event notification is considered to be a member of 454 that event stream (stream 1..stream n). An event notification may be 455 part of multiple event streams. 457 At some point after the NETCONF server receives the internal event 458 from a stream, it is converted to an appropriate XML encoding by the 459 server, and a element is ready to send to all NETCONF 460 sessions subscribed to that stream. 462 After generation of the element, access control is 463 applied by the server. If a session does not have permission to 464 receive the , then it is discarded for that session, 465 and processing of the internal event is completed for that session. 467 When a NETCONF client subscribes to a given event stream, user- 468 defined filter elements, if applicable, are applied to the event 469 stream and matching event notifications are forwarded to the NETCONF 470 server for distribution to subscribed NETCONF clients. A filter is 471 transferred from the client to the server during the operation and applied against each 473 element generated by the stream. For more information on filtering, 474 see section 3.6. 476 A notification logging service may also be available, in which case, 477 the central component logs notifications. The NETCONF server may 478 later retrieve logged notifications via the optional replay feature. 479 For more information on replay, see section 3.3. 481 +----+ 482 | c1 |----+ available streams 483 +----+ | +---------+ 484 +----+ | |central |-> stream 1 485 | c2 | +--->|event |-> stream 2 filter +-------+ 486 +----+ | |processor|-> NETCONF stream ----->|NETCONF| 487 ... | | |-> stream n |server | 488 System | +---------+ +-------+ 489 Components| | /\ 490 ... | | || 491 +----+ | | (------------) || 492 | cn |----+ | (notification) || 493 +----+ +-----> ( logging ) || 494 ( service ) || 495 (------------) || 496 || 497 || 498 \/ 499 +-------+ 500 |NETCONF| 501 |client | 502 +-------+ 504 Figure 2 506 3.2.1. Event Stream Definition 508 Event streams are predefined on the managed device. The 509 configuration of event streams is outside the scope of this document. 510 However, it is envisioned that event streams are either pre- 511 established by the vendor (pre-configured), user configurable (e.g., 512 part of the device's configuration) or both. Device vendors may 513 allow event stream configuration via the NETCONF protocol (i.e., 514 operation). 516 3.2.2. Event Stream Content Format 518 The contents of all event streams made available to a NETCONF client 519 (i.e., the notification sent by the NETCONF server) MUST be encoded 520 in XML. 522 3.2.3. Default Event Stream 524 A NETCONF server implementation supporting the notification 525 capability MUST support the "NETCONF" notification event stream. 526 This stream contains all NETCONF XML event notifications supported by 527 the NETCONF server. The exact string "NETCONF" is used during 528 advertisement of stream support during the operation on 529 and during the operation. Definition 530 of the event notifications and their contents, beyond the inclusion 531 of , for this event stream is outside the scope of this 532 document. 534 3.2.4. Event Stream Sources 536 With the exception of the default event stream (NETCONF), 537 specification of additional event stream sources (e.g., SNMP, syslog) 538 is outside the scope of this document. NETCONF server 539 implementations may leverage any desired event stream source in the 540 creation of supported event streams. 542 3.2.5. Event Stream Discovery 544 A NETCONF client retrieves the list of supported event streams from a 545 NETCONF server using the operation. 547 3.2.5.1. Name Retrieval using operation 549 The list of available event streams is retrieved by requesting the 550 subtree via a operation. Available event streams for 551 the requesting session are returned in the reply containing the 552 and elements, where the element is 553 mandatory, and its value is unique within the scope of a NETCONF 554 server. An empty reply is returned if there are no available event 555 streams, due to user-specified filters on the operation . 557 Additional information available about a stream include whether 558 notification replay is available and if so, the timestamp of the 559 earliest possible notification to replay. 561 The following example shows retrieving the list of available event 562 stream list using the operation. 564 566 567 568 569 570 571 572 573 574 The NETCONF server returns a list of event streams available for 575 subscription: NETCONF, SNMP, and syslog-critical in this example. 577 579 580 581 582 583 NETCONF 584 default NETCONF event stream 585 586 true 587 588 2007-07-08T00:00:00Z 589 590 591 592 SNMP 593 SNMP notifications 594 false 595 596 597 syslog-critical 598 Critical and higher severity 599 600 true 601 602 2007-07-01T00:00:00Z 603 604 605 606 607 608 610 3.2.5.2. Event Stream Subscription 612 A NETCONF client may request from the NETCONF server the list of 613 event streams available to this session and then issue a request with the desired event stream name. Omitting 615 the event stream name from the request results 616 in subscription to the default NETCONF event stream. 618 3.2.5.2.1. Filtering Event Stream Contents 620 The set of event notifications delivered in an event stream may be 621 further refined by applying a user-specified filter supplied at 622 subscription creation time ( ). This is a 623 transient filter associated with the event notification subscription 624 and does not modify the event stream configuration. The filter 625 element is applied against the contents of the wrapper 626 and not the wrapper itself. See section 5 for examples. Either 627 subtree or XPATH filtering can be used. 629 XPATH support for the Notification capability is advertised as part 630 of the normal XPATH capability advertisement. If XPATH support is 631 advertised via the XPATH capability then XPATH is supported for 632 notification filtering and if this capability is not advertised, 633 XPATH is not supported for notification filtering. 635 3.3. Notification Replay 637 3.3.1. Overview 639 Replay is the ability to create an event subscription that will 640 resend recently generated notifications, or in some cases send them 641 for the first time to a particular NETCONF client. These 642 notifications are sent the same way as normal notifications. 644 A replay of notifications is specified by including the optional 645 parameter to the subscription command, which indicates 646 the start time of the replay. The end time is specified using the 647 optional parameter. If not present, notifications will 648 continue to be sent until the subscription is terminated. 650 A notification stream that supports replay is not expected to have an 651 unlimited supply of saved notifications available to accommodate any 652 replay request. Clients can query and 653 to learn about the availability of notifications 654 for replay. 656 The actual number of stored notifications available for retrieval at 657 any given time is a NETCONF server implementation specific matter. 658 Control parameters for this aspect of the feature are outside the 659 scope of this document. 661 Replay is dependent on a notification stream supporting some form of 662 notification logging, although it puts no restrictions on the size or 663 form of the log, or where it resides within the device. Whether or 664 not a stream supports replay can be discovered by doing a 665 operation on the element of the Notification Management 666 Schema and looking at the value of the object. This 667 schema also provides the element to indicate 668 the earliest available logged notification. 670 3.3.2. Creating a Subscription with Replay 672 This feature uses optional parameters to the 673 command called and . identifies the 674 earliest date and time of interest for event notifications being 675 replayed and also indicates that a subscription will be providing 676 replay of notifications. Events generated before this time are not 677 matched. specifies the latest date and time of interest 678 for event notifications being replayed. If it is not present, then 679 notifications will continue to be sent until the subscription is 680 terminated. 682 Note that and are associated with the time an 683 event was generated by the event source. 685 A notification is sent to indicate that all of the 686 replay notifications have been sent and must not be sent for any 687 other reason. If this subscription has a stop time, then this 688 session becomes a normal NETCONF session again. The NETCONF server 689 will then accept operations even if the server did not 690 previously accept such operations due to lack of interleave support. 691 In the case of a subscription without a stop time, after the 692 notification has been sent, it can be expected that 693 any notifications generated since the start of the subscription 694 creation will be sent, followed by notifications as they arise 695 naturally within the system. 697 The and notifications cannot 698 be filtered out. They will always be sent on a replay subscription 699 that specified a startTime and stopTime respectively. 701 3.4. Notification Management Schema 703 This Schema is used to learn about the event streams supported on the 704 system. It also contains the definition of the and 705 notifications, which are sent to indicate that 706 an event replay has sent all applicable notifications and that the 707 subscription has terminated, respectively. 709 710 718 719 720 A schema that can be used to learn about current 721 event streams. It also contains the replayComplete 722 and notificationComplete notification. 723 724 726 728 730 733 736 738 739 740 741 742 743 The list of event streams supported by the 744 system. When a query is issued, the returned 745 set of streams is determined based on user 746 privileges. 747 748 749 750 751 752 753 754 Stream name, description and other information. 755 756 757 758 759 761 762 763 The name of the event stream. If this is 764 the default NETCONF stream, this must have 765 the value "NETCONF". 766 767 768 769 771 772 773 A description of the event stream, including 774 such information as the type of events that 775 are sent over this stream. 776 777 778 779 781 782 783 An indication of whether or not event replay 784 is available on this stream. 785 786 787 788 790 791 792 The timestamp of the creation of the log 793 used to support the replay function on 794 this stream. 795 Note that this might be earlier then 796 the earliest available 797 notification in the log. This object 798 is updated if the log resets 799 for some reason. This 800 object MUST be present if replay is 801 supported. 802 803 804 805 807 808 809 The timestamp of the last notification 810 aged out of the log. This 811 object MUST be present if replay is 812 supported and any notifications 813 have been aged out of the log. 814 815 816 817 818 819 820 821 822 823 824 826 827 828 829 830 832 835 836 837 This notification is sent to signal the end of a replay 838 portion of a subscription. 839 840 841 843 844 845 846 847 849 852 853 854 This notification is sent to signal the end of a 855 notification subscription. It is sent in the case 856 that stopTime was specified during the creation of 857 the subscription. 858 859 860 862 864 3.5. Subscriptions Data 866 Subscriptions are non-persistent state information and their lifetime 867 is defined by their session or by the parameter. 869 3.6. Filter Mechanics 871 If a filter element is specified to look for data of a particular 872 value, and the data item is not present within a particular event 873 notification for its value to be checked against, the notification 874 will be filtered out. For example, if one were to check for 875 'severity=critical' in a configuration event notification where this 876 field was not supported, then the notification would be filtered out. 878 For subtree filtering, a non-empty node set means that the filter 879 matches. For XPath filtering, the mechanisms defined in [XPATH] 880 should be used to convert the returned value to boolean. 882 3.6.1. Filtering 884 Filtering is explicitly stated when the event notification 885 subscription is created. This is specified via the 'filter' 886 parameter. A Filter only exists as a parameter to the subscription. 888 3.7. Message Flow 889 The following figure depicts message flow between a NETCONF client 890 (C) and NETCONF server (S) in order to create a subscription and 891 begin the flow of notifications. This subscription specified a 892 , so the server starts by replaying logged notifications. 893 It is possible that many rpc/rpc-reply sequences occur before the 894 subscription is created, but this is not depicted in the figure. 896 C S 897 | | 898 | capability exchange | 899 |-------------------------->| 900 |<------------------------->| 901 | | 902 | | (startTime) 903 |-------------------------->| 904 |<--------------------------| 905 | | 906 | | 907 | | 908 |<--------------------------| 909 | | 910 | | 911 |<--------------------------| 912 | | (replayComplete) 913 |<--------------------------| 914 | | 915 | | 916 | | 917 | | 918 |<--------------------------| 919 | | 920 | | 921 | | 922 |<--------------------------| 923 | | 924 | | 926 Figure 3 928 The following figure depicts message flow between a NETCONF client 929 (C) and NETCONF server (S) in order to create a subscription and 930 begin the flow of notifications. This subscription specified a 931 and so it starts by replaying logged 932 notifications and then returns to be a normal command-response 933 NETCONF session after the and 934 notifications are sent and it is available to process requests. 935 It is possible that many rpc/rpc-reply sequences occur before the 936 subscription is created, but this is not depicted in the figure. 938 C S 939 | | 940 | capability exchange | 941 |-------------------------->| 942 |<------------------------->| 943 | | 944 | | (startTime, 945 |-------------------------->| stopTime) 946 |<--------------------------| 947 | | 948 | | 949 | | 950 |<--------------------------| 951 | | 952 | | 953 |<--------------------------| 954 | | (replayComplete) 955 |<--------------------------| 956 | |(notificationComplete) 957 |<--------------------------| 958 | | 959 | | 960 | | 961 | | 962 |-------------------------->| 963 |<--------------------------| 964 | | 965 | | 967 Figure 4 969 4. XML Schema for Event Notifications 971 The following [XML Schema] defines NETCONF Event Notifications. 973 974 983 985 987 988 989 This import accesses the xml: attribute groups for the 990 xml:lang as declared on the error-message element. 991 992 993 995 996 999 1001 1003 1004 1005 1006 1007 1009 1010 1011 An optional parameter that indicates 1012 which stream of events is of interest. If 1013 not present, then events in the default 1014 NETCONF stream will be sent. 1015 1016 1017 1018 1021 1022 1023 An optional parameter that indicates 1024 which subset of all possible events 1025 is of interest. The format of this 1026 parameter is the same as that of the 1027 filter parameter in the NETCONF 1028 protocol operations. If not present, 1029 all events not precluded by other 1030 parameters will be sent. 1031 1032 1033 1034 1036 1037 1038 A parameter used to trigger the replay 1039 feature and indicates that the replay 1040 should start at the time specified. If 1041 start time is not present, this is not a 1042 replay subscription. 1043 1044 1045 1046 1048 1049 1050 An optional parameter used with the 1051 optional replay feature to indicate the 1052 newest notifications of interest. If 1053 stop time is not present, the 1054 notifications will continue until the 1055 subscription is terminated. Must be used 1056 with startTime. 1057 1058 1059 1060 1062 1063 1064 1066 1067 1068 1069 The name of an event stream. 1070 1071 1072 1073 1075 1078 1079 1080 The command to create a notification subscription. It 1081 takes as argument the name of the notification stream 1082 and filter. Both of those options 1083 limit the content of the subscription. In addition, 1084 there are two time-related parameters, startTime and 1085 stopTime, which can be used to select the time interval 1086 of interest to the notification replay feature. 1087 1088 1089 1091 1093 1094 1096 1099 1100 1101 1102 1103 1104 The time the event was generated by the event source 1105 1106 1107 1108 1109 1110 1112 1114 1116 5. Filtering Examples 1118 The following section provides examples to illustrate the various 1119 methods of filtering content on an event notification subscription. 1121 In order to illustrate the use of filter expressions, it is necessary 1122 to assume some of the event notification content. The examples below 1123 assume that the event notification schema definition has an 1124 element at the top level consisting of the event class (e.g., fault, 1125 state, config), reporting entity and either severity or operational 1126 state. 1128 Examples in this section are generated from the following fictional 1129 Schema. 1131 1132 1138 1142 1143 1144 1145 1146 1147 1148 1149 1150 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1164 1168 1170 The above fictional notification definition could result in the 1171 following sample notification list, which is used in the examples in 1172 this section. 1174 1176 2007-07-08T00:01:00Z 1177 1178 fault 1179 1180 Ethernet0 1181 1182 major 1183 1184 1186 1188 2007-07-08T00:02:00Z 1189 1190 fault 1191 1192 Ethernet2 1193 1194 critical 1195 1196 1198 1200 2007-07-08T00:04:00Z 1201 1202 fault 1203 1204 ATM1 1205 1206 minor 1207 1208 1210 1212 2007-07-08T00:10:00Z 1213 1214 state 1215 1216 Ethernet0 1217 1218 enabled 1220 1221 1223 5.1. Subtree Filtering 1225 XML subtree filtering is not well-suited for creating elaborate 1226 filter definitions given that it only supports equality comparisons 1227 and application of the logical OR operators (e.g., in an event 1228 subtree give me all event notifications which have severity=critical 1229 or severity=major or severity=minor). Nevertheless, it may be used 1230 for defining simple event notification forwarding filters as shown 1231 below. 1233 The following example illustrates how to select fault events which 1234 have severities of critical, major, or minor. The filtering criteria 1235 evaluation is as follows: 1237 ((fault & severity=critical) | (fault & severity=major) | (fault & 1238 severity=minor)) 1240 1242 1244 1245 1246 fault 1247 critical 1248 1249 1250 fault 1251 major 1252 1253 1254 fault 1255 minor 1256 1257 1258 1259 1261 The following example illustrates how to select state or config 1262 EventClasses or fault events that are related to card Ethernet0. The 1263 filtering criteria evaluation is as follows: 1265 ( state | config | ( fault & ( card=Ethernet0))) 1267 1269 1271 1272 1273 state 1274 1275 1276 config 1277 1278 1279 fault 1280 1281 Ethernet0 1282 1283 1284 1285 1286 1288 5.2. XPATH filters 1290 The following [XPATH] example illustrates how to select fault 1291 EventClass notifications that have severities of critical, major, or 1292 minor. The filtering criteria evaluation is as follows: 1294 ((fault) & ((severity=critical) | (severity=major) | (severity = 1295 minor))) 1297 1299 1301 1306 1307 1309 The following example illustrates how to select state and config 1310 EventClasses or fault events of any severity that come from card 1311 Ethernet0. The filtering criteria evaluation is as follows: 1313 ( state | config | (fault & card=Ethernet0)) 1315 1317 1319 1324 1325 1327 6. Interleave Capability 1329 6.1. Description 1331 The Interleave capability indicates that the NETCONF peer supports 1332 the ability to interleave other NETCONF operations within a 1333 Notification subscription. This means the NETCONF server MUST 1334 receive, process and respond to NETCONF requests on a session with an 1335 active notification subscription. This capability helps scalability 1336 by reducing the total number of NETCONF sessions required by a given 1337 operator or management application. 1339 6.2. Dependencies 1341 This capability is dependant on the notification capability being 1342 supported. 1344 6.3. Capability Identifier 1346 The :interleave capability is identified by the following capability 1347 string: 1349 urn:ietf:params:netconf:capability:interleave:1.0 1351 6.4. New Operations 1353 None. 1355 6.5. Modifications to Existing Operations 1357 When a is sent while another subscription is 1358 active on that session, the following error will be returned: 1360 Tag: operation-failed 1362 Error-type: protocol 1364 Severity: error 1366 Error-info: none 1368 Description: Request could not be completed because the requested 1369 operation failed for some reason not covered by any other error 1370 condition. 1372 7. Security Considerations 1374 The security considerations from the base [NETCONF] document also 1375 apply to the Notification capability. 1377 The access control framework and the choice of transport will have a 1378 major impact on the security of the solution. 1380 The elements are never sent before the transport layer 1381 and the NETCONF layer, including capabilities exchange, have been 1382 established, and the manager has been identified and authenticated. 1384 It is recommended that care be taken to secure execution: 1386 o invocation 1388 o on read-only data models 1390 o content 1392 Secure execution means ensuring that a secure transport is used as 1393 well as ensuring that the user has sufficient authorization to 1394 perform the function they are requesting against the specific subset 1395 of NETCONF content involved. When a is received that refers to 1396 the content defined in this memo, clients should only be able to view 1397 the content for which they have sufficient privileges. A create 1398 operation can be considered like a deferred 1399 , and the content that different users can access may vary. 1400 This different access is reflected in the that 1401 different users are able to subscribe to. 1403 One potential security issue is the transport of data from non- 1404 NETCONF streams, such as syslog and SNMP. This data may be more 1405 vulnerable (or less vulnerable) when being transported over NETCONF 1406 than when being transported using the protocol normally used for 1407 transporting it, depending on the security credentials of the two 1408 subsystems. The NETCONF server is responsible for applying access 1409 control to stream content. 1411 The contents of notifications as well as the names of event streams 1412 may contain sensitive information and care should be taken to ensure 1413 that they are viewed only by authorized users. If a user is not 1414 authorized to view all elements in the content of the notification, 1415 the notification is not sent to that user. 1417 If a subscription is created with a , the NETCONF session 1418 will return to being a normal command-response NETCONF session when 1419 the replay is completed. It is the responsibility of the NETCONF 1420 client to close this session when it is no longer of use. 1422 8. IANA Considerations 1424 -- Editor note to IANA/RFC-Editor: we request that you make these 1425 assignments, in which case it is to be documented as below 1427 This document registers three URIs for the NETCONF XML namespace in 1428 the IETF XML registry [RFC3688]. 1430 Following the format in RFC 3688, IANA has made the following 1431 registration. Note that the capability urns as also compliant to 1432 [NETCONF] section 10.3. 1434 +--------------------+----------------------------------------------+ 1435 | Index | Capability Identifier | 1436 +--------------------+----------------------------------------------+ 1437 | :notification | urn:ietf:params:netconf:capability: | 1438 | | notification:1.0 | 1439 | | | 1440 | :interleave | urn:ietf:params:netconf:capability: | 1441 | | interleave:1.0 | 1442 +--------------------+----------------------------------------------+ 1444 URI: urn:ietf:params:xml:ns:netmod:notification 1446 URI: urn:ietf:params:xml:ns:netconf:notification:1.0 1448 Registrant Contact: The IESG. 1450 XML: N/A, the requested URI is an XML namespace. 1452 In addition, IANA registered the following XML Schema, the definition 1453 of which can be found in Section 4: 1454 http://www.iana.org/assignments/xml-registry/schema/notification.xsd 1456 9. Acknowledgements 1458 Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing 1459 their input into the early work on this document. In addition, the 1460 editors would like to acknowledge input at the Vancouver editing 1461 session from the following people: Orly Nicklass, James Balestriere, 1462 Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, 1463 Dave Partain, Ray Atarashi and David Perkins and the following 1464 additional people from the Montreal editing session: Balazs Lengyel, 1465 Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, 1466 Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, 1467 Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William 1468 Chow. We would also like to thank Li Yan for his numerous reviews as 1469 well as Suresh Krishnan for his gen-art review of the document. 1471 10. Normative References 1473 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1474 December 2006. 1476 [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements 1477 Levels", RFC 2119, March 1997. 1479 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 1480 Internet: Timestamps", RFC 3339, July 2002. 1482 [RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January 1483 2004. 1485 [XML] World Wide Web Consortium, "Extensible Markup Language 1486 (XML) 1.0", W3C XML, February 1998, 1487 . 1489 [XML Schema] 1490 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1491 "XML Schema Part 1: Structures Second Edition", W3C http:/ 1492 /www.w3.org/TR/2004/REC-xmlschema-1-20041028/ 1493 structures.html, October 2004. 1495 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1496 Version 1.0", 1497 W3C http://www.w3.org/TR/1999/REC-xpath-19991116, 1498 November 1999. 1500 Appendix A. Change Log 1502 -- Editor note to RFC-Editor: we request that you remove this section 1503 before publishing. 1505 A.1. Version -08 1507 1. Removed named profiles 1509 2. Removed eventClass that was accidentally included in the 1510 definition of the replayComplete notification 1512 3. Deleted data wrapper from notification 1514 4. Changed replayLogStartTime to have a minOccurs of 0. It will 1515 only be there when replay is supported. Verify examples in 1516 section 3.2.5.1 are correct with respect to this element. 1518 5. Error codes in section 2.1.1, fixed formatting issue 1520 6. Moved replayComplete to not be under 1522 7. Section 2.1, fixed capitalization 1524 8. In figure 4, the line was pushed out by 'system components', 1525 fixed this. 1527 9. On page 8, replaced "If the startTime specified is earlier then 1528 the" with 'If the startTime specified is earlier than the" 1530 10. Updated some name spaces and schemaLocations as per Andy's June 1531 3rd email. 1533 11. Added discussion of replayLogStartTime to draft in section 3.3.1 1534 as follows "Whether or not a stream supports replay can be 1535 discovered by doing a operation on the elements 1536 of the Notification Management Schema. This schema also 1537 provides the replayLogStartTime element to indicate the earliest 1538 available logged notification." 1540 12. Removed most of the uses of the phrase 'Note that'. I kept two 1541 uses that prevent sentences from starting with either a lower 1542 case letter or an angle bracket. 1544 13. In section 3.6 replaced "it will be filtered out" with "the 1545 notification will be filtered out" 1547 14. In section 3.4, replaced "and the query" with "and to query" 1549 15. Replaced 3 instances of "replay complete notification" with 1550 "replayComplete notification" 1552 16. In section 3.3.2, replaced "normal NETCONF session" with "normal 1553 command-response NETCONF session" 1555 17. In section 3.3.1, replaced "create an event subscription that 1556 will resend recently generated notification" with "create an 1557 event subscription that will resend recently generated 1558 notification, or is some cases send them for the first time to a 1559 particular NETCONF client." 1561 18. In section 3.2.5.2, s/available event streams to/event streams 1562 available to/ 1564 19. In one spot, changed snmp to SNMP (the other gets deleted) 1566 20. In section 3.2.5.1 s/where element is/where the 1567 element is/ 1569 21. In section 3.2.5.1, clarified that "value is unique" - within 1570 the scope of a NETCONF server. 1572 22. In section 2.1.1, clarified that stopTime cannot preceded start 1573 time. 1575 23. In section 2.1.1, in Start Time s/indicates/indicate/ 1577 24. In section 2.1.1, in Filter: s/This is mutually exclusive/The 1578 filter parameter is mutually exclusive/ ("this" could refer to 1579 the behaviour described in the previous sentence.) 1581 25. In section 1.4, third bullet, replaced "syslog and SNMP are 1582 rather constrained in terms of message sizes)" with (ie, not too 1583 short) 1585 26. In section 1.4, made all bullets start with capital letters. 1587 27. Added definition of Filter to section 1.1 1589 28. In section 1.1, improved the definition of subscription with "An 1590 agreement and method to receive event notifications over a 1591 NETCONF session." 1593 29. In section 1.1, in the definition of operation, added a 1594 reference to [NETCONF]. 1596 30. Created a change log section 1598 31. Fixed reference to IETF XML Registry in IANA Considerations 1599 section. 1601 32. In section 3.3.3, deleted "This notification will only be sent 1602 if a 'stopTime' was specified when the replay subscription was 1603 created." 1605 33. Added text to the security considerations section that says "If 1606 a subscription is created with a stopTime, the NETCONF session 1607 will return to being a normal command-response NETCONF session 1608 when the replay is completed. It is the responsibility of the 1609 NETCONF client to close off this session when it is no longer of 1610 use". 1612 34. Update examples in section 5 to get rid of extra wrapper tag. 1614 35. In section 2.1, replace "A NETCONF server is not required to 1615 process RPC requests on the session associated with the 1616 subscription until the notification subscription is done and may 1617 silently discard these requests." with "A NETCONF server is will 1618 not read RPC requests, by default, on the session associated 1619 with the subscription until the notification subscription is 1620 done. 1622 36. Updated the notification definition and the replyComplete 1623 notification definition to use a substitution group. 1625 A.2. Version -09 1627 1. In section 5.1 "logical OR operation" -> "application of the 1628 logical OR operator" 1630 2. In section 6 "ensure the secure operation of the following 1631 commands" -> "secure execution" 1633 3. Removed a couple remaining references to named profiles. 1635 4. Updated name datatype in eventStreams element. 1637 5. Modified the cardinality of eventStreams to reflect that there 1638 will always be at least one event stream. 1640 6. Fixed description of examples to remove reference to eventEntry, 1641 which is no longer part of the actual example. 1643 7. In examples, for consistency changed some references to 1644 reportingElement to be reportingEntity 1646 8. Fixed section 3.2, third paragraph to talk about filter elements 1647 instead of filters. 1649 9. Merge section 3.3.2 and section 3.3.3. Delete the first 1650 paragraph in (old) section 3.3.3 since it both duplicates and 1651 contradicts text in section 3.3.2 1653 10. In section 3.2.5.2.1, added clarification to first paragraph 1654 that "Either subtree or XPATH filtering can be used. " 1656 11. Removed discussion of not allowing the return of stream names 1657 for which the user does not have permissions from the body of 1658 the document to the security considerations section. 1660 12. Fixed typos and did wordsmithing in various parts of the 1661 document. 1663 13. In section 2.1, explicitly stated that a subscription is bound 1664 to a single stream for the lifetime of the subscription. 1666 14. removed single quotes around some instances of stopTime and 1667 startTime for consistency. When appropriate, put between angle 1668 brackets. 1670 15. In section 2.1.1, changed "Error-info: : startTime" 1671 to use bad-element. 1673 16. In section 2.2.1, under the parameter tag, replaced "Contains 1674 notification-specific tagged content." with "Contains 1675 notification-specific tagged content, if any. " 1677 17. Clarified some text in section 3.2, paragraph 3 around sending 1678 of filters from client and the filters later being applied to 1679 the notifications. 1681 18. Fixed target namespace in section 4. 1683 19. Added missing lang and version information to schema in section 1684 3.4 1686 20. Clarified that the examples in section 5 all used the same 1687 example event list. 1689 21. Cleaned up security considerations section. 1691 22. In section 3.4, clarified the definition of replayLogStart time 1692 to be the timestamp of the earliest available notification in 1693 the log used to support the replay function in the description 1694 tag for the object definition. 1696 23. In section 3.3.2, clarified that the time an event was generated 1697 by the system means time an event was generated by the event 1698 source. 1700 24. In section 3.5, deleted discussion about possibly defining 1701 subscriptions in XML Schema. 1703 25. In section 3.6, deleted discussion about filter element 1704 execution order not mattering. 1706 26. Fixed examples in section 5 to add tag and to make 1707 other corrections 1709 27. Added XML Schema definition for examples in section 5 and showed 1710 the event list with wrappers. 1712 28. Added notification 1714 29. Removed support of startTime and stopTime in the future. 1716 30. Replaced replayLogStartTime with replayLogCreationTime and 1717 replayLogAgedTime. 1719 A.3. Version -10 1721 1. Changed the description of stopTime to allow stopTimes in the 1722 future. 1724 2. Added interleave capability 1726 3. Clarified create-subscription error messages. 1728 4. Corrected targetNamespace in Netconf Notification XSD 1730 5. Fixed typos and made minor edits. 1732 A.4. Version -11 1734 1. Fixed namespaces 1736 2. In section 6.5, fixed error message Error-info 1737 3. In section 6.1 clarify that if the interleave capability is 1738 supported, then the server must respond to requests. 1740 A.5. Version -12 1742 1. Add to section 1.3 the clarification "Note that a subscription 1743 cannot be modified once created." 1745 2. In section 2.2.1, in the description of eventTime, added the 1746 following text: "This parameter is of type dateTime." 1748 3. Fixed several typos. 1750 4. Added the following text to the IANA considerations section: "-- 1751 Editor note to IANA/RFC-Editor: we request that you make these 1752 assignments, in which case it is top be documented as below" " 1754 5. Replaced/Updated XML Schema reference to be " [XML Schema] 1755 Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., "XML Schema 1756 Part 1: Structures Second Edition", W3C Recommendation, 28 1757 October 2004 " 1760 6. Add instructions to RFC editor to remove change log before 1761 publication 1763 7. Added IANA registration item for http://www.iana.org/assignments/ 1764 xml-registry/schema/notification.xsd 1766 8. Clarified in the IANA considerations section that the capability 1767 URIs were complaint to RFC4741 section 10.3 1769 A.6. Version -13 1771 1. In section 2.1.1, for both instances and in section 2.2.1, 1772 replaced "This parameter is of type dateTime." With "This 1773 parameter is of type dateTime and compliant to [RFC3339]." 1775 2. In the normative reference section, added the following 1776 reference [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time 1777 on the Internet: Timestamps", RFC 3339, July 2002. 1779 3. In section 2.1.1, for both instances and in section 2.2.1, added 1780 the following after the text \ indicating that the time fields 1781 are dateTime (this covers eventTime, startTime and stopTime). 1782 "Implementations must support time zones." 1784 4. In Section 3.6.1 "parameter. A Filter only exist as a parameter 1785 to the subscription." s/exist/exists/ 1787 5. In Section 7: Replaced second last paragraph with "The contents 1788 of notifications as well as the names of event streams may 1789 contain sensitive information and care should be taken to ensure 1790 that they are viewed only by authorized users. If a user is not 1791 authorized to view all elements in the content of the 1792 notification, the notification is not sent to that user." 1794 6. In section 3.3.2, replaced "The NETCONF server will then accept 1795 operations." With "The NETCONF server will then accept 1796 operations even if the server did not previously accept 1797 such operations due to lack of interleave support." 1799 7. In section 3.3.2, replaced "A notification is 1800 sent to indicate that all of the replay notifications have been 1801 sent. If this subscription has a stop time, then this session 1802 becomes a normal NETCONF session again. When a has 1803 been specified, notification is the last 1804 notification sent on the subscription before it terminates and 1805 the NETCONF session returns to being a normal NETCONF session." 1806 With "A notification is sent to indicate that 1807 all of the replay notifications have been sent. When a 1808 has been specified, 1809 notification is the last notification sent on the subscription 1810 before it terminates and the NETCONF session returns to being a 1811 normal NETCONF session. " 1813 8. In section 3.3.2, replaced, "A notification is 1814 sent to indicate that all of the replay notifications have been 1815 sent." With "A notification is sent to 1816 indicate that all of the replay notifications have been sent and 1817 must not be sent for any other reason." 1819 9. In section 3.3.1, replaced "A notification stream that supports 1820 replay is not expected to have an unlimited supply of saved 1821 notifications available to accommodate any replay request." 1822 With "A notification stream that supports replay is not expected 1823 to have an unlimited supply of saved notifications available to 1824 accommodate any replay request. Clients can query 1825 and to learn about 1826 the availability of notifications for replay." 1828 10. In section 3.2, replaced "Figure 2 illustrates the notification 1829 flow and concepts identified in this document." With "Figure 2 1830 illustrates the notification flow and concepts identified in 1831 this document. It does not mandate and/or preclude an 1832 implementation." 1834 11. In section 6.1, added the following text "This capability helps 1835 scalability by reducing the total number of NETCONF sessions 1836 required by a given operator or management application." 1838 12. In section 3.6, deleted "When multiple filter elements are 1839 specified, they are applied collectively, so event notifications 1840 need to pass all specified filter elements in order to be sent 1841 to the subscriber. " 1843 13. In section 7 (Security Considerations) after the bullets added 1844 the following: Secure execution means ensuring that a secure 1845 transport is used as well as ensuring that the user has 1846 sufficient authorization to perform the function they are 1847 requesting against the specific piece of NETCONF content 1848 involved. When a is received against the content defined 1849 in this memo, clients should only be able to view the content 1850 for which they have sufficient privileges. A create operation can be considered like a deferred , 1852 and the content that different users can access may vary. This 1853 different access is reflected in the that 1854 different users are able to subscribe to. 1856 14. Updated import statements to not used fully qualified URLs. 1858 Authors' Addresses 1860 Sharon Chisholm 1861 Nortel 1862 3500 Carling Ave 1863 Nepean, Ontario K2H 8E9 1864 Canada 1866 Email: schishol@nortel.com 1868 Hector Trevino 1869 Cisco 1870 Suite 400 1871 9155 E. Nichols Ave 1872 Englewood, CO 80112 1873 USA 1875 Email: htrevino@cisco.com 1877 Full Copyright Statement 1879 Copyright (C) The IETF Trust (2008). 1881 This document is subject to the rights, licenses and restrictions 1882 contained in BCP 78, and except as set forth therein, the authors 1883 retain all their rights. 1885 This document and the information contained herein are provided on an 1886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1888 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1889 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1890 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1893 Intellectual Property 1895 The IETF takes no position regarding the validity or scope of any 1896 Intellectual Property Rights or other rights that might be claimed to 1897 pertain to the implementation or use of the technology described in 1898 this document or the extent to which any license under such rights 1899 might or might not be available; nor does it represent that it has 1900 made any independent effort to identify any such rights. Information 1901 on the procedures with respect to rights in RFC documents can be 1902 found in BCP 78 and BCP 79. 1904 Copies of IPR disclosures made to the IETF Secretariat and any 1905 assurances of licenses to be made available, or the result of an 1906 attempt made to obtain a general license or permission for the use of 1907 such proprietary rights by implementers or users of this 1908 specification can be obtained from the IETF on-line IPR repository at 1909 http://www.ietf.org/ipr. 1911 The IETF invites any interested party to bring to its attention any 1912 copyrights, patents or patent applications, or other proprietary 1913 rights that may cover technology that may be required to implement 1914 this standard. Please address the information to the IETF at 1915 ietf-ipr@ietf.org. 1917 Acknowledgment 1919 Funding for the RFC Editor function is provided by the IETF 1920 Administrative Support Activity (IASA).