An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
RFC 4827
Document | Type | RFC - Proposed Standard (May 2007) Errata | |
---|---|---|---|
Authors | Markus Isomaki , Eva Leppanen | ||
Last updated | 2020-01-21 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
IESG | Responsible AD | Ted Hardie | |
Send notices to | (None) |
RFC 4827
I2NSF Working Group S. Hares, Ed. Internet-Draft Huawei Intended status: Standards Track J. Jeong, Ed. Expires: March 12, 2021 J. Kim Sungkyunkwan University R. Moskowitz HTT Consulting Q. Lin Huawei September 8, 2020 I2NSF Capability YANG Data Model draft-ietf-i2nsf-capability-data-model-11 Abstract This document defines a YANG data model for the capabilities of various Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework to centrally manage the capabilities of the various NSFs. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 12, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Hares, et al. Expires March 12, 2021 [Page 1] Internet-Draft I2NSF Capability YANG Data Model September 2020 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Network Security Function (NSF) Capabilities . . . . . . 6 5. YANG Data Model of I2NSF NSF Capability . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 8.1. Normative References . . . . . . . . . . . . . . . . . . 42 8.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Configuration Examples . . . . . . . . . . . . . . . 47 A.1. Example 1: Registration for the Capabilities of a General Firewall . . . . . . . . . . . . . . . . . . . . . . . . 47 A.2. Example 2: Registration for the Capabilities of a Time- based Firewall . . . . . . . . . . . . . . . . . . . . . 49 A.3. Example 3: Registration for the Capabilities of a Web Filter . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.4. Example 4: Registration for the Capabilities of a VoIP/VoLTE Filter . . . . . . . . . . . . . . . . . . . . 51 A.5. Example 5: Registration for the Capabilities of a HTTP and HTTPS Flood Mitigator . . . . . . . . . . . . . . . . 52 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 53 Appendix C. Contributors . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction As the industry becomes more sophisticated and network devices (e.g., Internet of Things, Self-driving vehicles, and smartphone using Voice over IP (VoIP) and Voice over LTE (VoLTE)), service providers have a lot of problems described in [RFC8192]. To resolve these problems, [I-D.ietf-i2nsf-capability] specifies the information model of the capabilities of Network Security Functions (NSFs) in a framework of the Interface to Network Security Functions (I2NSF) [RFC8329]. This document provides a YANG data model [RFC6020][RFC7950] that defines the capabilities of NSFs to centrally manage the capabilities of those security devices. The security devices can register their own capabilities into a Network Operator Management (Mgmt) System Hares, et al. Expires March 12, 2021 [Page 2] Internet-Draft I2NSF Capability YANG Data Model September 2020 (i.e., Security Controller) with this YANG data model through the registration interface [RFC8329]. With the capabilities of those security devices maintained centrally, those security devices can be more easily managed [RFC8329]. This YANG data model is based on the information model for I2NSF NSF capabilities [I-D.ietf-i2nsf-capability]. This YANG data model uses an "Event-Condition-Action" (ECA) policy model that is used as the basis for the design of I2NSF Policy as described in [RFC8329] and [I-D.ietf-i2nsf-capability]. The "ietf- i2nsf-capability" YANG module defined in this document provides the following features: o Definition for general capabilities of network security functions. o Definition for event capabilities of generic network security functions. o Definition for condition capabilities of generic network security functions. o Definition for condition capabilities of advanced network security functions. o Definition for action capabilities of generic network security functions. o Definition for resolution strategy capabilities of generic network security functions. o Definition for default action capabilities of generic network security functions. 2. Terminology This document uses the terminology described in [RFC8329]. This document follows the guidelines of [RFC8407], uses the common YANG types defined in [RFC6991], and adopts the Network Management Datastore Architecture (NMDA). The meaning of the symbols in tree diagrams is defined in [RFC8340]. 3. Overview This section provides as overview of how the YANG data model can be used in the I2NSF framework described in [RFC8329]. Figure 1 shows the capabilities (e.g., firewall and web filter) of NSFs in the I2NSF Framework. As shown in this figure, an NSF Developer's Management gt; SIP NOTIFY | | | (PA) | +-------+-------+ +------------+ ^ ^ ^ | | | | | | +---------------+ +--------+ | +-------| XCAP server | | | +-------+-------+ | | ^ ^ | SIP Publish | | XCAP | | | | | +--+--+ +--+--+ +-------+ +-------+ | PUA | | PUA | | XCAP | | XCAP | | | | | | client| | client| +-----+ +-----+ +-------+ +-------+ Figure 1: Framework for Presence Publishing and Event State Composition The protocol interface between XCAP server and the event state compositor is not specified here. Isomaki & Leppanen Standards Track [Page 5] RFC 4827 XCAP for Manipulating Presence Document May 2007 4. Application Usage ID XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the 'pidf-manipulation' AUID within the IETF tree, via the IANA registration in Section 13. 5. MIME Type The MIME type for this application usage is 'application/pidf+xml'. 6. Structure of Manipulated Presence Information The XML Schema of the presence information is defined in the Presence Information Data Format (PIDF) [3]. The PIDF also defines a mechanism for extending presence information. See [8], [9], [11], and [12] for currently defined PIDF extensions and their XML Schemas. The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf' which is also the XCAP default document namespace. 7. Additional Constraints There are no constraints on the document beyond those described in the XML schemas (PIDF and its extensions) and in the description of PIDF [3]. 8. Resource Interdependencies There are no resource interdependencies beyond the possible interdependencies defined in PIDF [3] and XCAP [2] that need to be defined for this application usage. 9. Naming Conventions The XCAP server MUST store only a single XCAP manipulated presence document for each user. The presence document MUST be located under the "users" tree, using filename "index". See an example in Section 11. 10. Authorization Policies This application usage does not modify the default XCAP authorization policy, which allows only a user (owner) to read, write, or modify their own documents. A server can allow privileged users to modify documents that they do not own, but the establishment and indication of such policies is outside the scope of this document. Isomaki & Leppanen Standards Track [Page 6] RFC 4827 XCAP for Manipulating Presence Document May 2007 11. Example The section provides an example of a presence document provided by an XCAP Client to an XCAP Server. The presence document illustrates the situation where a (human) presentity has left for vacation, and before that, has set his presence information so that he is only available via e-mail. In the absence of any published soft state information, this would be the sole input to the compositor forming the presence document. The example document contains PIDF extensions specified in "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)" [8] and "CIPID: Contact Information in Presence Information Data Format" [9]. It is assumed that the presentity is a SIP user with Address-of- Record (AOR) sip:someone@example.com. The XCAP root URI for example.com is assumed to be http://xcap.example.com. The XCAP User Identifier (XUI) is assumed to be identical to the SIP AOR, according to XCAP recommendations. In this case, the presence document would be located at http://xcap.example.com/pidf-manipulation/users/ sip:someone@example.com/index. The presence document is created with the following XCAP operation: PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1 Host: xcap.example.com Content-Type: application/pidf+xml ... <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid" xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model" xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid" entity="sip:someone@example.com"> <tuple id="x8eg92m"> <status> <basic>closed</basic> </status> <rp:user-input>idle</rp:user-input> <rp:class>auth-1</rp:class> <contact priority="0.5">sip:user@example.com</contact> <note>I'm available only by e-mail.</note> <timestamp>2004-02-06T16:49:29Z</timestamp> </tuple> <tuple id="x8eg92n"> <status> Isomaki & Leppanen Standards Track [Page 7] RFC 4827 XCAP for Manipulating Presence Document May 2007 <basic>open</basic> </status> <rp:class>auth-1</rp:class> <contact priority="1.0">mailto:someone@example.com</contact> <note>I'm reading mail a couple of times a week</note> </tuple> <dm:person id="p1"> <rp:class>auth-A</rp:class> <ci:homepage>http://www.example.com/~someone</ci:homepage> <rp:activities> <rp:vacation/> </rp:activities> </dm:person> </presence> When the user wants to change the note related to e-mail service, it is done with the following XCAP operation: PUT /pidf-manipulation/users/sip:someone@example.com/index/ ~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1 If-Match: "xyz" Host: xcap.example.com Content-Type: application/xcap-el+xml ... <note>I'm reading mails on Tuesdays and Fridays</note> 12. Security Considerations A presence document may contain information that is highly sensitive. Its delivery to watchers needs to happen strictly according to the relevant authorization policies. It is also important that only authorized clients are able to manipulate the presence information. The XCAP base specification mandates that all XCAP servers MUST implement HTTP Digest authentication specified in RFC 2617 [5]. Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is recommended that administrators of XCAP servers use an HTTPS URI as the XCAP root services' URI, so that the digest client authentication occurs over TLS. By using these means, XCAP client and server can ensure the confidentiality and integrity of the XCAP presence document manipulation operations, and that only authorized clients are allowed to perform them. Isomaki & Leppanen Standards Track [Page 8] RFC 4827 XCAP for Manipulating Presence Document May 2007 13. IANA Considerations There is an IANA consideration associated with this specification. 13.1. XCAP Application Usage ID This section registers a new XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2]. Name of the AUID: pidf-manipulation Description: Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF-based presence documents. 14. Acknowledgements The authors would like to thank Jari Urpalainen, Jonathan Rosenberg, Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for their comments. 15. References 15.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004. [4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [5] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 15.2. Informative References [7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004. Isomaki & Leppanen Standards Track [Page 9] RFC 4827 XCAP for Manipulating Presence Document May 2007 [8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006. [9] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006. [10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006. [11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, July 2006. [12] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006. Authors' Addresses Markus Isomaki Nokia P.O. BOX 100 00045 NOKIA GROUP Finland EMail: markus.isomaki@nokia.com Eva Leppanen Nokia P.O. BOX 785 33101 Tampere Finland EMail: eva-maria.leppanen@nokia.com Isomaki & Leppanen Standards Track [Page 10]Hares, et al. Expires March 12, 2021 [Page 3] Internet-Draft I2NSF Capability YANG Data Model September 2020 System can register NSFs and the capabilities that the network security device can support. To register NSFs in this way, the Developer's Management System utilizes this standardized capability YANG data model through the I2NSF Registration Interface [RFC8329]. That is, this Registration Interface uses the YANG module described in this document to describe the capability of a network security function that is registered with the Security Controller. With the capabilities of those network security devices maintained centrally, those security devices can be more easily managed, which can resolve many of the problems described in [RFC8192]. In Figure 1, a new NSF at a Developer's Management Systems has capabilities of Firewall (FW) and Web Filter (WF), which are denoted as (Cap = {FW, WF}), to support Event-Condition-Action (ECA) policy rules where 'E', 'C', and 'A' mean "Event", "Condition", and "Action", respectively. The condition involves IPv4 or IPv6 datagrams, and the action includes "Allow" and "Deny" for those datagrams. Note that the NSF-Facing Interface [RFC8329] is used to configure the security policy rules of the generic network security functions, and The configuration of advanced security functions over the NSF-Facing Interface is used to configure the security policy rules of advanced network security functions (e.g., anti-virus and Distributed-Denial- of-Service (DDoS) attack mitigator), respectively, according to the capabilities of NSFs registered with the I2NSF Framework. Hares, et al. Expires March 12, 2021 [Page 4] Internet-Draft I2NSF Capability YANG Data Model September 2020 +------------------------------------------------------+ | I2NSF User (e.g., Overlay Network Mgmt, Enterprise | | Network Mgmt, another network domain's mgmt, etc.) | +--------------------+---------------------------------+ I2NSF ^ Consumer-Facing Interface | | v I2NSF +-----------------+------------+ Registration +-------------+ | Network Operator Mgmt System | Interface | Developer's | | (i.e., Security Controller) |<-------------->| Mgmt System | +-----------------+------------+ +-------------+ ^ New NSF | Cap = {FW, WF} I2NSF | E = {} NSF-Facing Interface | C = {IPv4, IPv6} | A = {Allow, Deny} v +---------------+----+------------+-----------------+ | | | | +---+---+ +---+---+ +---+---+ +---+---+ | NSF-1 | ... | NSF-m | | NSF-1 | ... | NSF-n | ... +-------+ +-------+ +-------+ +-------+ NSF-1 NSF-m NSF-1 NSF-n Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} Cap = {FW, WF} E = {} E = {user} E = {dev} E = {time} C = {IPv4} C = {IPv6} C = {IPv4, IPv6} C = {IPv4} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} A = {Allow, Deny} Developer's Mgmt System A Developer's Mgmt System B Figure 1: Capabilities of NSFs in I2NSF Framework A use case of an NSF with the capabilities of firewall and web filter is described as follows. o If a network manager wants to apply security policy rules to block malicious users with firewall and web filter, it is a tremendous burden for a network administrator to apply all of the needed rules to NSFs one by one. This problem can be resolved by managing the capabilities of NSFs in this document. o If a network administrator wants to block malicious users for IPv6 traffic, he sends a security policy rule to block the users to the Network Operator Management System using the I2NSF User (i.e., web application). Hares, et al. Expires March 12, 2021 [Page 5] Internet-Draft I2NSF Capability YANG Data Model September 2020 o When the Network Operator Management System receives the security policy rule, it automatically sends that security policy rules to appropriate NSFs (i.e., NSF-m in Developer's Management System A and NSF-1 in Developer's Management System B) which can support the capabilities (i.e., IPv6). This lets an I2NSF User not consider NSFs where the rule is applied. o If NSFs encounter the suspicious IPv6 packets of malicious users, they can filter the packets out according to the configured security policy rule. Therefore, the security policy rule against the malicious users' packets can be automatically applied to appropriate NSFs without human intervention. 4. YANG Tree Diagram This section shows a YANG tree diagram of capabilities of network security functions, as defined in the [I-D.ietf-i2nsf-capability]. 4.1. Network Security Function (NSF) Capabilities This section explains a YANG tree diagram of NSF capabilities and its features. Figure 2 shows a YANG tree diagram of NSF capabilities. The NSF capabilities in the tree include time capabilities, event capabilities, condition capabilities, action capabilities, resolution strategy capabilities, and default action capabilities. Those capabilities can be tailored or extended according to a vendor's specific requirements. Refer to the NSF capabilities information model for detailed discussion [I-D.ietf-i2nsf-capability]. Hares, et al. Expires March 12, 2021 [Page 6] Internet-Draft I2NSF Capability YANG Data Model September 2020 module: ietf-i2nsf-capability +--rw nsf* [nsf-name] +--rw nsf-name string +--rw time-capabilities* enumeration +--rw event-capabilities | +--rw system-event-capability* identityref | +--rw system-alarm-capability* identityref +--rw condition-capabilities | +--rw generic-nsf-capabilities | | +--rw ipv4-capability* identityref | | +--rw icmp-capability* identityref | | +--rw ipv6-capability* identityref | | +--rw icmpv6-capability* identityref | | +--rw tcp-capability* identityref | | +--rw udp-capability* identityref | +--rw advanced-nsf-capabilities | | +--rw anti-virus-capability* identityref | | +--rw anti-ddos-capability* identityref | | +--rw ips-capability* identityref | | +--rw url-capability* identityref | | +--rw voip-volte-capability* identityref | +--rw context-capabilities* identityref +--rw action-capabilities | +--rw ingress-action-capability* identityref | +--rw egress-action-capability* identityref | +--rw log-action-capability* identityref +--rw resolution-strategy-capabilities* identityref +--rw default-action-capabilities* identityref +--rw ipsec-method* identityref Figure 2: YANG Tree Diagram of Capabilities of Network Security Functions Time capabilities are used to specify the capabilities which describe when to execute the I2NSF policy rule. The time capabilities are defined in terms of absolute time and periodic time. The absolute time means the exact time to start or end. The periodic time means repeated time like day, week, or month. See Section 3.4.6 (Capability Algebra) in [I-D.ietf-i2nsf-capability] for more information about the time-based condition (e.g., time period) in the capability algebra. Event capabilities are used to specify the capabilities that describe the event that would trigger the evaluation of the condition clause of the I2NSF Policy Rule. The defined event capabilities are system event and system alarm. See Section 3.1 (Design Principles and ECA Hares, et al. Expires March 12, 2021 [Page 7] Internet-Draft I2NSF Capability YANG Data Model September 2020 Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more information about the event in the ECA policy model. Condition capabilities are used to specify capabilities of a set of attributes, features, and/or values that are to be compared with a set of known attributes, features, and/or values in order to determine whether or not the set of actions in that (imperative) I2NSF policy rule can be executed. The condition capabilities are classified in terms of generic network security functions and advanced network security functions. The condition capabilities of generic network security functions are defined as IPv4 capability, IPv6 capability, TCP capability, UDP capability, and ICMP capability. The condition capabilities of advanced network security functions are defined as anti-virus capability, anti-DDoS capability, Intrusion Prevention System (IPS) capability, HTTP capability, and VoIP/VoLTE capability. See Section 3.1 (Design Principles and ECA Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more information about the condition in the ECA policy model. Also, see Section 3.4.3 (I2NSF Condition Clause Operator Types) in [I-D.ietf-i2nsf-capability] for more information about the operator types in an I2NSF condition clause. Action capabilities are used to specify the capabilities that describe the control and monitoring aspects of flow-based NSFs when the event and condition clauses are satisfied. The action capabilities are defined as ingress-action capability, egress-action capability, and log-action capability. See Section 3.1 (Design Principles and ECA Policy Model Overview) in [I-D.ietf-i2nsf-capability] for more information about the action in the ECA policy model. Also, see Section 7.2 (NSF-Facing Flow Security Policy Structure) in [RFC8329] for more information about the ingress and egress actions. In addition, see Section 9.1 (Flow- Based NSF Capability Characterization) for more information about logging at NSFs. Resolution strategy capabilities are used to specify the capabilities that describe conflicts that occur between the actions of the same or different policy rules that are matched and contained in this particular NSF. The resolution strategy capabilities are defined as First Matching Rule (FMR), Last Matching Rule (LMR), Prioritized Matching Rule (PMR), Prioritized Matching Rule with Errors (PMRE), and Prioritized Matching Rule with No Errors (PMRN). See Section 3.4.2 (Conflict, Resolution Strategy and Default Action) in [I-D.ietf-i2nsf-capability] for more information about the resolution strategy. Default action capabilities are used to specify the capabilities that describe how to execute I2NSF policy rules when no rule matches a RFC 4827 XCAP for Manipulating Presence Document May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Isomaki & Leppanen Standards Track [Page 11]