Network Working Group B. Carpenter (ed)
Internet-Draft IBM
Intended status: Informational October 12, 2006
Expires: April 15, 2007
Design issues for protocol extensions
draft-carpenter-extension-recs-00
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 April 15, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document discusses issues related to the extensibility of IETF
protocols, with a focus on the architectural design considerations
involved. Concrete case study examples are included.
Carpenter (ed) Expires April 15, 2007 [Page 1]
Internet-Draft Design issues for protocol extensions October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Interoperability . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use of Registered Values . . . . . . . . . . . . . . . . . 4
2. Principles and Guidelines for Robust Extensions . . . . . . . 4
2.1. Achieving Interoperability . . . . . . . . . . . . . . . . 4
2.2. When is an Extension Minor? . . . . . . . . . . . . . . . 5
2.3. Specific Risks with Major Extensions . . . . . . . . . . . 6
3. Considerations for the Base Protocol . . . . . . . . . . . . . 6
4. Running Code Must Run Right . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Change log [RFC Editor: please remove this section] . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9
A.1. Already documented cases . . . . . . . . . . . . . . . . . 10
A.2. RADIUS Extensions . . . . . . . . . . . . . . . . . . . . 10
A.3. RSVP Extensions . . . . . . . . . . . . . . . . . . . . . 11
A.4. TLS Extensions . . . . . . . . . . . . . . . . . . . . . . 11
A.5. L2TP Extensions . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Carpenter (ed) Expires April 15, 2007 [Page 2]
Internet-Draft Design issues for protocol extensions October 2006
1. Introduction
For the origins of this draft, please see the Acknowledgements
section. Authorship will be updated.
When an initial protocol design is extended, there is always a risk
of introducing interoperability defects, security defects, etc.,
along with the additional functionality. This risk is especially
high if the extension is performed by a different team than the
original designers, who may stray outside implicit design constraints
or assumptions. This document aims to describe technical guidelines
for protocol extensions that will minimize such risks. Although
written in general terms, it is largely aimed at people considering
extending an IETF protocol, whether as an IETF activity or elsewhere.
This document is informative. Formal procedures for extending IETF
protocols are discussed in [I-D.carpenter-protocol-extensions].
IETF protocols typically include mechanisms whereby they can be
extended in the future. It is of course a good principle to design
extensiblity into protocols; one common definition of a successful
protocol is one that becomes widely used in ways not originally
anticipated. Well-designed extensibility mechanisms facilitate the
evolution of protocols and help make it easier to roll-out
incremental changes in an interoperable fashion. At the same time,
experience has shown that extensibility features should be limited to
what is clearly necessary when the protocol is developed and any
later extensions should be done carefully and with a full
understanding of the base protocol, existing implementations, and
current operational practice.
1.1. Interoperability
Designers of extensions must assume the high likelihood of a specific
system using the extension having to interoperate with other people's
Internet systems; experience shows that software is often used
outside the particular special environment it was originally intended
for.
Thus, an extension will lead to interoperability failures unless the
extended protocol correctly supports all mandatory and optional
features of the unextended base protocol, and implementations of the
base protocol operate correctly in the presence of the extensions.
Another aspect is that that mechanisms included to allow the
extension of protocols must not be used to create incompatible forks
in development instead. Ideally, the protocol mechanisms for
extension and versioning should be sufficiently well described that
Carpenter (ed) Expires April 15, 2007 [Page 3]
Internet-Draft Design issues for protocol extensions October 2006
compatibility can be assessed later.
Thus we observe that a key requirement for interoperable extension
design is that the base protocol must be well designed for
interoperability. This is further discussed below.
Finally, it should be noted that protocol variations - specifications
that look very similar to the original but are actually different -
are of course even more harmful to interoperability than extensions.
In general, such variations should be avoided. If they cannot be
avoided, as many of the following considerations as possible should
be applied, to minimize the damage to interoperability.
1.2. Use of Registered Values
An extension is often likely to make use of additional values added
to an existing IANA registry (in many cases, simply by adding a new
"TLV" (type-length-value) field). To avoid conflicting usage of the
same value, it is essential that all new values are properly
registered by the applicable procedures, including expert review
where applicable (see BCP 26, [RFC2434]).
2. Principles and Guidelines for Robust Extensions
This document makes explicit some guiding principles based on the
community's experience with extensibility mechanisms. One of the key
principles is that protocols should not be made more extensible than
clearly necessary at inception, and that proposed extensions should
be reviewed by subject-matter experts familiar with the protocol
itself and how it is used in currently deployed systems. The formal
aspects of this are covered in [I-D.carpenter-protocol-extensions].
2.1. Achieving Interoperability
The importance of extending protocols only in carefully thought-out
ways is driven by the overall goal of acheiving good
interoperability. Good interoperability stems from a number of
factors, including:
o having a well-written spec, that makes clear and precise what an
implementor needs to implement and what impact each individual
operation (e.g., a message sent to a peer) will have when invoked.
However, while necessary, a well-written spec is not by itself
sufficient to result in good interoperability.
o learning lessons from deployment, including understanding what
current implementations do and how a proposed extension will
interact with deployed systems.
Carpenter (ed) Expires April 15, 2007 [Page 4]
Internet-Draft Design issues for protocol extensions October 2006
o having an adequate transition story for deploying the new
extension. What impact will the proposed extension have on
implementations that do not understand it? Is there a way to
negotiate or determine the capabilities of a peer?
o being architecturally compatible with the base protocol. For
example, does the extension make use of features as envisioned by
the original protocol designers, or is a new mechanism being
invented?
o respecting underlying architectural or security assumptions
(including those that may not be well-documented, those that may
have arison as a result of operational experience, or those that
only became understood after the original protocol was published).
o will the proposed extension (or its proposed usage) operationally
stress existing implementations or the underlying protocol itself
if widely deployed?
o some protocols have become critical components of the Internet
infrastructure. Does the proposed extension (or its proposed
usage) have the potential for negatively impacting such
infrastructure to the point where explicit steps would be
appropriate to firewall existing uses from new ones?
o does the proposed extension extend the data model in a major way?
Does the extension fundamentally change basic assumptions about
data handling within the protocol? For example, do the extensions
reverse the flow of data, allow formerly static parameters to be
changed on the fly, add new data types or change assumptions
relating to the frequency of reads/writes?
o can the extended protocol negotiate with an unextended partner to
find a common subset of useful functions?
2.2. When is an Extension Minor?
The protocol is designed to carry such opaque data and no changes to
the underlying base protocol are needed to carry a new type of data.
Moreover, no changes are required to existing and currently deployed
implementations of the underlying protocol unless they want to make
use of the new data type.
Using the existing protocol to carry a new type of opaque data will
not impact existing implementations or cause operational problems.
Examples of minor extensions include the DHC vendor-specific option,
the enterprise OID tree for MIB modules, vnd. MIME types, and some
classes of (non-critical) certification extensions. Such extensions
can safely be made with minimal IETF coordination and are indicated
by having an IANA Considerations that allows assignments of code
points with minimal overhead (e.g., First Come First Served)
[RFC2434].
Carpenter (ed) Expires April 15, 2007 [Page 5]
Internet-Draft Design issues for protocol extensions October 2006
2.3. Specific Risks with Major Extensions
Major extensions have some or all of the following characteristics:
o Change or extend the way in which the basic underlying protocol
works, e.g., by changing the semantics of existing PDUs or
defining new message types that require implementation changes in
existing and deployed implementations of the protocols, even if
they do not want to make use of the new functions or data types.
o Change basic architectural assumptions about the protocol that
have been an assumed part of the protocol and its implementations.
o Lead to new uses of the protocol in ways not originally intended
or investigated, potentially leading to operational and other
difficulties when deployed, even in cases where the "on-the-wire"
format has not changed. For example, the overall quantity of
traffic the protocol is expected to carry might go up
substantially, typical packet sizes may increase compared to
existing deployments, simple implementation algorithms that are
widely deployed may not scale sufficiently or otherwise be up to
the new task at hand, etc.
All of these lead directly to a need for extremely close attention to
backward compatibility with implementations of the unextended
protocol, and to the inadvertent introduction of security or
operational exposures.
3. Considerations for the Base Protocol
Ideally, the document that defines a base protocol's extension
mechanisms will include guidance to future extension writers that
help them use extension mechanisms properly. It may also be possible
to define classes of extensions that need little or no review, while
other classes need wide review. The specific details will
necessarily be technology-specific.
As mentioned above, any mechanism for extension by versioning must
include provisions to ensure interoperability, or at least clean
failure modes. Imagine someone creating a protocol and using a
"version" field and populating it with a value (1, let's say), but
giving no information about what would happen when a new version
number appears in it. That's bad protocol design and description; it
should be clear what the expectation is and how you test it (e.g. 1.X
is compatible but 2 or greater is not expected to be).
Protocols commonly include one or more "reserved" fields, clearly
intended for future extensions. It is good practice to specify the
value to be inserted in such a field by the sender (typically zero)
and the action to be taken by the receiver when seeing some other
Carpenter (ed) Expires April 15, 2007 [Page 6]
Internet-Draft Design issues for protocol extensions October 2006
value (typically no action). If this is not done, future
implementation of new values in the reserved field may break old
software. Similarly, protocols should carefully specify how
receivers should react to unknown TLVs etc., such that failures occur
only when that is truly the desired result.
Protocols that permit easy extensions with minimal or no review, make
it likely that unreviewed extensions will be deployed and used in
practice. Consequently, protocols should not be made more extensible
than clearly necessary at inception, and the process for defining new
extensibility mechanisms must ensure that adequate review of proposed
extensions will take place before widespread adoption. In practice,
this means First Come First Served [RFC2434] and similar policies
should be used very carefully, as they imply minimal or no review.
In order to increase the likelihood that minor extensions are truly
minor, protocol documents should provide guidelines explaining how
they should be done. For example, even though DHCP carries opaque
data, defining a new option using completely unstructured data may
lead to an option that is (unnecessarily) hard for clients and
servers to process. In contrast, using widely-supported encoding
formats leads to better interoperability [XXX need ref]. Similarly,
SNMP MIB guidelines exist for defining the MIB objects that SNMP
carries [RFC4181].
Documents defining IETF protocols should carefully analyze and
identify which protocol components can be extended safely with
minimal or no community review and which need community review, and
then write appropriate IANA considerations sections that ensure the
appropriate level of community review prior to the assignment of
numbers. For example, the definition of additional data formats that
can be carried may require no review, while the addition of new
protocol message types might require a Standards Track action
[RFC2434]. Finally, the use of version numbers should be carefully
specified in order to favour interoperability or clean failure modes.
In a number of cases, there is a need for explicit guidance relating
to extensions beyond what is encapsulated in the IANA considerations
section of the base specification. The usefulness of [RFC4181] would
appear to suggest that protocols whose data model is likely to be
widely extended (particularly using vendor-specific elements) need a
Design Guidelines document specifically addressing extensions.
4. Running Code Must Run Right
Experience shows that it is insufficient to correctly specify
extensibility and backwards compatibility in an RFC. It is also of
importance that every implementation must fully respect the
Carpenter (ed) Expires April 15, 2007 [Page 7]
Internet-Draft Design issues for protocol extensions October 2006
compatibility mechanisms; if not, non-interoperable pairs of
implementations may arise. The TLS case study below shows how
important this may be.
5. Security Considerations
An extension must not introduce new security risks without also
providing an adequate counter-measure, and in particular it must not
inadvertently defeat security measures in the unextended protocol.
Thus, the security analysis for an extension needs to be as thorough
as for the original protocol - effectively it needs to be a
regression analysis to check that the extension doesn't inadvertently
invalidate the original security model.
6. IANA Considerations
This draft requires no action by IANA.
7. Acknowledgements
This document is heavily based on an earlier draft under a different
title by Scott Bradner and Thomas Narten.
That draft stated: The initial version of this document was put
together by the IESG in 2002. Since then, it has been reworked in
response to feedback from John Loughney, Henrik Levkowetz, Mark
Townsley, Randy Bush, Bernard Aboba and others.
Valuable comments and suggestions were made by Jari Arkko, Ted
Hardie, Loa Andersson...
The text on TLS experience was contributed by Yngve Pettersen.
This document was produced using the xml2rfc tool [RFC2629].
8. Change log [RFC Editor: please remove this section]
draft-carpenter-extension-recs-00: original version, 2006-10-12.
Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by
focussing on architectural issues; the more procedural issues in that
draft were moved to another document.
9. References
Carpenter (ed) Expires April 15, 2007 [Page 8]
Internet-Draft Design issues for protocol extensions October 2006
9.1. Normative References
[I-D.carpenter-protocol-extensions]
Carpenter, B., "Procedures for protocol extensions and
variations", draft-carpenter-protocol-extensions-04 (work
in progress), October 2006.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
and B. Rosen, "Change Process for the Session Initiation
Protocol (SIP)", BCP 67, RFC 3427, December 2002.
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", BCP 92, RFC 3932, October 2004.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
9.2. Informative References
[I-D.andersson-rtg-gmpls-change]
Andersson, L. and A. Farrel, "Change Process for
Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Protocols and Procedures",
draft-andersson-rtg-gmpls-change-04 (work in progress),
October 2006.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
Appendix A. Examples
[This is mainly raw material from the old draft, not yet edited
except for minimal reformatting from nroff to xml2rfc.]
This section discusses some specific examples, as it is not always
immediately clear what constitutes a major extension.
Carpenter (ed) Expires April 15, 2007 [Page 9]
Internet-Draft Design issues for protocol extensions October 2006
A.1. Already documented cases
There are certain documents that specify a change process for
specific IETF protocols:
The SIP change process [RFC3427]
The (G)MPLS change process [I-D.andersson-rtg-gmpls-change]
It is relatively common for MIBs, which are all in effect
extensions of the SMI data model, to be defined or extended
outside the IETF. BCP 111 [RFC4181] offers detailed guidance for
authors and reviewers.
A.2. RADIUS Extensions
The RADIUS [RFC2865] protocol was designed to be extensible via
addition of Attributes to a Data Dictionary on the server, without
requiring code changes. However, this extensibility model assumed
that Attributes would conform to a limited set of data types and that
vendor extensionns would be limited to use by vendors in situations
in which interoperability was not required. Recent developments have
stretched those assumptions.
[RFC2865] Section 6.2 defines a mechanism for Vendor-Specific
extensions (Attribute 26), and states that use:
"... should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of
RADIUS, where no interoperability is deemed useful."
However, in practice usage of Vendor-Specific Attributes (VSAs) has
been considerably broader than this; in particular, VSAs have been
used by SDOs to define their extensions to the RADIUS protocol.
This has caused a number of problems. Since the VSA mechanism was
not designed for interoperability, VSAs do not contain a "mandatory"
bit. As a result, RADIUS clients and servers may not know whether it
is safe to ignore unknown attributes. For example, [RFC2865] Section
5 states:
"A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type."
However, in the case where the VSAs pertain to security (e.g.
Filters) it may not be safe to ignore them, since [RFC2865] also
states:
"A NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is
unable to offer ARAP service MUST NOT implement the RADIUS attributes
Carpenter (ed) Expires April 15, 2007 [Page 10]
Internet-Draft Design issues for protocol extensions October 2006
for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an
unavailable service as an access-reject instead."
Since it was not envisaged that multi-vendor VSA implementations
would need to interoperate, [RFC2865] does not define the data model
for VSAs, and allows multiple subattributes to be included within a
single Attribute of type 26. However, this enables VSAs to be
defined which would not be supportable by current implementations if
placed within the standard RADIUS attribute space. This has caused
problems in standardizing widely deployed VSAs.
In addition to extending RADIUS by use of VSAs, SDOs have also
defined new values of the Service-Type attribute in order to create
new RADIUS commands. Since [RFC2865] defined Service-Type values as
being allocated First Come, First Served (FCFS), this essentially
enabled new RADIUS commands to be allocated without IETF review.
This oversight has since been fixed in [RFC3575].
A.3. RSVP Extensions
TBD
A.4. TLS Extensions
The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape
to be used to secure online transactions on the Internet. It was
later replaced by SSL v3, also developed by Netscape [[check this,
AFAIK IETF was, to some extent involved]]. SSL v3 was then further
developed by the IETF as the Transport Layer Security (TLS) protocol.
The SSL v3 protocol was designed to be expanded in several ways,
which have been inherited by TLS:
o New versions
o New cipher suites
o Compression
o Expanded handshake messages
o New record types
o New handshake messages
The protocol also defines how implementations should handle unknown
extensions.
Of the above extension methods, new versions and expanded handshake
messages have caused the most problems, although it is also known
that some implementations may have had problems when encountering
unknown record types and handshake messages unexpectedly in test
situations.
Carpenter (ed) Expires April 15, 2007 [Page 11]
Internet-Draft Design issues for protocol extensions October 2006
The new version support in SSL/TLS includes a capability to define
new versions of the protocol, while allowing newer implementations to
communicate with older implementations. As part of this
functionality some Key Exchange methods include functionality to
prevent version roll-back attacks.
The experience with this upgrade functionality in SSL and TLS is
decidely mixed.
o SSL v2 and SSL v3/TLS are not compatible. It is possible to use
SSL v2 protocol messages to intiate a SSL v3/TLS connection, but
it is not possible to communicate with a SSL v2 implementation
using SSL v3/TLS protocol messages.
o There are implementations that refuse to accept handshakes using
newer versions of the protocol than they support.
o There are other implementations that accepts newer versions, but
have implemented the version rollback protection incorrectly.
The SSL v2 problem have forced clients to use SSL v3 and TLS clients
to continue to use SSL v2 Client Hellos for their initial handshake
with almost all servers until 2006, much longer than would have been
desirable, in order to interoperate with old servers.
The problem with incorrect handling of newer versions has also forced
many clients to actually disable the newer protocol versions, either
by default, or by automatically disabling the functionality, to be
able to connect to such servers. Effectively, this means that the
version rollback protection in SSL and TLS is currently non-existent,
opening the possibility for attacks should one of the older version
prove to be vulnerable to a feasible man-in-the-middle attack.
SSL v3 and TLS also permitted expansion of the Client Hello and
Server Hello handshake messages. This functionality was fully
defined by the introduction of TLS Extensions, which makes it
possible to add new functionality to the handshake, such as the name
of the server the client is connecting to, request certificate status
information, indicate Certificate Authority support, maximum record
length, etc. Several of these extensions also introduces new
handshake messages.
It has turned out that many SSL v3 and TLS implementations that do
not support TLS Extensions, did not, as specified in the protocols,
ignore the unknown extensions, but instead failed to establish
connections.
Several of the implementations behaving in this manner are used by
high profile Internet sites, such as online banking sites, and this
has caused a significant delay in the deployment of clients
supporting TLS Extensions, and several of the clients that have
Carpenter (ed) Expires April 15, 2007 [Page 12]
Internet-Draft Design issues for protocol extensions October 2006
enabled support are using heuristics that allow them to disable the
functionality when they detect a problem.
Looking forward, the protocol version problem, in particular, can
cause future security problem for the TLS protocol. The strength of
the Digest algorithms (MD5 and SHA-1) used by SSL and and TLS is
weakening, and work is underway to define TLS 1.2 which will permit
new methods to be used in the protocol instead of the currently used
methods. If MD5 and SHA-1 weaken to the point where it is feasible
to mount successful attacks against older SSL and TLS versions, the
current error recovery used by clients would become a security
vulnerability.
The lesson to be drawn from this experience is that it isn't
sufficient to design extensibility carefully; it must also be
implemented carefully by every implementer, without exception.
A.5. L2TP Extensions
L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs
having no semantics to the L2TP protocol itself. However, it should
be noted that L2TP message types are identified by a Message Type AVP
(Attribute Type 0) with specific AVP values indicating the actual
message type. Thus, extensions relating to Message Type AVPs would
likely be considered major extensions.
L2TP also provides for Vendor-Specific AVPs. Because everything in
L2TP is encoded using AVPs, it would be easy to define vendor-
specific AVPs that would be considered major extensions.
L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP
messages containing AVPs they do not understand but that have the
mandatory bit set, are expected to reject the message and terminate
the tunnel or session the message refers to. This leads to
interesting interoperability issues, because a sender can include a
vendor-specific AVP with the M-bit set, which then cause the
recipient to not interoperate with the sender. This sort of behavior
is counter to the IETF ideals, as implementations of the IETF
standard should interoperate successfully with other implementations
and not require the implementation of non-IETF extensions in order to
interoperate successfully. Section 4.2 of the L2TP specification
[L2TP] includes specific wording on this point, though there was
significant debate at the time as to whether such language was by
itself sufficient.
Fortunately, it does not appear that the above concerns have been a
problem in practice. At the time of this writing, the authors are
unaware of the existance of vendor-specific AVPs that also set the
Carpenter (ed) Expires April 15, 2007 [Page 13]
Internet-Draft Design issues for protocol extensions October 2006
M-bit.
Author's Address
Brian Carpenter (ed)
IBM
8 Chemin de Blandonnet
1214 Vernier,
Switzerland
Email: brc@zurich.ibm.com
Carpenter (ed) Expires April 15, 2007 [Page 14]
Internet-Draft Design issues for protocol extensions October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Carpenter (ed) Expires April 15, 2007 [Page 15]