Internet DRAFT - draft-klensin-iana-reg-policy
draft-klensin-iana-reg-policy
Network Working Group J. Klensin
Internet-Draft
Expires: January 18, 2006 V. Cerf
MCI
S. Bradner
Harvard University
July 17, 2005
Registration Policies for the IETF and IANA
draft-klensin-iana-reg-policy-01.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 January 18, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
For many years, the IETF has maintained, via the IANA, registries of
protocol and parameter names and numbers. The primary purpose of
these registries is to ensure that different methods and options are
properly identified and distinguished. Registration of such names or
numbers generally does not necessarily imply approval of the
Klensin, et al. Expires January 18, 2006 [Page 1]
Internet-Draft Registration Policies July 2005
technology in the corresponding protocol. Instead, registration
represents the desire to keep choices distinctly identified,
separated, and public to avoid conflicts in use. In recent years,
various changes in the nature of the instructions given to the IANA,
increased perceptions of scarcity in the number spaces associated
with some of the parameters, and other issues have led to a shift in
emphasis from "registration to keep identifiers unique" toward
evaluations of the quality of proposals for and preferences among
protocols. This document argues that shift is undesirable. It
articulates and clarifies the principles that the reasons for
evaluation of registration requests is to ensure a minimum quality of
definition, that any assertions of scarcity to restrict registrations
must be accompanied by a plan for evaluating and, if appropriate,
eliminating the scarcity problem, and that, if a "no scarcity" plan
is not possible, to establish criteria for making decisions that are
as specific and objective as possible.
This document is intended to update the general considerations of RFC
2434, the specific allocation rules of RFC 2780, and the evaluation
criteria associated with other documents that condition an IANA
registration on Expert Review with IESG oversight or on IESG or IETF
action.
[[NOTE IN DRAFT: The length of this abstract exceeds the RFC Editor's
recommended limits. It will be shortened in future versions, but the
longer one is believed to be helpful for I-D announcements, etc.]]
Klensin, et al. Expires January 18, 2006 [Page 2]
Internet-Draft Registration Policies July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Registration Principle: Clarity of Definition . . . . . . . 6
3. Registration Principle: Allocating Scarcity . . . . . . . . 6
3.1 Scarcity in Parameter Spaces . . . . . . . . . . . . . . . 6
3.2 Scaling and Scarcity Reduction . . . . . . . . . . . . . . 7
3.3 Legitimacy of Registration Requests . . . . . . . . . . . 8
4. Multiple category or arc registrations . . . . . . . . . . . 8
5. Interpretation of Requirements for IESG Review or
Standards Action . . . . . . . . . . . . . . . . . . . . . . 8
6. Reflections on 2434bis . . . . . . . . . . . . . . . . . . . 9
6.1 Designated Experts . . . . . . . . . . . . . . . . . . . . 9
6.2 Override Procedure . . . . . . . . . . . . . . . . . . . . 10
6.3 Denial of Service Attacks . . . . . . . . . . . . . . . . 10
6.4 Appeals . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Internationalization Considerations . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
9. Security considerations . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
A. Changes from previous version . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1 Normative References . . . . . . . . . . . . . . . . . . 11
11.2 Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 15
Klensin, et al. Expires January 18, 2006 [Page 3]
Internet-Draft Registration Policies July 2005
1. Introduction
For many years, the IETF has maintained, via the IANA registries of
protocol and parameter names and numbers. The original purpose of
these registries was to ensure that different methods and options are
properly identified and distinguished. Registration did not imply
approval of the technology in the corresponding protocol. Instead,
registration represented only the desire to keep distinct options
identified, separated, and public to avoid conflicts.
In recent years, the previous very general instructions to the IANA
about registrations have been superceded by the inclusion of specific
instructions in RFCs that define IETF protocols. These instructions
have included rules for the establishment of the relevant registries
themselves and details on how requests should be submitted, and new
values defined, for any paramaters defined by the RFC. In addition a
number of RFCs have been produced to provide instructions for IETF
protocols that were defined before such instructions began to be
included. Examples of those RFCs containing registration
instructions include [RFC2780], [RFC2939], [RFC3171], [RFC3228],
[RFC3383], [RFC3438], [RFC3474], [RFC3475], [RFC3476], [RFC3575],
[RFC3737], [RFC3818], [RFC3968], and [RFC3969]. These instructions,
coupled with increased perceptions of scarcity in the number spaces
associated with some parameters, have led to a shift in emphasis from
"registration to keep identifiers unique" and toward evaluations of
the quality of proposals and preferences about protocol design.
The distinction between requiring clarity and lack of obvious
conflict in a registration and blocking one unless the quality of the
underlying protocol was adequate was, in retrospect, further confused
by [RFC2434] (which describes elements of the registration model) in
different places, as
o "To insure that such quantities have consistent values and
interpretations in different implementations, their assignment
must be administered by a central authority." (abstract, repeated
in first paragraph of section 1)
o "... preferred way of insuring review, and is particularly
important if any potential interoperability issues can arise.
[...] A new option may define fields that need to be parsed and
acted on, which (if specified poorly) may not fit cleanly with the
architecture of other options or the base protocols on which they
are built." (section 2)
o "Even when the space is essentially unlimited, however, it is
usually desirable to have a minimal review to prevent the hoarding
of or unnecessary wasting of a space." (section 2)
Klensin, et al. Expires January 18, 2006 [Page 4]
Internet-Draft Registration Policies July 2005
RFC 2434 was used as the primary guideline for the RFCs listed above
that define IANA considerations for particular protocols. All three
of the above statements are consistent with other text in RFC 2434,
but the intent of the review is left open. In other words, it
specifies how a review is to be performed, but not the criteria to be
used. The present document argues that the apparent recent shift
from "evaluate a registration request for clarity and to avoid
interoperability problems" is undesirable and explicitly sets out
evaluation principles for registrations. While it may be completely
reasonable to require some specific level of approval of a protocol
with an associated parameter value, especially when the specification
for that allocation explicitly designates IETF approval and
endorsement (see Section 4), this should not be used as a
justification to require "approval" of registrations in general. For
registrations, the principal reasons for review are to ensure
adequate quality in the definitions to permit interoperability, to
avoid redundant or spurious registrations, and to provide those who
request the registrations an opportunity for non-binding IETF
community advice on the nature of the parameters being proposed for
registration or the protocol elements associated with them. A
secondary, but still important, reason involves verification that the
proposed protocol does not contain elements that are likely to cause
serious harm to the Internet. However, the threshold for rejecting a
registration on the basis of "serious harm" should be very high and
represent broad and obvious community consensus. This is the case
first because there might otherwise be suspicion that a claim of harm
was being used to try to block an unpopular protocol or to give a
favored one some advantage. Second, from a registration standpoint,
the best way to handle a dangerous protocol may be to give it clear
and distinct parameter values so its effects can be easily and
accurately identified and quarantined.
It should also be clear from experience with Peer-to-Peer protocols
and other that the IETF does not and cannot control introduction and
use of "non-standard" protocols. So registration is in some sense
only a courtesy to the community. P2P protocols freely violate norms
on the use of particular protocol identifiers and parameters but
since the software often has but a single source, there is no
confusion FOR THOSE INSTANCES of the software that comes from the
same source and uses the same "conventions" albeit non-standard and
even conflicting with standards.
This document articulates and clarifies the principles that (i) the
reasons for evaluation of registration requests is to ensure a
minimum quality of definition, (ii) any assertion of a danger to the
Internet or to the stable operation of other protocols (especially
IETF Standards Track ones) must by supported by a public discussion
to which all relevant parties can contribute, and (iii) that any
Klensin, et al. Expires January 18, 2006 [Page 5]
Internet-Draft Registration Policies July 2005
assertions of scarcity to restrict registrations MUST be accompanied
by a plan for eliminating the scarcity problem or a conclusion,
supported by IETF consensus, that it is not possible to do so and a
corresponding rationing plan for the remaining space. These
principles derive from the assumption that growth and innovation on
the Internet continue to be core values of the IETF and the Internet
community.
In summary, unless the "scarcity" rules of Section 3 apply, this
document updates all "IANA registration" documents and "IANA
considerations" sections of documents to clarify the point that
registration review is to focus on the issues above, rather than on
concerns about, e.g., whether one protocol approach is better than
another one.
2. Registration Principle: Clarity of Definition
By longstanding IANA tradition, almost all protocol number or
parameter registrations must be associated with a description of what
the parameter represents. As mentioned in RFC 2434, while those
descriptions are normally public, the IETF and IANA have sometimes
made provisions for non-public definitions. But, in all cases, the
definitions must be sufficiently clear to avoid any interoperability
problems. Over the years, IANA has regularly sent registration
requests back to the originator for clarification. Today, part of
the purpose of review of registration requests in the IETF is to make
determinations about whether an appropriate level of clarity has been
achieved and about whether the documentation supplied is adequate.
3. Registration Principle: Allocating Scarcity
As suggested in section 2 of [RFC2434], the size of a name space in
which parameters are to be allocated determines whether care must be
taken "to insure that the space doesn't become exhausted". However,
that level of care MUST NOT be interpreted or implemented in an
attempt to apply a single standard of taste or style to the Internet
or otherwise as a mechanism for attempting to suppress innovation. A
limited space requires diligent evaluation of requests to avoid
spurious or vanity registrations and unnecessary ones, including
registrations that are unlikely to ever be used. However, unless
extraordinary circumstances arise, such evaluation must be carried
out on the assumption that the size of the name space is, and will
remain, adequate for all legitimate registrations of values that will
be used with the associated protocols.
3.1 Scarcity in Parameter Spaces
The size requirements for a particular name space may occasionally be
Klensin, et al. Expires January 18, 2006 [Page 6]
Internet-Draft Registration Policies July 2005
underestimated, creating a requirement to minimize allocations and
registrations in that particular name space to avoid a clear danger
of running out of the space. If that situation arises for a
particular name space, and its existence is confirmed by the IESG
after an IETF review and Last Call as described in [RFC2026], then
new registrations may be temporarily restricted to those required to
meet the needs of IETF protocol development. However, such
restrictions MUST NOT be applied without initiation of a plan to
evaluate and, if appropriate, eliminate the scarcity, as discussed in
the next subsection.
3.2 Scaling and Scarcity Reduction
Difficulties with scaling are always a significant risk factor on the
Internet, with regard to both protocol design and administrative
procedures. When a parameter field is of fixed length, estimates
must be made, sometimes under considerable uncertainty and with high
costs associated with incremental size, as to how much parameter
capacity is needed. If such an estimate is incorrect and a
significant danger arises of running out of space, "conservation",
i.e., restrictions on registrations or allocations to save space,
will delay the date on which no further space is available, but will
not eliminate the risk of that occurring. Because of the damaging
effects on Internet innovation of rejecting otherwise-legitimate
registrations because of name space exhaustion, a decision that a
name space is facing a capacity crisis MUST BE made explicitly by the
community, as outlined above, and MUST BE associated with a plan to
expand the relevant name space unless that is deemed to be infeasible
(see below). A plan to expand the name space MAY take the form of
chartering a Working Group or creating an IAB workshop to develop a
plan within an appropriate time, or other approaches may be used.
A determination that the expansion of a name space is infeasible MUST
include criteria for making allocations in the balance of the
existing space and those criteria must be fair and balanced. The
determination of infeasibility and the allocation plan MUST represent
the consensus of the IETF community, determined through the same
mechanisms used to approve a document as a BCP (see [RFC2026]).
It is the explicit intent of this specification that registration
requests not be rejected for reasons of name space shortages unless
either an effort has been initiated to eliminate the shortage or a
formal determination has been made by the community that it is
infeasible or undesirable to do so. Nothing in this document should
be taken as requiring that every limited name space must be expanded,
only that careful consideration of what to do about the scarcity
situation be initiated, and initiated in a way that is visible and
accessible for community participation, immediately upon a
Klensin, et al. Expires January 18, 2006 [Page 7]
Internet-Draft Registration Policies July 2005
determination of scarcity and that the consideration process be
diligently pursued until some consensus conclusion is reached.
3.3 Legitimacy of Registration Requests
[[Note in Draft: This subsection is temporary.]]
Obviously, it must be possible for the IANA and the registration
evaluation process to protect against denial of service attacks by
virtue of a perpetrator registering as many parameters as possible so
as to exhaust the address space. Since that issue exists whether or
not this specification is accepted, it should be addressed generally
in RFC 2434bis and more specifically in individual registry
specification documents or sections. See Section 6.
4. Multiple category or arc registrations
In a number of cases, registration procedures or protocols have
provided for registrations in a number of different categories, where
those categories are associated with different levels of requirements
for registration but where interoperability may be achieved by the
use of any of the categories. Examples of this approach include the
distinction between "user" and "system" port numbers most recently
described in [RFC2780] and the distinctions among the various
registration arcs for media type registrations described in
[RFC2048].
A decision by the IESG or other designated party to require that a
registration be made in a different arc or subsidiary name space than
was proposed is not to be considered a rejection of the registration
request under the terms of this document.
5. Interpretation of Requirements for IESG Review or Standards Action
A requirement for IESG approval, Standards Action, or RFC Publication
implies that IESG approval is an acceptable alternative to the other
two, not an exceptional case unless the requirement contains
additional provisions specifying the conditions for IESG review and
approval. Because, for reasons discussed above, the action on a
registration request SHOULD BE to permit the registration unless
special circumstances apply, the IESG MUST NOT deny a registration
request for other than reasons of clarity without an IETF Last Call
and IETF consensus that the rejection is appropriate for identified
reasons consistent with those discussed in this document. If a
registration request is denied for any reason, that reason must be
stated explicitly and the decision may be appealed under the
procedures specified in [RFC2026] or its successor(s).
Klensin, et al. Expires January 18, 2006 [Page 8]
Internet-Draft Registration Policies July 2005
Inevitably, almost any of the procedures discussed above or in RFC
2434, may result in delays as the application is evaluated. In the
spirit of community comment, input, and consensus, feedback to those
requesting an allocation is desirable and is to be encouraged.
Registration delays while such discussions are ongoing are entirely
appropriate as long as they do not cause unreasonable delays once the
feedback and discussion processes runs their effective course. Of
course, nothing in this document prevents an applicant from
voluntarily withdrawing a registration request at any time that is
deemed appropriate.
6. Reflections on 2434bis
A revision of RFC 2434, known as [RFC2434bis] is being developed.
This section discusses some important interactions between the model
of that document and the one presented here.
6.1 Designated Experts
2434bis is fairly non-specific about the amount of authority that is
reasonably delegated and for what purposes. This document takes the
position that individual decisions, taken out the view of the
community, should be significantly constrained with regard to both
subject matter and process. In particular, designated experts are
seen as appropriate as managers of discussion and feedback and to
evaluate clarity of a specification and not as a decision focus on
the appropriateness of a protocol or registration request. An
exception might be made when the expert is given specific guidance
from the community, but this document views even that as a high-risk
situation.
More generally, designated experts are appropriate only in situations
in which it is reasonable to assume that feedback --on both the
registration and the underlying protocol is sought by those who
request the registration and where that feedback is seen by all
parties as an important part of the process. As one example, a
designated expert may be an appropriate source or channel of advice
to both the requester and other other review bodies on the clarity of
a specification.
The designation and use of such experts is not appropriate for
registries that are, or are likely to be, associated with significant
controversy (of which declared scarcity is almost always an
instance). When controversies about registrations exist or can be
anticipated, an open, public process with community involvement and
practical opportunity for timely appeals is almost always more
appropriate.
Klensin, et al. Expires January 18, 2006 [Page 9]
Internet-Draft Registration Policies July 2005
6.2 Override Procedure
RFC2434bis-02 contains provisions for an override procedure in
section 4.3. The position of this document is that, while such
procedures may be necessary and appropriate, they should be exposed
to full view of the community so that timely feedback and, if
necessary, appeal is possible. Consequently, if the override
procedure is invoked, the IESG should notify the community that it is
being done and, unless the situation involves severe time
constraints, at least a brief Last Call or other request for
community comments should be conducted on the proposed action.
6.3 Denial of Service Attacks
At least in principle, it is possible to attack any registry by
attempting massive registration of names or parameters so as to use
up all of the available space. 2434bis should address this issue, at
least to the extent of recommending that specifications that
establish registries advise on how such attacks are to be repelled
for those registries.
6.4 Appeals
RFC 2434bis prohibits appeals beyond the IAB. There appears to be
little or no justification for barring such appeals if a claim is
made that the procedures are flawed or inadequate.
7. Internationalization Considerations
This document specifies IETF procedures and does not interact with
internationalization.
8. IANA Considerations
This document specifies IETF and IESG considerations in recommending
actions to IANA. It recommends that, when the IETF concludes that
the protocol, extension, or option associated with a registration
request is problematic or dangerous, the entry in the IANA registry
should be annotated to identify the concern and, when appropriate,
point to documentation or other materials that will better explain
the concern or alternatives that might be less problematic. While
this document specifies no particular registry actions for IANA, IANA
should be prepared for requests from the IETF to annotate registry
entries in that way.
9. Security considerations
This document specifies IETF procedures. It should have no direct
Klensin, et al. Expires January 18, 2006 [Page 10]
Internet-Draft Registration Policies July 2005
impact on Internet security. It does, however, firmly advocate the
principle that it is preferable for options or extensions that could
pose security or operational risks to be throughly documented and
carefully identified in preference to hiding them and hoping that
they will disappear.
10. Acknowledgements
Comments were received on discussion leading to this document, or on
a preliminary draft, from Bob Braden, Dave Crocker, Spencer Dawkins,
Ned Freed, John Loughney, and others that contributed to text in this
document and are greatly appreciated.
Appendix A. Changes from previous version
[[Note in draft: This section to be removed before RFC publication.]]
Changes from -00.
1. Added new material to discuss impact with and on RFC2434bis as
Section 6
2. Made several small changes to clarify that name space expansion
is not a requirement, only that serious consideration of the
issue be initiated as soon as scarcity is noted.
3. Made several small changes to clarify that delays in registration
to obtain feedback and to discuss the registration with the
requestor and the community are appropriate as long as they are
not unreasonably prolonged.
11. References
11.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
11.2 Informative References
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Klensin, et al. Expires January 18, 2006 [Page 11]
Internet-Draft Registration Policies July 2005
[RFC2434bis]
Narten, T. and B. Carpenter, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-02.txt (work
in progress), June 2005.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", BCP 57, RFC 3228,
February 2002.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label Switching
(GMPLS) Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC 3474,
March 2003.
[RFC3475] Aboul-Magd, O., "Documentation of IANA assignments for
Constraint-Based LSP setup using LDP (CR-LDP) Extensions
for Automatic Switched Optical Network (ASON)", RFC 3475,
March 2003.
[RFC3476] Rajagopalan, B., "Documentation of IANA Assignments for
Label Distribution Protocol (LDP), Resource ReSerVation
Protocol (RSVP), and Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) Extensions for Optical UNI
Signaling", RFC 3476, March 2003.
Klensin, et al. Expires January 18, 2006 [Page 12]
Internet-Draft Registration Policies July 2005
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the
Registry of Remote Monitoring (RMON) MIB modules",
RFC 3737, April 2004.
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point
Protocol (PPP)", BCP 88, RFC 3818, June 2004.
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Header Field Parameter Registry for the Session
Initiation Protocol (SIP)", BCP 98, RFC 3968,
December 2004.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
Email: john-ietf@jck.com
Vinton G. Cerf
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
USA
Phone: +1 703 886 1690
Email: vinton.g.cerf@mci.com
Klensin, et al. Expires January 18, 2006 [Page 13]
Internet-Draft Registration Policies July 2005
Scott Bradner
Harvard University
29 Oxford St
Cambridge, MA 02138
US
Phone: +1 617 495 3864
Email: sob@harvard.edu
Klensin, et al. Expires January 18, 2006 [Page 14]
Internet-Draft Registration Policies July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin, et al. Expires January 18, 2006 [Page 15]
