idnits 2.17.1 draft-ietf-netconf-notification-12.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 1789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1813. 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 574 has weird spacing: '...netconf xmlns...' == Line 715 has weird spacing: '...omplete notif...' == Line 728 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 (February 25, 2008) is 5903 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: August 28, 2008 Cisco 6 February 25, 2008 8 NETCONF Event Notifications 9 draft-ietf-netconf-notification-12.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 August 28, 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 . . . . . . . . . . . . . . . . . . . . 32 81 5.2. XPATH filters . . . . . . . . . . . . . . . . . . . . . . 33 82 6. Interleave Capability . . . . . . . . . . . . . . . . . . . . 35 83 6.1. Description . . . . . . . . . . . . . . . . . . . . . . . 35 84 6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 35 85 6.3. Capability Identifier . . . . . . . . . . . . . . . . . . 35 86 6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 35 87 6.5. Modifications to Existing Operations . . . . . . . . . . . 35 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 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. Vesrion -12 . . . . . . . . . . . . . . . . . . . . . . . 45 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 99 Intellectual Property and Copyright Statements . . . . . . . . . . 47 101 1. Introduction 103 [NETCONF] can be conceptually partitioned into four layers: 105 Layer Example 106 +-------------+ +-------------------------------------------+ 107 | Content | | Configuration data | 108 +-------------+ +-------------------------------------------+ 109 | | 110 +-------------+ +-------------------------------------------+ 111 | Operations | | , | 112 +-------------+ +-------------------------------------------+ 113 | | | 114 +-------------+ +-----------------------------+ | 115 | RPC | | , | | 116 +-------------+ +-----------------------------+ | 117 | | | 118 +-------------+ +-------------------------------------------+ 119 | Transport | | BEEP, SSH, SSL, console | 120 | Protocol | | | 121 +-------------+ +-------------------------------------------+ 123 Figure 1 125 This document defines mechanisms which provide an asynchronous 126 message notification delivery service for the [NETCONF] protocol. 127 This is an optional capability built on top of the base NETCONF 128 definition. This memo defines the capabilities and operations 129 necessary to support this service. 131 1.1. Definition of Terms 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 Element: An [XML] Element. 139 Subscription: An agreement and method to receive event notifications 140 over a NETCONF session. A concept related to the delivery of 141 notifications (if there are any to send) involving destination and 142 selection of notifications. It is bound to the lifetime of a 143 session. 145 Operation: This term is used to refer to NETCONF protocol operations 146 [NETCONF]. Within this document, operation refers to NETCONF 147 protocol operations defined in support of NETCONF notifications. 149 Event: An event is something that happens which may be of interest - 150 a configuration change, a fault, a change in status, crossing a 151 threshold, or an external input to the system, for example. Often 152 this results in an asynchronous message, sometimes referred to as 153 a notification or event notification, being sent to interested 154 parties to notify them that this event has occurred. 156 Replay: The ability to send/re-send previously logged notifications 157 upon request. These notifications are sent asynchronously. This 158 feature is implemented by the NETCONF server and invoked by the 159 NETCONF client. 161 Stream: An event stream is a set of event notifications matching 162 some forwarding criteria and available to NETCONF clients for 163 subscription. 165 Filter: A parameter that indicates which subset of all possible 166 events are of interest. A filter is defined as one or more filter 167 element [NETCONF], which each identifies a portion of the overall 168 filter. 170 1.2. Motivation 172 The motivation for this work is to enable the sending of asynchronous 173 messages that are consistent with the data model (content) and 174 security model used within a NETCONF implementation. 176 The scope of the work aims meeting the following operational needs: 178 o Initial release should ensure it supports notifications in support 179 of configuration operations. 181 o It should be possible to use the same data model for notifications 182 as for configuration operations. 184 o Solution should support a reasonable message size limit (i.e., not 185 too short) 187 o The notifications should be carried over a connection-oriented 188 delivery mechanism. 190 o A subscription mechanism for notifications should be provided. 191 This takes into account that a NETCONF server does not send 192 notifications before being asked to do so and that it is the 193 NETCONF client who initiates the flow of notifications. 195 o A filtering mechanism for sending notifications should be put in 196 place within the NETCONF server. 198 o The information contained in a notification should be sufficient 199 so that it can be analyzed independent of the transport mechanism. 200 In other words the data content fully describes a notification; 201 protocol information is not needed to understand a notification. 203 o The server should have the capability to replay locally logged 204 notifications. 206 1.3. Event Notifications in NETCONF 208 This memo defines a mechanism whereby the NETCONF client indicates 209 interest in receiving event notifications from a NETCONF server by 210 creating a subscription to receive event notifications. The NETCONF 211 server replies to indicate whether the subscription request was 212 successful and, if it was successful, begins sending the event 213 notifications to the NETCONF client as the events occur within the 214 system. These event notifications will continue to be sent until 215 either the NETCONF session is terminated or the subscription 216 terminates for some other reason. The event notification 217 subscription allows a number of options to enable the NETCONF client 218 to specify which events are of interest. These are specified when 219 the subscription is created. Note that a subscription cannot be 220 modified once created. 222 The NETCONF server MUST accept and process the 223 operation, even while the notification subscription is active. The 224 NETCONF server MAY accept and process other commands, otherwise they 225 will be rejected and the server MUST send a 'resource-denied' error. 226 A NETCONF server advertises support of the ability to process other 227 commands via the interleave capability. 229 2. Notification-Related Operations 231 2.1. Subscribing to Receive Event Notifications 233 The event notification subscription is initiated by the NETCONF 234 client and responded to by the NETCONF server. A subscription is 235 bound to a single stream for the lifetime of the subscription. When 236 the event notification subscription is created, the events of 237 interest are specified. 239 Content for an event notification subscription can be selected by 240 applying user-specified filters. 242 2.1.1. 244 Description: 246 This operation initiates an event notification subscription which 247 will send asynchronous event notifications to the initiator of the 248 command until the subscription terminates. 250 Parameters: 252 Stream: 254 An optional parameter, , that indicates which stream of 255 events is of interest. If not present, events in the default 256 NETCONF stream will be sent. 258 Filter: 260 An optional parameter, , that indicates which subset of 261 all possible events is of interest. The format of this 262 parameter is the same as that of the filter parameter in the 263 NETCONF protocol operations. If not present, all events not 264 precluded by other parameters will be sent. See section 3.6 265 for more information on filters. 267 Start Time: 269 A parameter, , used to trigger the replay feature 270 and indicate that the replay should start at the time 271 specified. If is not present, this is not a replay 272 subscription. It is not valid to specify start times that are 273 later than the current time. If the specified is 274 earlier than the log can support, the replay will begin with 275 the earliest available notification. This parameter is of type 276 dateTime. 278 Stop Time: 280 An optional parameter, , used with the optional 281 replay feature to indicate the newest notifications of 282 interest. If stop time is not present, the notifications will 283 continue until the subscription is terminated. Must be used 284 with and be later than . Values of in 285 the future are valid. This parameter is of type dateTime. 287 Positive Response: 289 If the NETCONF server can satisfy the request, the server sends an 290 element. 292 Negative Response: 294 An element is included within the if the 295 request cannot be completed for any reason. Subscription requests 296 will fail if a filter with invalid syntax is provided or if the 297 name of a non-existent stream is provided. 299 If a is specified in a request without having specified 300 a , the following error is returned: 302 Tag: missing-element 304 Error-type: protocol 306 Severity: error 308 Error-info: : startTime 310 Description: An expected element is missing. 312 If the optional replay feature is requested but it is not 313 supported by the NETCONF server, the following error is returned: 315 Tag: operation-failed 317 Error-type: protocol 319 Severity: error 321 Error-info: none 322 Description: Request could not be completed because the 323 requested operation failed for some reason not covered by any 324 other error condition 326 If a is requested which is earlier then the specified 327 , the following error is returned: 329 Tag: bad-element 331 Error-type: protocol 333 Severity: error 335 Error-info: : stopTime 337 Description: An element value is not correct; e.g., wrong type, 338 out of range, pattern mismatch. 340 If a is requested which is later then the current 341 time, the following error is returned: 343 Tag: bad-element 345 Error-type: protocol 347 Severity: error 349 Error-info: : startTime 351 Description: An element value is not correct; e.g., wrong type, 352 out of range, pattern mismatch. 354 2.1.1.1. Usage Example 356 The following demonstrates creating a simple subscription. More 357 complex examples can be found in section 5. 359 361 363 364 366 2.2. Sending Event Notifications 368 Once the subscription has been set up, the NETCONF server sends the 369 event notifications asynchronously over the connection. 371 2.2.1. 373 Description: 375 An event notification is sent to the client who initiated a 376 command asynchronously when an event of 377 interest (i.e., meeting the specified filtering criteria) has 378 occurred. An event notification is a complete and well-formed XML 379 document. Note that is not an RPC method but 380 rather the top level element identifying the one-way message as a 381 notification. 383 Parameters: 385 eventTime 387 The time the event was generated by the event source. This 388 parameter is of type dateTime. 390 Also contains notification-specific tagged content, if any. With 391 the exception of , the content of the notification is 392 beyond the scope of this document. 394 Response: 396 No response. Not applicable. 398 2.3. Terminating the Subscription 400 Closing of the event notification subscription can be done by using 401 the operation from the subscriptions session or 402 terminating the NETCONF session ( ) or the underlying 403 transport session from another session. If a stop time is provided 404 when the subscription is created, the subscription will terminate 405 after the stop time is reached. In this case, the NETCONF session 406 will still be an active session. 408 3. Supporting Concepts 410 3.1. Capabilities Exchange 412 The ability to process and send event notifications is advertised 413 during the capability exchange between the NETCONF client and server. 415 3.1.1. Capability Identifier 417 "urn:ietf:params:netconf:capability:notification:1.0" 419 3.1.2. Capability Example 421 422 423 424 urn:ietf:params:xml:ns:netconf:base:1.0 425 426 427 urn:ietf:params:netconf:capability:startup:1.0 428 429 430 urn:ietf:params:netconf:capability:notification:1.0 431 432 433 4 434 436 3.2. Event Streams 438 An event stream is defined as a set of event notifications matching 439 some forwarding criteria. 441 Figure 2 illustrates the notification flow and concepts identified in 442 this document. The following is observed from the diagram below: 443 System components (c1..cn) generate event notifications which are 444 passed to a central component for classification and distribution. 445 The central component inspects each event notification and matches 446 the event notification against the set of stream definitions. When a 447 match occurs, the event notification is considered to be a member of 448 that event stream (stream 1..stream n). An event notification may be 449 part of multiple event streams. 451 At some point after the NETCONF server receives the internal event 452 from a stream, it is converted to an appropriate XML encoding by the 453 server, and a element is ready to send to all NETCONF 454 sessions subscribed to that stream. 456 After generation of the element, access control is 457 applied by the server. If a session does not have permission to 458 receive the , then it is discarded for that session, 459 and processing of the internal event is completed for that session. 461 When a NETCONF client subscribes to a given event stream, user- 462 defined filter elements, if applicable, are applied to the event 463 stream and matching event notifications are forwarded to the NETCONF 464 server for distribution to subscribed NETCONF clients. A filter is 465 transferred from the client to the server during the operation and applied against each 467 element generated by the stream. For more information on filtering, 468 see section 3.6. 470 A notification logging service may also be available, in which case, 471 the central component logs notifications. The NETCONF server may 472 later retrieve logged notifications via the optional replay feature. 473 For more information on replay, see section 3.3. 475 +----+ 476 | c1 |----+ available streams 477 +----+ | +---------+ 478 +----+ | |central |-> stream 1 479 | c2 | +--->|event |-> stream 2 filter +-------+ 480 +----+ | |processor|-> NETCONF stream ----->|NETCONF| 481 ... | | |-> stream n |server | 482 System | +---------+ +-------+ 483 Components| | /\ 484 ... | | || 485 +----+ | | (------------) || 486 | cn |----+ | (notification) || 487 +----+ +-----> ( logging ) || 488 ( service ) || 489 (------------) || 490 || 491 || 492 \/ 493 +-------+ 494 |NETCONF| 495 |client | 496 +-------+ 498 Figure 2 500 3.2.1. Event Stream Definition 502 Event streams are predefined on the managed device. The 503 configuration of event streams is outside the scope of this document. 504 However, it is envisioned that event streams are either pre- 505 established by the vendor (pre-configured), user configurable (e.g., 506 part of the device's configuration) or both. Device vendors may 507 allow event stream configuration via the NETCONF protocol (i.e., 508 operation). 510 3.2.2. Event Stream Content Format 512 The contents of all event streams made available to a NETCONF client 513 (i.e., the notification sent by the NETCONF server) MUST be encoded 514 in XML. 516 3.2.3. Default Event Stream 518 A NETCONF server implementation supporting the notification 519 capability MUST support the "NETCONF" notification event stream. 520 This stream contains all NETCONF XML event notifications supported by 521 the NETCONF server. The exact string "NETCONF" is used during 522 advertisement of stream support during the operation on 523 and during the operation. Definition 524 of the event notifications and their contents, beyond the inclusion 525 of , for this event stream is outside the scope of this 526 document. 528 3.2.4. Event Stream Sources 530 With the exception of the default event stream (NETCONF), 531 specification of additional event stream sources (e.g., SNMP, syslog) 532 is outside the scope of this document. NETCONF server 533 implementations may leverage any desired event stream source in the 534 creation of supported event streams. 536 3.2.5. Event Stream Discovery 538 A NETCONF client retrieves the list of supported event streams from a 539 NETCONF server using the operation. 541 3.2.5.1. Name Retrieval using operation 543 The list of available event streams is retrieved by requesting the 544 subtree via a operation. Available event streams for 545 the requesting session are returned in the reply containing the 546 and elements, where the element is 547 mandatory, and its value is unique within the scope of a NETCONF 548 server. An empty reply is returned if there are no available event 549 streams, due to user-specified filters on the operation . 551 Additional information available about a stream include whether 552 notification replay is available and if so, the timestamp of the 553 earliest possible notification to replay. 555 The following example shows retrieving the list of available event 556 stream list using the operation. 558 560 561 562 563 564 565 566 567 568 The NETCONF server returns a list of event streams available for 569 subscription: NETCONF, SNMP, and syslog-critical in this example. 571 573 574 575 576 577 NETCONF 578 default NETCONF event stream 579 580 true 581 582 2007-07-08T00:00:00Z 583 584 585 586 SNMP 587 SNMP notifications 588 false 589 590 591 syslog-critical 592 Critical and higher severity 593 594 true 595 596 2007-07-01T00:00:00Z 597 598 599 600 601 602 604 3.2.5.2. Event Stream Subscription 606 A NETCONF client may request from the NETCONF server the list of 607 event streams available to this session and then issue a request with the desired event stream name. Omitting 609 the event stream name from the request results 610 in subscription to the default NETCONF event stream. 612 3.2.5.2.1. Filtering Event Stream Contents 614 The set of event notifications delivered in an event stream may be 615 further refined by applying a user-specified filter supplied at 616 subscription creation time ( ). This is a 617 transient filter associated with the event notification subscription 618 and does not modify the event stream configuration. The filter 619 element is applied against the contents of the wrapper 620 and not the wrapper itself. See section 5 for examples. Either 621 subtree or XPATH filtering can be used. 623 XPATH support for the Notification capability is advertised as part 624 of the normal XPATH capability advertisement. If XPATH support is 625 advertised via the XPATH capability then XPATH is supported for 626 notification filtering and if this capability is not advertised, 627 XPATH is not supported for notification filtering. 629 3.3. Notification Replay 631 3.3.1. Overview 633 Replay is the ability to create an event subscription that will 634 resend recently generated notifications, or in some cases send them 635 for the first time to a particular NETCONF client. These 636 notifications are sent the same way as normal notifications. 638 A replay of notifications is specified by including the optional 639 parameter to the subscription command, which indicates 640 the start time of the replay. The end time is specified using the 641 optional parameter. If not present, notifications will 642 continue to be sent until the subscription is terminated. 644 A notification stream that supports replay is not expected to have an 645 unlimited supply of saved notifications available to accommodate any 646 replay request. 648 The actual number of stored notifications available for retrieval at 649 any given time is a NETCONF server implementation specific matter. 650 Control parameters for this aspect of the feature are outside the 651 scope of this document. 653 Replay is dependent on a notification stream supporting some form of 654 notification logging, although it puts no restrictions on the size or 655 form of the log, or where it resides within the device. Whether or 656 not a stream supports replay can be discovered by doing a 657 operation on the element of the Notification Management 658 Schema and looking at the value of the object. This 659 schema also provides the element to indicate 660 the earliest available logged notification. 662 3.3.2. Creating a Subscription with Replay 664 This feature uses optional parameters to the 665 command called and . identifies the 666 earliest date and time of interest for event notifications being 667 replayed and also indicates that a subscription will be providing 668 replay of notifications. Events generated before this time are not 669 matched. specifies the latest date and time of interest 670 for event notifications being replayed. If it is not present, then 671 notifications will continue to be sent until the subscription is 672 terminated. 674 Note that and are associated with the time an 675 event was generated by the event source. 677 A notification is sent to indicate that all of the 678 replay notifications have been sent. If this subscription has a stop 679 time, then this session becomes a normal NETCONF session again. When 680 a has been specified, notification 681 is the last notification sent on the subscription before it 682 terminates and the NETCONF session returns to being a normal NETCONF 683 session. The NETCONF server will then accept operations. In 684 the case of a subscription without a stop time, after the 685 notification has been sent, it can be expected that 686 any notifications generated since the start of the subscription 687 creation will be sent, followed by notifications as they arise 688 naturally within the system. 690 The and notifications cannot 691 be filtered out. They will always be sent on a replay subscription 692 that specified a startTime and stopTime respectively. 694 3.4. Notification Management Schema 696 This Schema is used to learn about the event streams supported on the 697 system. It also contains the definition of the and 698 notifications, which are sent to indicate that 699 an event replay has sent all applicable notifications and that the 700 subscription has terminated, respectively. 702 703 711 712 713 A schema that can be used to learn about current 714 event streams. It also contains the replayComplete 715 and notificationComplete notification. 716 717 719 721 724 728 731 733 734 735 736 737 738 The list of event streams supported by the 739 system. When a query is issued, the returned 740 set of streams is determined based on user 741 privileges. 742 743 744 745 746 747 748 749 Stream name, description and other information. 750 751 752 753 754 756 757 758 The name of the event stream. If this is 759 the default NETCONF stream, this must have 760 the value "NETCONF". 761 762 763 764 766 767 768 A description of the event stream, including 769 such information as the type of events that 770 are sent over this stream. 771 772 773 774 776 777 778 An indication of whether or not event replay 779 is available on this stream. 780 781 782 783 785 786 787 The timestamp of the creation of the log 788 used to support the replay function on 789 this stream. 790 Note that this might be earlier then 791 the earliest available 792 notification in the log. This object 793 is updated if the log resets 794 for some reason. This 795 object MUST be present if replay is 796 supported. 797 798 799 800 803 804 805 The timestamp of the last notification 806 aged out of the log. This 807 object MUST be present if replay is 808 supported and any notifications 809 have been aged out of the log. 810 811 812 813 814 815 816 817 818 819 820 822 823 824 825 826 828 831 832 833 This notification is sent to signal the end of a replay 834 portion of a subscription. 835 836 837 839 840 841 842 843 845 848 849 850 This notification is sent to signal the end of a 851 notification subscription. It is sent in the case 852 that stopTime was specified during the creation of 853 the subscription. 854 855 856 858 860 3.5. Subscriptions Data 862 Subscriptions are non-persistent state information and their lifetime 863 is defined by their session or by the parameter. 865 3.6. Filter Mechanics 867 When multiple filter elements are specified, they are applied 868 collectively, so event notifications need to pass all specified 869 filter elements in order to be sent to the subscriber. If a filter 870 element is specified to look for data of a particular value, and the 871 data item is not present within a particular event notification for 872 its value to be checked against, the notification will be filtered 873 out. For example, if one were to check for 'severity=critical' in a 874 configuration event notification where this field was not supported, 875 then the notification would be filtered out. 877 For subtree filtering, a non-empty node set means that the filter 878 matches. For XPath filtering, the mechanisms defined in [XPATH] 879 should be used to convert the returned value to boolean. 881 3.6.1. Filtering 883 Filtering is explicitly stated when the event notification 884 subscription is created. This is specified via the 'filter' 885 parameter. A Filter only exist as a parameter to the subscription. 887 3.7. Message Flow 888 The following figure depicts message flow between a NETCONF client 889 (C) and NETCONF server (S) in order to create a subscription and 890 begin the flow of notifications. This subscription specified a 891 , so the server starts by replaying logged notifications. 892 It is possible that many rpc/rpc-reply sequences occur before the 893 subscription is created, but this is not depicted in the figure. 895 C S 896 | | 897 | capability exchange | 898 |-------------------------->| 899 |<------------------------->| 900 | | 901 | | (startTime) 902 |-------------------------->| 903 |<--------------------------| 904 | | 905 | | 906 | | 907 |<--------------------------| 908 | | 909 | | 910 |<--------------------------| 911 | | (replayComplete) 912 |<--------------------------| 913 | | 914 | | 915 | | 916 | | 917 |<--------------------------| 918 | | 919 | | 920 | | 921 |<--------------------------| 922 | | 923 | | 925 Figure 3 927 The following figure depicts message flow between a NETCONF client 928 (C) and NETCONF server (S) in order to create a subscription and 929 begin the flow of notifications. This subscription specified a 930 and so it starts by replaying logged 931 notifications and then returns to be a normal command-response 932 NETCONF session after the and 933 notifications are sent and it is available to process requests. 934 It is possible that many rpc/rpc-reply sequences occur before the 935 subscription is created, but this is not depicted in the figure. 937 C S 938 | | 939 | capability exchange | 940 |-------------------------->| 941 |<------------------------->| 942 | | 943 | | (startTime, 944 |-------------------------->| stopTime) 945 |<--------------------------| 946 | | 947 | | 948 | | 949 |<--------------------------| 950 | | 951 | | 952 |<--------------------------| 953 | | (replayComplete) 954 |<--------------------------| 955 | |(notificationComplete) 956 |<--------------------------| 957 | | 958 | | 959 | | 960 | | 961 |-------------------------->| 962 |<--------------------------| 963 | | 964 | | 966 Figure 4 968 4. XML Schema for Event Notifications 970 The following [XML Schema] defines NETCONF Event Notifications. 972 973 982 984 986 987 988 This import accesses the xml: attribute groups for the 989 xml:lang as declared on the error-message element. 990 991 992 994 995 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 1061 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 1108 1109 1110 1111 1113 1115 1117 5. Filtering Examples 1119 The following section provides examples to illustrate the various 1120 methods of filtering content on an event notification subscription. 1122 In order to illustrate the use of filter expressions, it is necessary 1123 to assume some of the event notification content. The examples below 1124 assume that the event notification schema definition has an 1125 element at the top level consisting of the event class (e.g., fault, 1126 state, config), reporting entity and either severity or operational 1127 state. 1129 Examples in this section are generated from the following fictional 1130 Schema. 1132 1133 1139 1144 1145 1146 1147 1148 1149 1150 1151 1152 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1166 1170 1172 The above fictional notification definition could result in the 1173 following sample notification list, which is used in the examples in 1174 this section. 1176 1178 2007-07-08T00:01:00Z 1179 1180 fault 1181 1182 Ethernet0 1183 1184 major 1185 1186 1188 1190 2007-07-08T00:02:00Z 1191 1192 fault 1193 1194 Ethernet2 1195 1196 critical 1197 1198 1200 1202 2007-07-08T00:04:00Z 1203 1204 fault 1205 1206 ATM1 1207 1208 minor 1209 1210 1212 1214 2007-07-08T00:10:00Z 1215 1216 state 1217 1218 Ethernet0 1219 1220 enabled 1221 1222 1224 5.1. Subtree Filtering 1226 XML subtree filtering is not well-suited for creating elaborate 1227 filter definitions given that it only supports equality comparisons 1228 and application of the logical OR operators (e.g., in an event 1229 subtree give me all event notifications which have severity=critical 1230 or severity=major or severity=minor). Nevertheless, it may be used 1231 for defining simple event notification forwarding filters as shown 1232 below. 1234 The following example illustrates how to select fault events which 1235 have severities of critical, major, or minor. The filtering criteria 1236 evaluation is as follows: 1238 ((fault & severity=critical) | (fault & severity=major) | (fault & 1239 severity=minor)) 1241 1243 1245 1246 1247 fault 1248 critical 1249 1250 1251 fault 1252 major 1253 1254 1255 fault 1256 minor 1257 1258 1259 1260 1262 The following example illustrates how to select state or config 1263 EventClasses or fault events that are related to card Ethernet0. The 1264 filtering criteria evaluation is as follows: 1266 ( state | config | ( fault & ( card=Ethernet0))) 1268 1270 1272 1273 1274 state 1275 1276 1277 config 1278 1279 1280 fault 1281 1282 Ethernet0 1283 1284 1285 1286 1287 1289 5.2. XPATH filters 1291 The following [XPATH] example illustrates how to select fault 1292 EventClass notifications that have severities of critical, major, or 1293 minor. The filtering criteria evaluation is as follows: 1295 ((fault) & ((severity=critical) | (severity=major) | (severity = 1296 minor))) 1298 1300 1302 1307 1308 1310 The following example illustrates how to select state and config 1311 EventClasses or fault events of any severity that come from card 1312 Ethernet0. The filtering criteria evaluation is as follows: 1314 ( state | config | (fault & card=Ethernet0)) 1316 1318 1320 1325 1326 1328 6. Interleave Capability 1330 6.1. Description 1332 The Interleave capability indicates that the NETCONF peer supports 1333 the ability to interleave other NETCONF operations within a 1334 Notification subscription. This means the NETCONF server MUST 1335 receive, process and respond to NETCONF requests on a session with an 1336 active notification subscription. 1338 6.2. Dependencies 1340 This capability is dependant on the notification capability being 1341 supported. 1343 6.3. Capability Identifier 1345 The :interleave capability is identified by the following capability 1346 string: 1348 urn:ietf:params:netconf:capability:interleave:1.0 1350 6.4. New Operations 1352 None. 1354 6.5. Modifications to Existing Operations 1356 When a is sent while another subscription is 1357 active on that session, the following error will be returned: 1359 Tag: operation-failed 1361 Error-type: protocol 1363 Severity: error 1365 Error-info: none 1367 Description: Request could not be completed because the requested 1368 operation failed for some reason not covered by any other error 1369 condition. 1371 7. Security Considerations 1373 The security considerations from the base [NETCONF] document also 1374 apply to the Notification capability. 1376 The access control framework and the choice of transport will have a 1377 major impact on the security of the solution. 1379 The elements are never sent before the transport layer 1380 and the NETCONF layer, including capabilities exchange, have been 1381 established, and the manager has been identified and authenticated. 1383 It is recommended that care be taken to secure execution: 1385 o invocation 1387 o on read-only data models 1389 o content 1391 One potential security issue is the transport of data from non- 1392 NETCONF streams, such as syslog and SNMP. This data may be more 1393 vulnerable (or less vulnerable) when being transported over NETCONF 1394 than when being transported using the protocol normally used for 1395 transporting it, depending on the security credentials of the two 1396 subsystems. The NETCONF server is responsible for applying access 1397 control to stream content. 1399 The contents of notifications as well as the name of event streams 1400 may contain sensitive information and care should be taken to ensure 1401 that it is viewed only by authorized users. If a user does not have 1402 permission to view content via other NETCONF operations, it must not 1403 have access that content via Notifications. If a user is not 1404 permitted to view one element in the content of the notification, the 1405 notification is not sent to that user. 1407 If a subscription is created with a , the NETCONF session 1408 will return to being a normal command-response NETCONF session when 1409 the replay is completed. It is the responsibility of the NETCONF 1410 client to close this session when it is no longer of use. 1412 8. IANA Considerations 1414 -- Editor note to IANA/RFC-Editor: we request that you make these 1415 assignments, in which case it is to be documented as below 1417 This document registers three URIs for the NETCONF XML namespace in 1418 the IETF XML registry [RFC3688]. 1420 Following the format in RFC 3688, IANA has made the following 1421 registration. Note that the capability urns as also compliant to 1422 [NETCONF] section 10.3. 1424 +--------------------+----------------------------------------------+ 1425 | Index | Capability Identifier | 1426 +--------------------+----------------------------------------------+ 1427 | :notification | urn:ietf:params:netconf:capability: | 1428 | | notification:1.0 | 1429 | | | 1430 | :interleave | urn:ietf:params:netconf:capability: | 1431 | | interleave:1.0 | 1432 +--------------------+----------------------------------------------+ 1434 URI: urn:ietf:params:xml:ns:netmod:notification 1436 URI: urn:ietf:params:xml:ns:netconf:notification:1.0 1438 Registrant Contact: The IESG. 1440 XML: N/A, the requested URI is an XML namespace. 1442 In addition, IANA registered the following XML Schema, the definition 1443 of which can be found in Section 4: 1444 http://www.iana.org/assignments/xml-registry/schema/notification.xsd 1446 9. Acknowledgements 1448 Thanks to Gilbert Gagnon, Greg Wilbur and Kim Curran for providing 1449 their input into the early work on this document. In addition, the 1450 editors would like to acknowledge input at the Vancouver editing 1451 session from the following people: Orly Nicklass, James Balestriere, 1452 Yoshifumi Atarashi, Glenn Waters, Alexander Clemm, Dave Harrington, 1453 Dave Partain, Ray Atarashi and David Perkins and the following 1454 additional people from the Montreal editing session: Balazs Lengyel, 1455 Phil Shafer, Rob Enns, Andy Bierman, Dan Romascanu, Bert Wijnen, 1456 Simon Leinen, Juergen Schoenwaelder, Hideki Okita, Vincent Cridlig, 1457 Martin Bjorklund, Olivier Festor, Radu State, Brian Trammell, William 1458 Chow. We would also like to thank Li Yan for his numerous reviews as 1459 well as Suresh Krishnan for his gen-art review of the document. 1461 10. Normative References 1463 [NETCONF] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 1464 December 2006. 1466 [RFC2119] Bradner, s., "Key words for RFCs to Indicate Requirements 1467 Levels", RFC 2119, March 1997. 1469 [RFC3688] Bradner, s., "The IETF XML Registry", RFC 3688, January 1470 2004. 1472 [XML] World Wide Web Consortium, "Extensible Markup Language 1473 (XML) 1.0", W3C XML, February 1998, 1474 . 1476 [XML Schema] 1477 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1478 "XML Schema Part 1: Structures Second Edition", W3C http:/ 1479 /www.w3.org/TR/2004/REC-xmlschema-1-20041028/ 1480 structures.html, October 2004. 1482 [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) 1483 Version 1.0", 1484 W3C http://www.w3.org/TR/1999/REC-xpath-19991116, 1485 November 1999. 1487 Appendix A. Change Log 1489 -- Editor note to RFC-Editor: we request that you remove this section 1490 before publishing. 1492 A.1. Version -08 1494 1. Removed named profiles 1496 2. Removed eventClass that was accidentally included in the 1497 definition of the replayComplete notification 1499 3. Deleted data wrapper from notification 1501 4. Changed replayLogStartTime to have a minOccurs of 0. It will 1502 only be there when replay is supported. Verify examples in 1503 section 3.2.5.1 are correct with respect to this element. 1505 5. Error codes in section 2.1.1, fixed formatting issue 1507 6. Moved replayComplete to not be under 1509 7. Section 2.1, fixed capitalization 1511 8. In figure 4, the line was pushed out by 'system components', 1512 fixed this. 1514 9. On page 8, replaced "If the startTime specified is earlier then 1515 the" with 'If the startTime specified is earlier than the" 1517 10. Updated some name spaces and schemaLocations as per Andy's June 1518 3rd email. 1520 11. Added discussion of replayLogStartTime to draft in section 3.3.1 1521 as follows "Whether or not a stream supports replay can be 1522 discovered by doing a operation on the elements 1523 of the Notification Management Schema. This schema also 1524 provides the replayLogStartTime element to indicate the earliest 1525 available logged notification." 1527 12. Removed most of the uses of the phrase 'Note that'. I kept two 1528 uses that prevent sentences from starting with either a lower 1529 case letter or an angle bracket. 1531 13. In section 3.6 replaced "it will be filtered out" with "the 1532 notification will be filtered out" 1534 14. In section 3.4, replaced "and the query" with "and to query" 1536 15. Replaced 3 instances of "replay complete notification" with 1537 "replayComplete notification" 1539 16. In section 3.3.2, replaced "normal NETCONF session" with "normal 1540 command-response NETCONF session" 1542 17. In section 3.3.1, replaced "create an event subscription that 1543 will resend recently generated notification" with "create an 1544 event subscription that will resend recently generated 1545 notification, or is some cases send them for the first time to a 1546 particular NETCONF client." 1548 18. In section 3.2.5.2, s/available event streams to/event streams 1549 available to/ 1551 19. In one spot, changed snmp to SNMP (the other gets deleted) 1553 20. In section 3.2.5.1 s/where element is/where the 1554 element is/ 1556 21. In section 3.2.5.1, clarified that "value is unique" - within 1557 the scope of a NETCONF server. 1559 22. In section 2.1.1, clarified that stopTime cannot preceded start 1560 time. 1562 23. In section 2.1.1, in Start Time s/indicates/indicate/ 1564 24. In section 2.1.1, in Filter: s/This is mutually exclusive/The 1565 filter parameter is mutually exclusive/ ("this" could refer to 1566 the behaviour described in the previous sentence.) 1568 25. In section 1.4, third bullet, replaced "syslog and SNMP are 1569 rather constrained in terms of message sizes)" with (ie, not too 1570 short) 1572 26. In section 1.4, made all bullets start with capital letters. 1574 27. Added definition of Filter to section 1.1 1576 28. In section 1.1, improved the definition of subscription with "An 1577 agreement and method to receive event notifications over a 1578 NETCONF session." 1580 29. In section 1.1, in the definition of operation, added a 1581 reference to [NETCONF]. 1583 30. Created a change log section 1585 31. Fixed reference to IETF XML Registry in IANA Considerations 1586 section. 1588 32. In section 3.3.3, deleted "This notification will only be sent 1589 if a 'stopTime' was specified when the replay subscription was 1590 created." 1592 33. Added text to the security considerations section that says "If 1593 a subscription is created with a stopTime, the NETCONF session 1594 will return to being a normal command-response NETCONF session 1595 when the replay is completed. It is the responsibility of the 1596 NETCONF client to close off this session when it is no longer of 1597 use". 1599 34. Update examples in section 5 to get rid of extra wrapper tag. 1601 35. In section 2.1, replace "A NETCONF server is not required to 1602 process RPC requests on the session associated with the 1603 subscription until the notification subscription is done and may 1604 silently discard these requests." with "A NETCONF server is will 1605 not read RPC requests, by default, on the session associated 1606 with the subscription until the notification subscription is 1607 done. 1609 36. Updated the notification definition and the replyComplete 1610 notification definition to use a substitution group. 1612 A.2. Version -09 1614 1. In section 5.1 "logical OR operation" -> "application of the 1615 logical OR operator" 1617 2. In section 6 "ensure the secure operation of the following 1618 commands" -> "secure execution" 1620 3. Removed a couple remaining references to named profiles. 1622 4. Updated name datatype in eventStreams element. 1624 5. Modified the cardinality of eventStreams to reflect that there 1625 will always be at least one event stream. 1627 6. Fixed description of examples to remove reference to eventEntry, 1628 which is no longer part of the actual example. 1630 7. In examples, for consistency changed some references to 1631 reportingElement to be reportingEntity 1633 8. Fixed section 3.2, third paragraph to talk about filter elements 1634 instead of filters. 1636 9. Merge section 3.3.2 and section 3.3.3. Delete the first 1637 paragraph in (old) section 3.3.3 since it both duplicates and 1638 contradicts text in section 3.3.2 1640 10. In section 3.2.5.2.1, added clarification to first paragraph 1641 that "Either subtree or XPATH filtering can be used. " 1643 11. Removed discussion of not allowing the return of stream names 1644 for which the user does not have permissions from the body of 1645 the document to the security considerations section. 1647 12. Fixed typos and did wordsmithing in various parts of the 1648 document. 1650 13. In section 2.1, explicitly stated that a subscription is bound 1651 to a single stream for the lifetime of the subscription. 1653 14. removed single quotes around some instances of stopTime and 1654 startTime for consistency. When appropriate, put between angle 1655 brackets. 1657 15. In section 2.1.1, changed "Error-info: : startTime" 1658 to use bad-element. 1660 16. In section 2.2.1, under the parameter tag, replaced "Contains 1661 notification-specific tagged content." with "Contains 1662 notification-specific tagged content, if any. " 1664 17. Clarified some text in section 3.2, paragraph 3 around sending 1665 of filters from client and the filters later being applied to 1666 the notifications. 1668 18. Fixed target namespace in section 4. 1670 19. Added missing lang and version information to schema in section 1671 3.4 1673 20. Clarified that the examples in section 5 all used the same 1674 example event list. 1676 21. Cleaned up security considerations section. 1678 22. In section 3.4, clarified the definition of replayLogStart time 1679 to be the timestamp of the earliest available notification in 1680 the log used to support the replay function in the description 1681 tag for the object definition. 1683 23. In section 3.3.2, clarified that the time an event was generated 1684 by the system means time an event was generated by the event 1685 source. 1687 24. In section 3.5, deleted discussion about possibly defining 1688 subscriptions in XML Schema. 1690 25. In section 3.6, deleted discussion about filter element 1691 execution order not mattering. 1693 26. Fixed examples in section 5 to add tag and to make 1694 other corrections 1696 27. Added XML Schema definition for examples in section 5 and showed 1697 the event list with wrappers. 1699 28. Added notification 1701 29. Removed support of startTime and stopTime in the future. 1703 30. Replaced replayLogStartTime with replayLogCreationTime and 1704 replayLogAgedTime. 1706 A.3. Version -10 1708 1. Changed the description of stopTime to allow stopTimes in the 1709 future. 1711 2. Added interleave capability 1713 3. Clarified create-subscription error messages. 1715 4. Corrected targetNamespace in Netconf Notification XSD 1717 5. Fixed typos and made minor edits. 1719 A.4. Version -11 1721 1. Fixed namespaces 1723 2. In section 6.5, fixed error message Error-info 1724 3. In section 6.1 clarify that if the interleave capability is 1725 supported, then the server must respond to requests. 1727 A.5. Vesrion -12 1729 1. Add to section 1.3 the clarification "Note that a subscription 1730 cannot be modified once created." 1732 2. In section 2.2.1, in the description of eventTime, added the 1733 following text: "This parameter is of type dateTime." 1735 3. Fixed several typos. 1737 4. Added the following text to the IANA considerations section: "-- 1738 Editor note to IANA/RFC-Editor: we request that you make these 1739 assignments, in which case it is top be documented as below" " 1741 5. Replaced/Updated XML Schema reference to be " [XML Schema] 1742 Thompson, H., Beech, D., Maloney, M., Mendelsohn, N., "XML Schema 1743 Part 1: Structures Second Edition", W3C Recommendation, 28 1744 October 2004 " 1747 6. Add instructions to RFC editor to remove change log before 1748 publication 1750 7. Added IANA registration item for http://www.iana.org/assignments/ 1751 xml-registry/schema/notification.xsd 1753 8. Clarified in the IANA considerations section that the capability 1754 URIs were complaint to RFC4741 section 10.3 1756 Authors' Addresses 1758 Sharon Chisholm 1759 Nortel 1760 3500 Carling Ave 1761 Nepean, Ontario K2H 8E9 1762 Canada 1764 Email: schishol@nortel.com 1766 Hector Trevino 1767 Cisco 1768 Suite 400 1769 9155 E. Nichols Ave 1770 Englewood, CO 80112 1771 USA 1773 Email: htrevino@cisco.com 1775 Full Copyright Statement 1777 Copyright (C) The IETF Trust (2008). 1779 This document is subject to the rights, licenses and restrictions 1780 contained in BCP 78, and except as set forth therein, the authors 1781 retain all their rights. 1783 This document and the information contained herein are provided on an 1784 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1785 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1786 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1787 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1788 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1789 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1791 Intellectual Property 1793 The IETF takes no position regarding the validity or scope of any 1794 Intellectual Property Rights or other rights that might be claimed to 1795 pertain to the implementation or use of the technology described in 1796 this document or the extent to which any license under such rights 1797 might or might not be available; nor does it represent that it has 1798 made any independent effort to identify any such rights. Information 1799 on the procedures with respect to rights in RFC documents can be 1800 found in BCP 78 and BCP 79. 1802 Copies of IPR disclosures made to the IETF Secretariat and any 1803 assurances of licenses to be made available, or the result of an 1804 attempt made to obtain a general license or permission for the use of 1805 such proprietary rights by implementers or users of this 1806 specification can be obtained from the IETF on-line IPR repository at 1807 http://www.ietf.org/ipr. 1809 The IETF invites any interested party to bring to its attention any 1810 copyrights, patents or patent applications, or other proprietary 1811 rights that may cover technology that may be required to implement 1812 this standard. Please address the information to the IETF at 1813 ietf-ipr@ietf.org. 1815 Acknowledgment 1817 Funding for the RFC Editor function is provided by the IETF 1818 Administrative Support Activity (IASA).