RFC 3815
Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)
4.3. The MPLS-LDP-GENERIC-STD-MIB Module
This MIB Module MUST be supported if LDP uses a Per Platform Label Space. This MIB Module contains a Label Range (LR) table for configuring MPLS Generic Label Ranges. This table is mplsLdpEntityGenericLRTable. Although the LDP Specification does not provide a way for configuring Label Ranges for Generic Labels, the MIB does provide a way to reserve a range of generic labels because this was thought to be useful by the working group. MPLS-LDP-GENERIC-STD-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, MODULE-IDENTITY, Unsigned32 FROM SNMPv2-SMI -- [RFC2578] MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579] InterfaceIndexOrZero FROM IF-MIB -- [RFC2020] mplsStdMIB FROM MPLS-TC-STD-MIB -- [RFC3811] mplsLdpEntityLdpId, mplsLdpEntityIndex FROM MPLS-LDP-STD-MIB -- [RFC3813] ; mplsLdpGenericStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 6, 2004 ORGANIZATION "Multiprotocol Label Switching (mpls) Working Group" CONTACT-INFO "Joan Cucchiara (jcucchiara@mindspring.com) Marconi Communications, Inc. Hans Sjostrand (hans@ipunplugged.com) ipUnplugged
James V. Luciani (james_luciani@mindspring.com)
Marconi Communications, Inc.
Working Group Chairs:
George Swallow, email: swallow@cisco.com
Loa Andersson, email: loa@pi.se
MPLS Working Group, email: mpls@uu.net
"
DESCRIPTION
"Copyright (C) The Internet Society (year). The
initial version of this MIB module was published
in RFC 3815. For full legal notices see the RFC
itself or see:
http://www.ietf.org/copyrights/ianamib.html
This MIB contains managed object definitions for
configuring and monitoring the Multiprotocol Label
Switching (MPLS), Label Distribution Protocol (LDP),
utilizing ethernet as the Layer 2 media."
REVISION "200406030000Z" -- June 6, 2004
DESCRIPTION
"Initial version published as part of RFC 3815."
::= { mplsStdMIB 7 }
--****************************************************************
mplsLdpGenericObjects
OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 1 }
mplsLdpGenericConformance
OBJECT IDENTIFIER ::= { mplsLdpGenericStdMIB 2 }
--****************************************************************
-- MPLS LDP GENERIC Objects
--****************************************************************
--
-- Ldp Entity Objects for Generic Labels
--
mplsLdpEntityGenericObjects OBJECT IDENTIFIER ::=
{ mplsLdpGenericObjects 1 }
--
-- The MPLS LDP Entity Generic Label Range Table
--
mplsLdpEntityGenericLRTable OBJECT-TYPE
SYNTAX SEQUENCE OF MplsLdpEntityGenericLREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The MPLS LDP Entity Generic Label Range (LR)
Table.
The purpose of this table is to provide a mechanism
for configurating a contiguous range of generic labels,
or a 'label range' for LDP Entities.
LDP Entities which use Generic Labels must have at least
one entry in this table. In other words, this table
'extends' the mpldLdpEntityTable for Generic Labels."
::= { mplsLdpEntityGenericObjects 1 }
mplsLdpEntityGenericLREntry OBJECT-TYPE
SYNTAX MplsLdpEntityGenericLREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A row in the LDP Entity Generic Label
Range (LR) Table. One entry in this table contains
information on a single range of labels
represented by the configured Upper and Lower
Bounds pairs. NOTE: there is NO corresponding
LDP message which relates to the information
in this table, however, this table does provide
a way for a user to 'reserve' a generic label
range.
NOTE: The ranges for a specific LDP Entity
are UNIQUE and non-overlapping.
A row will not be created unless a unique and
non-overlapping range is specified."
INDEX { mplsLdpEntityLdpId,
mplsLdpEntityIndex,
mplsLdpEntityGenericLRMin,
mplsLdpEntityGenericLRMax
}
::= { mplsLdpEntityGenericLRTable 1 }
MplsLdpEntityGenericLREntry ::= SEQUENCE {
mplsLdpEntityGenericLRMin Unsigned32,
mplsLdpEntityGenericLRMax Unsigned32,
mplsLdpEntityGenericLabelSpace INTEGER,
mplsLdpEntityGenericIfIndexOrZero InterfaceIndexOrZero,
mplsLdpEntityGenericLRStorageType StorageType,
mplsLdpEntityGenericLRRowStatus RowStatus
}
mplsLdpEntityGenericLRMin OBJECT-TYPE
SYNTAX Unsigned32(0..1048575)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The minimum label configured for this range."
::= { mplsLdpEntityGenericLREntry 1 }
mplsLdpEntityGenericLRMax OBJECT-TYPE
SYNTAX Unsigned32(0..1048575)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The maximum label configured for this range."
::= { mplsLdpEntityGenericLREntry 2 }
mplsLdpEntityGenericLabelSpace OBJECT-TYPE
SYNTAX INTEGER {
perPlatform(1),
perInterface(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This value of this object is perPlatform(1), then
this means that the label space type is
per platform.
If this object is perInterface(2), then this
means that the label space type is per Interface."
REFERENCE
"RFC3036, LDP Specification, Section 2.2.1,
Label Spaces."
DEFVAL { perPlatform }
::= { mplsLdpEntityGenericLREntry 3 }
mplsLdpEntityGenericIfIndexOrZero OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This value represents either the InterfaceIndex of
the 'ifLayer' where these Generic Label would be created,
or 0 (zero). The value of zero means that the
InterfaceIndex is not known.
However, if the InterfaceIndex is known,
then it must be represented by this value.
If an InterfaceIndex becomes known, then the
network management entity (e.g., SNMP agent) responsible
for this object MUST change the value from 0 (zero) to the
value of the InterfaceIndex."
::= { mplsLdpEntityGenericLREntry 4 }
mplsLdpEntityGenericLRStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row.
Conceptual rows having the value 'permanent(4)'
need not allow write-access to any columnar
objects in the row."
DEFVAL { nonVolatile }
::= { mplsLdpEntityGenericLREntry 5 }
mplsLdpEntityGenericLRRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this conceptual row. All writable
objects in this row may be modified at any time,
however, as described in detail in the section
entitled, 'Changing Values After Session
Establishment', and again described in the
DESCRIPTION clause of the mplsLdpEntityAdminStatus object,
if a session has been initiated with a Peer,
changing objects in this table will
wreak havoc with the session and interrupt traffic.
To repeat again: the recommended procedure is
to set the mplsLdpEntityAdminStatus to
down, thereby explicitly causing a
session to be torn down. Then, change objects
in this entry, then set the mplsLdpEntityAdminStatus
to enable which enables a new session to be initiated.
There must exist at least one entry in this
table for every LDP Entity that has a
generic label configured."
::= { mplsLdpEntityGenericLREntry 6 }
--****************************************************************
-- Module Conformance Statement
--****************************************************************
mplsLdpGenericGroups
OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 1 }
mplsLdpGenericCompliances
OBJECT IDENTIFIER ::= { mplsLdpGenericConformance 2 }
--
-- Full Compliance
--
mplsLdpGenericModuleFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The Module is implemented with support for
read-create and read-write. In other words,
both monitoring and configuration
are available when using this MODULE-COMPLIANCE."
MODULE -- this module
MANDATORY-GROUPS {
mplsLdpGenericGroup
}
OBJECT mplsLdpEntityGenericLRRowStatus
SYNTAX RowStatus { active(1) }
WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
DESCRIPTION
"Support for createAndWait and notInService is not required."
::= { mplsLdpGenericCompliances 1 }
--
-- Read-Only Compliance
--
mplsLdpGenericModuleReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The Module is implemented with support for
read-only. In other words, only monitoring
is available by implementing this MODULE-COMPLIANCE."
MODULE -- this module
MANDATORY-GROUPS {
mplsLdpGenericGroup
}
OBJECT mplsLdpEntityGenericLabelSpace
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsLdpEntityGenericIfIndexOrZero
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsLdpEntityGenericLRStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT mplsLdpEntityGenericLRRowStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the
only status that needs to be supported."
::= { mplsLdpGenericCompliances 2 }
--
-- units of conformance
--
mplsLdpGenericGroup OBJECT-GROUP
OBJECTS {
mplsLdpEntityGenericLabelSpace,
mplsLdpEntityGenericIfIndexOrZero,
mplsLdpEntityGenericLRStorageType,
mplsLdpEntityGenericLRRowStatus
}
STATUS current
DESCRIPTION
"Objects that apply to all MPLS LDP implementations
using Generic Labels as the Layer 2."
::= { mplsLdpGenericGroups 1 }
END
5. Acknowledgments
This document is a product of the MPLS Working Group. The authors would like to thank Mike MacFadden and Adrian Farrel for their helpful comments on several reviews. Also, the authors would like to give a special acknowledgement to Bert Wijnen for his many detailed reviews. Bert's assistance and guidance is greatly appreciated. We would also like to thank Cheenu Srinivasan, Arun Viswanathan and Thomas D. Nadeau, the authors of the MPLS-LSR-STD-MIB [RFC3813], for their assistance. Additionally, there have been other members of the working group that have been very helpful: Alan Kullberg from NetPlane Systems gave input on earlier versions of this document, and more recently, Riza Cetin of Alcatel and Neil Jerram of Data Connection who both provided MIB objects. Early versions of this document were also reviewed by colleagues at Nortel Networks and Ericsson. The authors would like to thank the following people: Leigh McLellan, Geetha Brown, Geping Chen and Charlan Zhou from Nortel Networks, and Zoltan Takacs and Bo Augustsson from Ericsson.6. References
6.1. Normative References
[RFC2115] Brown, C. and F. Baker, "Management Information Base for Frame Relay DTEs Using SMIv2", RFC 2115, September 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998. [RFC2514] Noto, M., Spiegel, E., and K. Tesink, editors, "Definition of Textual Conventions and OBJECT-IDENTITIES for ATM Management", RFC 2514, February 1999. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001. [RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001. [RFC3215] Boscher, C., Cheval, P., Wu, L., and E. Gray, "LDP State Machine", RFC 3215, January 2002. [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information Base for the Differentiated Services Architecture", RFC 3289, May 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Coventions for Internet Network Addresses", RFC 3291, May 2002. [RFC3413] Levi, D., Meyers, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3811] Nadeau, T. and J. Cucchiara, Editors "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004. [RFC3813] Srinivansan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 20046.2. Informative References
[MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol Label Switching (MPLS) Management Overview", Work in Progress, September 2003. [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002.7. Security Considerations
This Security Considerations section consists of 4 subsections, one for each of the MIB Modules in this document.7.1. Security Considerations for MPLS-LDP-STD-MIB
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityTable contains objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER). The mplsLdpLspFecTable contains objects which associate an LSP with a FEC. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether
read access to these objects should be allowed, since read
access may be undesirable under certain circumstances.
Some of the readable objects in this MIB module i.e., (objects with a
MAX-ACCESS other than not-accessible), may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o the mplsLdpEntityTable, mplsLdpPeerTable, mplsLdpSessionTable
and mplsLdpSessionStatsTable collectively show the LDP LSP
network topology. If an Administrator does not want to reveal
the LDP LSP topology of the network, then these tables should be
considered sensitive/vulnerable.
7.2. Security Considerations for MPLS-LDP-ATM-STD-MIB
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
o the mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable contain
objects to provision potential LDP sessions on the Label
Switching Router (LSR) or Label Edge Router (LER) over Layer 2
of ATM. These tables extend the mplsLdpEntityTable in the MPLS-
LDP-MIB. Unauthorized access to objects in these tables, could
result in disruption of traffic on the network. This is
especially true if an LDP session has been established. The use
of stronger mechanisms such as SNMPv3 security should be
considered where possible. Specifically, SNMPv3 VACM and USM
MUST be used with any v3 agent which implements this MIB.
Administrators should consider whether read access to these
objects should be allowed, since read access may be undesirable
under certain circumstances.
Some of the readable objects in this MIB module i.e., (objects with a
MAX-ACCESS other than not-accessible), may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o the mplsLdpEntityAtmTable and mplsLdpEntityAtmLRTable show the
Label Ranges for ATM. If an Administrator does not want to
reveal this information then these tables should be considered
sensitive/vulnerable and treated accordingly.
7.3. Security Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
o the mplsLdpEntityFrameRelayTable and
mplsLdpEntityFrameRelayLRTable contain objects to provision
potential LDP sessions on the Label Switching Router (LSR) or
Label Edge Router (LER) over Layer 2 of Frame Relay. These
tables extend the mplsLdpEntityTable in the MPLS-LDP-MIB.
Unauthorized access to objects in these tables, could result in
disruption of traffic on the network. This is especially true
if an LDP session has been established. The use of stronger
mechanisms such as SNMPv3 security should be considered where
possible. Specifically, SNMPv3 VACM and USM MUST be used with
any v3 agent which implements this MIB. Administrators should
consider whether read access to these objects should be allowed,
since read access may be undesirable under certain
circumstances.
Some of the readable objects in this MIB module i.e., (objects with a
MAX-ACCESS other than not-accessible), may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP. These are the tables and objects and their
sensitivity/vulnerability:
o the mplsLdpEntityFrameRelayTable and
mplsLdpEntityFrameRelayLRTable show the Label Ranges for Frame
Relay. If an Administrator does not want to reveal this
information then these tables should be considered
sensitive/vulnerable and treated accordingly.
7.4. Security Considerations for MPLS-LDP-GENERIC-STD-MIB
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityGenericLRTable contains objects to provision potential LDP sessions on the Label Switching Router (LSR) or Label Edge Router (LER) over Layer 2 of Ethernet. This table extends the mplsLdpEntityTable in the MPLS-LDP-MIB. Unauthorized access to objects in these tables, could result in disruption of traffic on the network. This is especially true if an LDP session has been established. The use of stronger mechanisms such as SNMPv3 security should be considered where possible. Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent which implements this MIB. Administrators should consider whether read access to these objects should be allowed, since read access may be undesirable under certain circumstances. Some of the readable objects in this MIB module i.e., (objects with a MAX-ACCESS other than not-accessible), may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o the mplsLdpEntityGenericLRTable shows the Label Ranges for ethernet. If an Administrator does not want to reveal this information then these tables should be considered sensitive/vulnerable and treated accordingly.7.5. Additional Security Considerations
The following paragraphs describe additional security considerations which are applicable to all 4 of the MIB Modules in this document. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.8. IANA Considerations
As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB [MPLSTCMIB], MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. There are 4 MPLS MIB Modules contained in this document, each of the following "IANA Considerations" subsections lists new IANA assignments under the mplsStdMIB subtree. New assignments can only be made via a Standards Action as specified in [RFC2434].8.1. IANA Considerations for MPLS-LDP-STD-MIB
The IANA has assigned { mplsStdMIB 4 } to the MPLS-LDP-STD-MIB module specified in this document.8.2. IANA Considerations for MPLS-LDP-ATM-STD-MIB
The IANA has assigned { mplsStdMIB 5 } to the MPLS-LDP-ATM-STD-MIB module specified in this document.8.3. IANA Considerations for MPLS-LDP-FRAME-RELAY-STD-MIB
The IANA has assigned { mplsStdMIB 6 } to the MPLS-LDP-FRAME-RELAY- STD-MIB module specified in this document.8.4. IANA Considerations for MPLS-LDP-GENERIC-STD-MIB
The IANA has assigned { mplsStdMIB 7 } to the MPLS-LDP-GENERIC-STD- MIB module specified in this document.
9. Authors' Addresses
James V. Luciani Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851 EMail: james_luciani@mindspring.com Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden Phone: +46 8 725 5900 EMail: hans@ipunplugged.com Joan E. Cucchiara Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851 Phone: +1 978 275 7400 EMail: jcucchiara@mindspring.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 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.