IANA Considerations for OSPF
draft-ietf-ospf-iana-03
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4940.
|
|
|---|---|---|---|
| Authors | Bill Fenner (ˢˣˠ) , Kireeti Kompella | ||
| Last updated | 2015-10-14 (Latest revision 2007-03-20) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Best Current Practice | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4940 (Best Current Practice) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Bill Fenner (ˢˣˠ) | ||
| Send notices to | (None) |
draft-ietf-ospf-iana-03
Network Working Group K. Kompella
Internet-Draft Juniper Networks
Intended status: Best Current B. Fenner
Practice AT&T Labs--Research
Expires: September 19, 2007 March 18, 2007
IANA Considerations for OSPF
draft-ietf-ospf-iana-03
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 September 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This memo creates a number of OSPF registries and provides guidance
to IANA for assignment of code points within these registries.
Kompella & Fenner Expires September 19, 2007 [Page 1]
Internet-Draft IANA Considerations for OSPF March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 4
1.2. Changes from version -00 . . . . . . . . . . . . . . . . . 4
1.3. Changes from version -01 . . . . . . . . . . . . . . . . . 4
2. OSPF Registries . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. OSPFv2 Options . . . . . . . . . . . . . . . . . . . . . . 4
2.2. OSPFv3 Options . . . . . . . . . . . . . . . . . . . . . . 5
2.3. OSPF Packet Type (both v2 and v3) . . . . . . . . . . . . 5
2.3.1. OSPF Authentication Type . . . . . . . . . . . . . . . 5
2.4. OSPFv2 Link State (LS) Type . . . . . . . . . . . . . . . 5
2.4.1. OSPFv2 Router LSA Link Type . . . . . . . . . . . . . 6
2.4.2. OSPFv2 Router Properties . . . . . . . . . . . . . . . 6
2.5. OSPFv3 LSA Function Code . . . . . . . . . . . . . . . . . 6
2.5.1. OSPFv3 Prefix Options . . . . . . . . . . . . . . . . 6
2.5.2. OSPFv3 Router LSA Link Type . . . . . . . . . . . . . 7
2.6. OSPFv2 Opaque LSA Type . . . . . . . . . . . . . . . . . . 7
2.6.1. OSPFv2 Grace LSA Top Level TLVs . . . . . . . . . . . 7
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. OSPFv2 Options Registry . . . . . . . . . . . . . . . . . 8
5.2. OSPFv3 Options Registry . . . . . . . . . . . . . . . . . 9
5.3. OSPF Packet Type Registry . . . . . . . . . . . . . . . . 9
5.4. OSPF Authentication Type Registry . . . . . . . . . . . . 10
5.5. OSPFv2 Link State Type Registry . . . . . . . . . . . . . 10
5.6. OSPFv2 Router LSA Link Type Registry . . . . . . . . . . . 10
5.7. OSPFv2 Router Properties Registry . . . . . . . . . . . . 10
5.8. OSPFv3 LSA Function Code Registry . . . . . . . . . . . . 11
5.9. OSPFv3 Prefix Options Registry . . . . . . . . . . . . . . 12
5.10. OSPFv3 Router LSA Link Type Registry . . . . . . . . . . . 12
5.11. OSPFv2 Opaque LSA Type Registry . . . . . . . . . . . . . 13
5.12. OSPFv2 Grace LSA Top Level TLV Registry . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Kompella & Fenner Expires September 19, 2007 [Page 2]
Internet-Draft IANA Considerations for OSPF March 2007
1. Introduction
This memo defines various OSPF registries for IANA to set up and
maintain for OSPF code points. In some cases, this memo defines
ranges of code point values within these registries; each such range
has a different assignment policy.
The terms used in describing the assignment policies are as follows:
o Standards Action
o Experimentation
o Vendor Private Use
o Reserved
Standards Action means that assignment in that range MUST only be
made for Standards Track RFCs (as defined in [RFC2434]).
Some of the registries defined below reserve a range of values for
Experimentation. For guidelines regarding the use of such values see
[RFC3692]. Values from this range MUST NOT be assigned by IANA.
Further guidance on the use of the Experimentation range may be found
in paragraphs 4, 5 and 6 of [RFC3692]. An implementation MAY choose
to not support values from the Experimentation range. In such a
case, the protocol data structure with a code point from the
Experimentation range is ignored, unless other protocol machinery
says how to deal with it. "Ignored" in this context means that the
associated data structure is removed from the received packet before
further processing, including flooding.
Values set aside as Vendor Private Use MUST NOT be assigned by IANA.
A protocol data structure whose code point falls in this range MUST
have a disambiguating field identifying the Vendor. This identifier
consists of four octets of the Vendor's SMI enterprise code (see
[ENTERPRISE-NUMBERS]) in network byte order; the location of this
code must be well- defined per data structure. An implementation
that encounters a Vendor Private code point SHOULD check whether the
enterprise code is one that it recognises; if so, the implementation
MAY choose to interpret the code point and data structure.
Otherwise, it SHOULD ignore the code point, unless protocol machinery
says how to deal with the data structure (as defined in the previous
paragraph). This allows multiple vendor private extensions to co-
exist in a network.
Values in the Reserved range MUST NOT be assigned until a Standards
Track or Best Common Practices RFC is published defining the
Kompella & Fenner Expires September 19, 2007 [Page 3]
Internet-Draft IANA Considerations for OSPF March 2007
assignment policy for that range. This RFC MUST be the product of
the OSPF Working Group; if the OSPF WG is terminated, then it MUST be
reviewed by an Expert Reviewer designated by the IESG.
1.1. Conventions used in this document
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 RFC 2119 [RFC2119].
1.2. Changes from version -00
[This section to be removed before publication.]
Removed misguided reference to non-existent U bit in OSPFv2 Opaque
LSAs.
Tightened up requirements for defining new OSPFv2 Link State (LS)
Type (section 2.4) and OSPFv2 Router LSA Link Type (section 2.4.1).
1.3. Changes from version -01
[This section to be removed before publication.]
Reworded experimental text as suggested by Jari Arkko and Brian
Carpenter in IESG review.
Added all of Section 5 to give IANA starting points for the
registries to create.
2. OSPF Registries
This section lists the various registries for OSPF protocol code
points. Note that some of these are for OSPF, and some are specific
to a particular version of OSPF; also, some registries pre-date this
memo.
Registries that are specific to one version of OSPF reflect the
version number in the registry name (e.g., OSPFv2 Options). A
registry whose name does not mention a version number applies to both
OSPFv2 and OSPFv3 (e.g., OSPF Packet Type).
2.1. OSPFv2 Options
(Defined in section A.2 of [RFC2328], updated in section A.1 of
[RFC2370]. See also [RFC3101].)
Kompella & Fenner Expires September 19, 2007 [Page 4]
Internet-Draft IANA Considerations for OSPF March 2007
Assignment policy: Standards Action.
2.2. OSPFv3 Options
(Defined in section A.2 of [RFC2740])
Assignment policy: Standards Action.
2.3. OSPF Packet Type (both v2 and v3)
(Defined in section A.3.1 of [RFC2328])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-5 | Already assigned |
| 6-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
2.3.1. OSPF Authentication Type
(Defined in section A.3.1 of [RFC2328])
(Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.)
+-------------+-------------------+
| Range | Assignment Policy |
+-------------+-------------------+
| 0-2 | Already assigned |
| 3-247 | Standards Action |
| 248-65519 | Reserved |
| 65520-65535 | Experimentation |
+-------------+-------------------+
2.4. OSPFv2 Link State (LS) Type
(Defined in section A.4.1 of [RFC2328])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-11 | Already assigned |
| 12-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
Kompella & Fenner Expires September 19, 2007 [Page 5]
Internet-Draft IANA Considerations for OSPF March 2007
If a new LS Type is documented, the documentation MUST say how the
Link State ID is to be filled in, what the flooding scope of the LSA
is, and how backward compatibility is maintained.
2.4.1. OSPFv2 Router LSA Link Type
(Defined in section A.4.2 of [RFC2328])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
No Experimental range is defined, due to possible backwards
compatibility issues.
If a new Router LSA Link Type is documented, the documentation SHOULD
say how the Link State ID, Link ID and Link Data fields are to be
filled in, and how backward compatibility is maintained.
2.4.2. OSPFv2 Router Properties
(Defined in section A.4.2 of [RFC2328], updated in [RFC3101])
This 8-bit field in the Router LSA is unnamed; it is the field
immediately following the Router LSA length.
Assignment policy: Standards Action.
2.5. OSPFv3 LSA Function Code
This registry is created by [I-D.ietf-ospf-cap]. This document
provides the values to be populated for values defined in section
A.4.2.1 of [RFC2740].
2.5.1. OSPFv3 Prefix Options
(Defined in section A.4.1.1 of [RFC2740])
Assignment policy: Standards Action.
Kompella & Fenner Expires September 19, 2007 [Page 6]
Internet-Draft IANA Considerations for OSPF March 2007
2.5.2. OSPFv3 Router LSA Link Type
(Defined in section A.4.3 of [RFC2740])
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an
enterprise code to identify the Vendor.
No Experimental range is defined, due to possible backwards
compatibility issues.
2.6. OSPFv2 Opaque LSA Type
(Defined in section A.2 of [RFC2370])
(Note: this registry is called "OSPF Opaque LSA Option" by IANA. See
also [RFC3630].)
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-127 | Standards Action |
| 128-247 | Reserved |
| 248-251 | Experimentation |
| 252-255 | Vendor Private Use |
+---------+--------------------+
In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private
Use range, the first four octets of Opaque Information MUST be the
Vendor enterprise code.
A document defining a new Standards Track Opaque LSA with TLVs and
sub-TLVs MUST describe ranges and assignment policies for these TLVs.
2.6.1. OSPFv2 Grace LSA Top Level TLVs
(Defined in Section A of [RFC3623])
Kompella & Fenner Expires September 19, 2007 [Page 7]
Internet-Draft IANA Considerations for OSPF March 2007
+-------------+--------------------+
| Range | Assignment Policy |
+-------------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-255 | Standards Action |
| 256-65519 | Reserved |
| 65520-65527 | Experimentation |
| 65528-65535 | Vendor Private Use |
+-------------+--------------------+
In a Grace LSA, if a top-level TLV has a Type from the Vendor Private
Use range, the Length MUST be at least four, and the first four
octets of the Value field MUST be the Vendor enterprise code.
3. Acknowledgments
Many thanks to Adrian Farrel and Acee Lindem for their review and
comments.
4. Security Considerations
The lack of adequate IANA guidelines may be viewed as an avenue for
Denial of Service attacks on IETF protocols (in this case, OSPFv2 and
OSPFv3), and on the IETF Standards Process in general. This memo
attempts to close this loophole for OSPFv2 and OSPFv3.
Authors contemplating extensions to OSPF SHOULD examine such
extensions carefully, and consider whether new registries are needed,
and if so, allocation policies within each registry.
5. IANA Considerations
This document specifies assignment policy for several existing IANA
registries and creates several more.
5.1. OSPFv2 Options Registry
Section 2.1 defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 6 are already assigned. The initial registry contents are given
below.
Kompella & Fenner Expires September 19, 2007 [Page 8]
Internet-Draft IANA Considerations for OSPF March 2007
OSPFv2 Options Registry (Section 2.1)
Value Description Reference
----- ----------- ---------
0x02 E-bit [RFC2328]
0x04 MC-bit [RFC1584]
0x08 N/P-bit [RFC3101]
0x10 Reserved
0x20 DC-bit [RFC1793]
0x40 O-bit [RFC2370]
5.2. OSPFv3 Options Registry
Section 2.2 defines the policy for allocation of bits from this
registry as "Standards Action". There are 24 bits in this field, and
6 are assigned. The initial registry contents are given below.
OSPFv3 Options Registry (Section 2.2)
Value Description Reference
-------- ----------- ---------
0x000001 V6-bit [RFC2740]
0x000002 E-bit [RFC2328]
0x000004 MC-bit [RFC1584]
0x000008 N-bit [RFC3101]
0x000010 R-Bit [RFC2740]
0x000020 DC-bit [RFC1793]
5.3. OSPF Packet Type Registry
Section 2.3 defines the policy for allocation of values from this
registry for different ranges. The initial registry contents are
given below.
OSPF Packet Type (Section 2.3)
Value Description Reference
----- -------------------- ---------
1 Hello [RFC2328]
2 Database Description [RFC2328]
3 Link State Request [RFC2328]
4 Link State Update [RFC2328]
5 Link State Ack [RFC2328]
Kompella & Fenner Expires September 19, 2007 [Page 9]
Internet-Draft IANA Considerations for OSPF March 2007
5.4. OSPF Authentication Type Registry
This registry already exists at IANA, called "ospf-authentication-
codes". Section 2.3.1 defines the policy for allocation from this
registry for different ranges.
5.5. OSPFv2 Link State Type Registry
Section 2.4 defines the policy for allocations from this registry for
different ranges. The initial registry contents are given below.
OSPFv2 Link State (LS) Type (Section 2.4)
Value Description Reference
----- ------------------------ ---------
1 Router-LSA [RFC2328]
2 Network-LSA [RFC2328]
3 Summary-LSA (IP network) [RFC2328]
4 Summary-LSA (ASBR) [RFC2328]
5 AS-external-LSA [RFC2328]
6 Group-membership-LSA [RFC1584]
7 NSSA AS-external LSA [RFC3101]
8 Reserved
9 Link-local Opaque LSA [RFC2370]
10 Area-local Opaque LSA [RFC2370]
11 Opaque LSA [RFC2370]
5.6. OSPFv2 Router LSA Link Type Registry
Section 2.4.1 defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv2 Router LSA Link Type (Section 2.4.1)
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2328]
2 Transit Network [RFC2328]
3 Stub Network [RFC2328]
4 Virtual Link [RFC2328]
5.7. OSPFv2 Router Properties Registry
Section 2.4.2 defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 5 are already assigned. The initial registry contents are given
below.
Kompella & Fenner Expires September 19, 2007 [Page 10]
Internet-Draft IANA Considerations for OSPF March 2007
OSPFv2 Options Registry (Section 2.1)
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 W-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
5.8. OSPFv3 LSA Function Code Registry
This registry is created by [I-D.ietf-ospf-cap], which also defines
the registration policy. This section contains values that belong in
this registry that were defined by [RFC2740].
As defined in [RFC2740], the first three bits of the LSA Function
Code are the U, S1 and S2 bits. A given function code implies a
specific setting for the U, S1 and S2 bits as shwon in the "LS Type"
column.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which
does not recognize the LSA's function code. Its values are:
U-bit LSA Handling
----- ----------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
The S1 and S2 bits indicate the flooding scope of the LSA. The
values are:
S1 S2 Flooding Scope
-- -- --------------------------------------------------------------
0 0 Link-Local Scoping. Flooded only on link it is originated on.
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
The initial registry contents are given below.
Kompella & Fenner Expires September 19, 2007 [Page 11]
Internet-Draft IANA Considerations for OSPF March 2007
OSPFv3 LSA Function Code (Section 2.5)
LSA function code LS Type Description Reference
----------------- ------- --------------------- ---------
1 0x2001 Router-LSA [RFC2740]
2 0x2002 Network-LSA [RFC2740]
3 0x2003 Inter-Area-Prefix-LSA [RFC2740]
4 0x2004 Inter-Area-Router-LSA [RFC2740]
5 0x4005 AS-External-LSA [RFC2740]
6 0x2006 Group-membership-LSA [RFC2740]
7 0x2007 Type-7-LSA [RFC2740]
8 0x0008 Link-LSA [RFC2740]
9 0x2009 Intra-Area-Prefix-LSA [RFC2740]
5.9. OSPFv3 Prefix Options Registry
Section 2.5.1 defines the policy for allocation of bits from this
registry as "Standards Action". There are only 8 bits in this field,
and 4 are already assigned. The initial registry contents are given
below.
OSPFv3 Prefix Options Registry (Section 2.5.1)
Value Description Reference
----- ----------- ---------
0x01 NU-bit [RFC2740]
0x02 LA-bit [RFC2740]
0x04 MC-bit [RFC2740]
0x08 P-bit [RFC2740]
5.10. OSPFv3 Router LSA Link Type Registry
Section 2.5.2 defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv3 Router LSA Link Type (Section 2.5.2)
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2740]
2 Transit Network [RFC2740]
3 Reserved [RFC2740]
4 Virtual Link [RFC2740]
Kompella & Fenner Expires September 19, 2007 [Page 12]
Internet-Draft IANA Considerations for OSPF March 2007
5.11. OSPFv2 Opaque LSA Type Registry
This registry already exists at IANA, called "ospf-opaque-types".
Section 2.6 defines the policy for allocation from this registry for
different ranges.
5.12. OSPFv2 Grace LSA Top Level TLV Registry
Section 2.6.1 defines the policy for allocations from this registry
for different ranges. The initial registry contents are given below.
OSPFv2 Grace LSA Top Level TLV (Section 2.6.1)
Value Description Reference
----- ----------------------- ---------
1 Grace Period [RFC3623]
2 Graceful Restart reason [RFC3623]
3 IP Interface Address [RFC3623]
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994.
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits",
RFC 1793, April 1995.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003.
Kompella & Fenner Expires September 19, 2007 [Page 13]
Internet-Draft IANA Considerations for OSPF March 2007
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, November 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
6.2. Informative References
[ENTERPRISE-NUMBERS]
"PRIVATE ENTERPRISE NUMBERS",
<http://www.iana.org/assignments/enterprise-numbers>.
[I-D.ietf-ospf-cap]
Lindem, A., "Extensions to OSPF for Advertising Optional
Router Capabilities", draft-ietf-ospf-cap-10 (work in
progress), February 2007.
Authors' Addresses
Kireeti Kompella
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: kireeti@juniper.net
Bill Fenner
AT&T Labs--Research
1 River Oaks Place
San Jose, California 95134
United States
Phone: +1 (408) 493-8505
Email: fenner@research.att.com
Kompella & Fenner Expires September 19, 2007 [Page 14]
Internet-Draft IANA Considerations for OSPF March 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).
Kompella & Fenner Expires September 19, 2007 [Page 15]