Network Working Group V. Marinov Internet-Draft J. Schoenwaelder Intended status: Standards Track Jacobs University Bremen Expires: August 30, 2007 February 26, 2007 Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages draft-marinov-syslog-snmp-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 30, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This memo defines a mapping from Simple Network Management Protocol (SNMP) notifications to SYSLOG notifications. Marinov & Schoenwaelder Expires August 30, 2007 [Page 1] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. SNMP Notifications . . . . . . . . . . . . . . . . . . . . 3 2.2. SYSLOG Notifications . . . . . . . . . . . . . . . . . . . 5 3. Mapping SNMP Notifications to SYSLOG Notifications . . . . . . 5 3.1. SYSLOG Header . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Structured Data . . . . . . . . . . . . . . . . . . . . . 7 3.3. MSG Data . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Marinov & Schoenwaelder Expires August 30, 2007 [Page 2] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 1. Introduction SNMP and SYSLOG are two widely used protocols to communicate event notifications. Although co-existence of several management protocols in one operational environment is possible, certain environments require that all event notifications are collected by a single system daemon such as a SYSLOG collector or an SNMP notification receiver via a single management protocol. In such environments, it is necessary to translate event notifications between management protocols. The latest version of SYSLOG, specified in [I-D.ietf-syslog-protocol], supports a structured data element format. Structured data elements allow us tto map between SNMP notifications and SYSLOG messages without losing information. In this memo we specify a concrete mapping from SNMP event notifications [RFC3416] into SYSLOG messages [I-D.ietf-syslog-protocol]. We specify how the SYSLOG message format should be utilized to carry the information contained in an SNMP notification message. A new SYSLOG structured data element is defined which carries the PDU portion of an SNMP notification message. 1.1. Conventions A system which has the capability of receiving SNMP notification messages from an SNMP Notification Originator and sending the SNMP data contained inside in a SYSLOG message format to a SYSLOG receiver is referred in this memo as an "snmp-to-syslog translator". By definition, such a system should have an SNMP Notification Receiver application and a SYSLOG sender application running in order to be able to perform the functions of an "snmp-to-syslog translator". The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Background 2.1. SNMP Notifications A detailed introduction to the SNMP Management Framework can be found in [RFC3410]. The SNMP Management Architecture is described in [RFC3411]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB [RFC3418]. Objects in the MIB are defined using the mechanisms defined in the SMI [RFC2578]. Marinov & Schoenwaelder Expires August 30, 2007 [Page 3] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 An SNMP notification message is generated and transmitted by an SNMP entity on behalf of a Notification Originator application [RFC3413]. SNMP notifications are often used to notify a Notification Receiver application at a logically remote SNMP entity that an event has occurred or that a certain condition is present. There are two types of SNMP protocol operations that are associated with SNMP notification messages [RFC3416]: o SNMPv2-Trap-PDU, an unconfirmed notification delivery mechanisms o InformRequest-PDU, a confirmed notification delivery mechanism The scopedPDU portion of an SNMPv3 trap or inform message has the following format [RFC3412]: ScopedPDU ::= SEQUENCE { contextEngineID OCTET STRING, contextName OCTET STRING, data ANY -- e.g., PDUs as defined in [RFC3416] } The data member of the SEQUENCE ScopedPDU carries a SNMPv2-Trap-PDU or an InformRequest-PDU. They both have the same structure: PDUs ::= [7] IMPLICIT SEQUENCE { request-id INTEGER, error-status INTEGER, -- ignored in notifications error-index INTEGER, -- ignored in notifications variable-bindings VarBindList } -- variable binding VarBind ::= SEQUENCE { name ObjectName, CHOICE { value ObjectSyntax, unSpecified NULL, -- in retrieval requests -- exceptions in responses noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, endOfMibView [2] IMPLICIT NULL } } -- variable-binding list VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind Marinov & Schoenwaelder Expires August 30, 2007 [Page 4] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 The first two variable bindings in the variable binding list of an SNMPv2-Trap-PDU or InformRequest-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] respectively. If the OBJECTS clause is present in the invocation of the corresponding NOTIFICATION-TYPE macro, then each corresponding variable, as instantiated by this notification, is copied, in order, to the variable-bindings field. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field. In the case of SNMPv1 or SNMPv2c notifications, the contextEngineID and the contextName parameters are not present in notification messages. In general, we assume that notifications from an SNMP version preceding SNMPv3 are mapped into the notification format used by SNMPv3 according to the coexistance rules defined in RFC 3584 [RFC3584]. 2.2. SYSLOG Notifications The SYSLOG protocol is defined in [I-D.ietf-syslog-protocol]. The message contains a global header and a number of structured data elements. The ABNF [RFC4234] representation of a SYSLOG message is defined in RFC XXXX [I-D.ietf-syslog-protocol]. The relevant productions for structured data elements are: STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 SD-ID = SD-NAME PARAM-NAME = SD-NAME PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and ; ']' MUST be escaped. SD-NAME = 1*32PRINTUSASCII ; except '=', SP, ']', %d34 (") UTF-8-STRING = *OCTET ; Any VALID UTF-8 String ; "shortest form" MUST be used OCTET = %d00-255 SP = %d32 PRINTUSASCII = %d33-126 NILVALUE = "-" 3. Mapping SNMP Notifications to SYSLOG Notifications In this section, we define how the scopedPDU portion from a SNMP notification message is used to generate a message in the SYSLOG Marinov & Schoenwaelder Expires August 30, 2007 [Page 5] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 format. The notification receiver application at the snmp-to-syslog translator is listening for incoming notifications. After a notification is received by the SNMP engine the data portion is forwarded to the notification receiver application. The data portion contains the scopedPDU portion of the message which is used by the SYSLOG sender on the snmp-to-syslog translator to generate a SYSLOG notification and send it to a SYSLOG receiver. A common scenario is the following: +-------------------+ snmp +------------+ | |notification |snmp | +---------+ syslog | +-------------+ |-------------|notification| |syslog |notification| |syslog sender| | |originator | |collector|------------| +-------------+ | +------------+ | | | +------------+ | snmp +------------+ | | | |snmp | |notification |snmp | +---------+ | |notification| |-------------|notification| | |receiver | | |originator | | +------------+ | +------------+ | snmp-to-syslog |snmp +------------+ | translator |notification |snmp | | |-------------|notification| +-------------------+ |originator | +------------+ There can be many SNMP notification originators which send SNMP event notifications to a snmp-to-syslog translator. The snmp-to-syslog translator extracts the data portion of the notification, generates a SYSLOG message, and send the SYSLOG message to a SYSLOG collector, which is responsible for collecting and storing all notification messages. The snmp-to-syslog translator is not transparent for a SYSLOG receiver. The global header of the SYSLOG message generated by the snmp-to-syslog translator is filled with parameters that are specific for the system running the snmp-to-syslog translator such as its hostname, time stamp, etc. The data portion (scopedPDU for SNMPv3 or PDU for SNMPv1/SNMPv2c) of the SNMP notification message is contained in the structured data of the SYSLOG message. 3.1. SYSLOG Header The snmp-to-syslog translator fills the HEADER field of a SYSLOG message with parameters specific to the system on which it is running. The default facility level for SYSLOG messages containing SNMP notifications should be 3, which corresponds to messages Marinov & Schoenwaelder Expires August 30, 2007 [Page 6] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 generated by system daemons. The default severity level should be 5, which correponds to "Notice: normal but significant condition". If the snmp-to-syslog translator has a notion of the type of notification that has been received it might choose other values for facility and severity level. The VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID and MSGID fields in the SYSLOG message header are filled with values that are specific to the system on which the snmp-to-syslog translator is running. The character set used in the HEADER MUST be seven-bit ASCII in an eight- bit field as described in [I-D.ietf-syslog-protocol]. 3.2. Structured Data The STRUCTURED-DATA field of a SYSLOG message will contain the ScopedPDU (or PDU) portion of the SNMP notification message. For the purpose of carrying SNMP notification data, a new SD-ID element is defined. The ABNF [RFC4234] representation of the new structured element is: Marinov & Schoenwaelder Expires August 30, 2007 [Page 7] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 SNMP-SD-ELEMENT = "[" SNMP-SD-ID [CTX] REQID SYSUPTIME TRAP *VARBIND "]" SNMP-SD-ID = %x73.6E.6D.70 ; snmp CTX = CTXENGINE CTXNAME CTXENGINE = SP "ctxEngine=" %d34 HEXSTRING %d34 CTXNAME = SP "ctxName=" %d34 HEXSTRING %d34 REQID = SP "reqid=" %d34 INTEGER32 %d34 SYSUPTIME = SP "sysUpTime=" %d34 UNSIGNED32 %d34 TRAP = SP "snmpTrapOID=" %d34 OID %d34 VARBIND = SP NAME SP VALUE NAME = VALOID VALUE = VALOID / VALSTRING / VALCOUNTER32 / VALCOUNTER64 / VALUNSIGNED32 / VALINTEGER32 / VALIP / VALNULL / VALOPAQUE / VALTIMETICKS VALOID = "o=" %d34 OID %d34 VALSTRING = "s=" %d34 HEXSTRING %d34 VALCOUNTER32 = "c=" %d34 UNSIGNED32 %d34 VALCOUNTER64 = "C=" %d34 UNSIGNED64 %d34 VALUNSIGNED32 = "u=" %d34 UNSIGNED32 %d34 VALINTEGER32 = "d=" %d34 INTEGER32 %d34 VALIP = "i=" %d34 IPV4ADDRESS %d34 VALNULL = "n=" %d34 NULL %d34 VALOPAQUE = "p=" %d34 HEXSTRING %d34 VALTIMETICKS = "t=" %d34 UNSIGNED32 %d34 OID = 1*DIGIT "." 1*DIGIT *("." 1*DIGIT) HEXSTRING = *HEX INTEGER32 = ["-"] NONZERODIGIT 0*DIGIT UNSIGNED32 = NONZERODIGIT 0*DIGIT UNSIGNED64 = NONZERODIGIT 0*DIGIT NULL = "" IPV4ADDRESS = d8 "." d8 "." d8 "." d8 d8 = DIGIT ; 0-9 / %d49-57 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %d48-52 DIGIT ; 200-249 / "25" %d48-53 ; 250-255 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f NONZERODIGIT = %d49-57 DIGIT = %d48 / NONZERODIGIT SP = %d32 Each SNMP-SD-ELEMENT starts with a SD-ID="snmp". The first three PARAM-NAME elements are "ctxEngine", "ctxName" and "reqid". They must be present in an SNMPv3 notification and therefore they must be present in a SYSLOG message generated by an snmp-to-syslog Marinov & Schoenwaelder Expires August 30, 2007 [Page 8] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 translator. The contexdEngineID is encoded as as hexadecimal string, the contextName is encoded as a hexadecimal string, and the requestID is encoded as a signed decimal number. Two special varbind elements are encoded next as an unsigned 32-bit number (sysUpTime) and an OBJECT IDENTIFIER value in dotted notation (snmpTrapOID). [DISCUSS: Why do we keep the requestid? We do not keep the PDU type (inform / trap) - so why is the requestid relevant?] [DISCUSS: Does it really make sense to special case the first two varbinds sysUpTime and snmpTrapOID? The value of the later one is hardly readable for humans anyways.] The remaining parameters correspond to the remaining varbind list elements. The name of a varbind is encoded as an OID in dotted notation and the values are encoded according to the following rules: o OBJECT IDENTIFIER - denoted by a PARAM-NAME = "o" and encoded in a dotted-decimal notation o OCTET STRING - denoted by PARAM-NAME = "s" and encoded as a hexadecimal string o Counter32 - denoted by PARAM-NAME ="c" and encoded as an unsigned decimal number o Counter64 - denoted by PARAM-NAME ="C" and encoded as an unsigned decimal number o Unsigned32 - denoted by PARAM-NAME ="u" and encoded as a decimal number o INTEGER, Integer32 - denoted by PARAM-NAME = "d" and encoded as a signed decimal number o IpAddress - denoted by PARAM-NAME = "i" and encoded in a quad- decimal notation o OPAQUE - denoted by PARAM-NAME = "p" and encoded as a hexadecimal string o Timeticks - denoted by PARAM-NAME = "t" and encoded as a decimal number o NULL - denoted by PARAM-NAME = "n" and encoded as an empty string The syslog message generated by the snmp-to-syslog translator may include other structured data elements in its structured part in addition to the SNMP-SD-ELEMENT. These structured data elements are included in the syslog message by the syslog sender at the snmp-to- syslog translator and must be compliant to the specification in [I-D.ietf-syslog-protocol] . 3.3. MSG Data The MSG part of the syslog message is optional and may contain a free-form message that provides a textual description of the SNMP Marinov & Schoenwaelder Expires August 30, 2007 [Page 9] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 event notification. The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 as specified in [RFC3629]. If the sender can not encode the MSG in Unicode, it MAY use any other encoding. 4. Usage Example Here we provide an example how an SNMP linkUp trap message is mapped into a syslog message by using the mappings defined in Section 3.1 and Section 3.2 The linkUp notification is defined in [RFC2863] linkUp NOTIFICATION-TYPE OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } STATUS current DESCRIPTION "A linkUp trap signifies that the SNMP entity, acting in an agent role, has detected that the ifOperStatus object for one of its communication links left the down state and transitioned into some other state (but not into the notPresent state). This other state is indicated by the included value of ifOperStatus." ::= { snmpTraps 4 } The scopedPDU portion of an SNMP linkUp trap sent using the SNMPv3 message format is show below (left columns shows the BER encoding while the right column indicates the corresponding ASN.1 definitions): [TODO: The encoding below should show a scopedPDU, but right now it shows only a PDU.] Marinov & Schoenwaelder Expires August 30, 2007 [Page 10] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 A7:6A SNMPv2-Trap-PDU { 02:03:6D:08:67 INTEGER 7145575 02:01:00 INTEGER 0 02:01:00 INTEGER 0 30:5D SEQUENCE OF { 30:0F SEQUENCE { 06:08:2B:06:01:02:01:01:03:00 sysUpTime.0 43:03:01:72:8C 94860 } 30:17 SEQUENCE { 06:0A:2B:06:01:06:03:01:01:04:01:00 snmpTrapOID.0 06:09:2B:06:01:06:03:01:01:05:04 linkUp } 30:0F SEQUENCE { 06:0A:2B:06:01:02:01:02:02:01:01:03 ifIndex.3 02:01:03 3 } 30:0F SEQUENCE { 06:0A:2B:06:01:02:01:02:02:01:07:03 ifAdminStatus.3 02:01:01 up(1) } 30:0F SEQUENCE { 06:0A:2B:06:01:02:01:02:02:01:08:03 ifOperStatus.3 02:01:01 up(1) } } } The corresponding SYSLOG message generated by the snmp-to-syslog translator is shown below. (SYSLOG examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes only.) <29>1 2003-10-11T22:14:15.003Z mymachine.example.com snmptrapd - ID47 [snmp ctxEngine="123456" ctxName="ctx1" reqid="7145575" sysUpTime="94860" snmpTrapOID="1.3.6.1.6.3.1.1.5.4" o="1.3.6.1.2.1.2.2.1.1.3" d="3" o="1.3.6.1.2.1.2.2.1.7.3" d="1" o="1.3.6.1.2.1.2.2.1.8.3" d="1"] The corresponding syslog message has a priority value of 29 which means a facility level of 3 (system daemons) and a severity level of 5 (Notice: Normal but significant condition) according to the algorithm for calculation of priority value specified in section 6.2.1 of [I-D.ietf-syslog-protocol]. The rest of the fields in the header of the syslog message are parameters that are specific to the system running the snmp-to-syslog translator. The syslog version is 1 and the message was generated at 22:14:15.003Z on 2003-10-11T by the host "mymachine.example.com". The application on the snmp-to- syslog translator that generated the message was "snmptrapd", there is no information about the process id and the message on the snmp- Marinov & Schoenwaelder Expires August 30, 2007 [Page 11] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 to-syslog system is identified with the MSGID of ID47. The syslog message contains one structured data element with a SD-ID of "snmp" which means that this is the scopedPDU portion of an SNMP event notification message. The data which is contained in the notification is associated with the ContextEngineID "123456" and ContextName "ctx1". The request-id of the SNMP notification message was "7145575". Then follows the data portion of the scopedPDU. The first two variables contained in the data portion are always the sysUpTime.0 and snmpTrapOID.0. An snmpTrapOID.0 with a value of "1.3.6.1.6.3.1.1.5.4" means that this is a linkUp trap. The parameters o="1.3.6.1.2.1.2.2.1.1.3" d="3" mean that the SNMP notification message is carrying the ifIndex object which has a type INTEGER and has a value of 3. The parameters o="1.3.6.1.2.1.2.2.1.7.3" d="1" mean that the SNMP notification message is carrying the object ifAdminStatus which has type INTEGER and a value of 1. The parameters o="1.3.6.1.2.1.2.2.1.8.3" d="1" mean that the SNMP notification message is carrying the object ifOperStatus which has type INTEGER and a value of "1". 5. IANA Considerations IANA is requested to register the SD-ID value "snmp" together with the PARAM-NAME values specified in Section 3.2 in the registry for SYSLOG structured data id values according to section 9 in [I-D.ietf-syslog-protocol]. SD-ID PARAM-NAME snmp OPTIONAL ctxEngine OPTIONAL ctxName OPTIONAL reqid OPTIONAL sysUpTime OPTIONAL snmpTrapOID OPTIONAL o OPTIONAL s OPTIONAL c OPTIONAL C OPTIONAL u OPTIONAL d OPTIONAL i OPTIONAL n OPTIONAL p OPTIONAL t OPTIONAL Marinov & Schoenwaelder Expires August 30, 2007 [Page 12] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 6. Security Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [I-D.ietf-syslog-protocol] Gerhards, R., "The syslog Protocol", Internet Draft (work in progress), November 2006. [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework.", BCP 74, RFC 3584, August 2003. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. Marinov & Schoenwaelder Expires August 30, 2007 [Page 13] Internet-Draft Mapping SNMP Notifications to SYSLOG February 2007 7.2. Informative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. Authors' Addresses Vladislav Marinov Jacobs University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 176 70046718 Email: v.marinov@iu-bremen.de Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@iu-bremen.de Marinov & Schoenwaelder Expires August 30, 2007 [Page 14] Internet-Draft Mapping SNMP Notifications to SYSLOG February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Marinov & Schoenwaelder Expires August 30, 2007 [Page 15]