One document matched: draft-iesg-vendor-extensions-01.txt
Differences from draft-iesg-vendor-extensions-00.txt
INTERNET-DRAFT Scott O. Bradner
<draft-iesg-vendor-extensions-01.txt> Harvard University
Thomas Narten
IBM
October 27, 2003
Considerations on the Extensibility of IETF protocols
<draft-iesg-vendor-extensions-01.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document discusses issues related to the extensibility of IETF
protocols, including when it is reasonable to extend IETF protocols
with little or no review, and when extensions need to be reviewed by
the larger IETF community. The document also recommends that major
extensions to IETF protocols only take place through normal IETF
processes or in coordination with the IETF.
Contents
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Principles............................................... 2
draft-iesg-vendor-extensions-01.txt [Page 1]
INTERNET-DRAFT October 27, 2003
3. Recommendation........................................... 4
4. Examples................................................. 6
4.1. RADIUS Vendor-Specific Attributes................... 6
4.2. LDAP Schema Extensions.............................. 6
4.3. L2TP Extensions..................................... 6
5. IANA Considerations...................................... 7
6. Security Considerations.................................. 7
7. Acknowledgments.......................................... 7
8. Informative References................................... 7
9. Editor's Addresses....................................... 7
1. Introduction
When developing protocols, quite a few IETF working groups have made
facilities whereby these protocols can be extended in the future.
Vendors, other standards development organizations and technology
fora have used those facilities. Sometimes the result is non-
interoperability or poorly designed mechanisms.
The purpose of this memo is to make 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. The IESG is
presently applying some version of these principles when evaluating
proposals for new standards.
2. Principles
The most important principle driving this memo, and in fact the IETF
as a whole is the principle of:
o IETF Standards are intended to encourage and enable multiple
implementers to build implementations of protocols that will
interoperate.
It is a good principle to design extensible protocols but
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.
draft-iesg-vendor-extensions-01.txt [Page 2]
INTERNET-DRAFT October 27, 2003
If extensions to IETF protocols are done outside the IETF, experience
has shown that documentation of these extensions can be hard to
obtain, short-sighted design choices are sometimes made, basic
underlying architectural principals of the protocol are sometimes
violated, assessing the quality of the specification is hard, and
achieving interoperability can be hard.
It can be particularly difficult for a user to figure out who is at
fault and what to do about it if two pieces of software that both
claim to be implementations of an IETF standard do not work together.
Yet there are situations where extensions to IETF protocols can make
sense. There are two general ways in which protocols are extended.
Many (if not most) protocols are designed to carry opaque data of
some kind, where the protocol itself mostly doesn't care what the
contents of that data is. For example, DHCP [DHC] transports options,
but the contents of the option are generally of no concern to the
DHCP protocol itself. Many other protocols provide such a capability,
including OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc.
Important points to note about such extensions include:
o 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. Specifically, no changes are required to
existing and currently deployed implementations unless they want
to make use of the new data type.
o 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) [IANA-
CONSID].
The more interesting way in which protocols are extended is called a
major extension. 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
draft-iesg-vendor-extensions-01.txt [Page 3]
INTERNET-DRAFT October 27, 2003
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.
Exactly what is considered to be a major extension and what is
considered normal usage will depend on the specific protocol and the
proposed extension at issue. Even for protocols designed to carry
opaque data, whether a proposed usage qualifies as a major extension
may involve considerable debate. But it is important that such
discussion involve the IETF community of experts knowledgeable about
the protocol's architecture and existing usage in order to fully
understand the implications of a proposed extension.
Major extensions should be well, and publicly, documented and
reviewed by the IETF community to be sure that the extension does not
undermine basic assumptions and safeguards designed into the
protocol, such as security functions, or undermine its architectural
integrity.
3. Recommendation
The following principles are the main guiding principles concerning
extensions to IETF protocols:
o Extensibility features in IETF protocols should be limited to
providing just the amount of extensibility that is seen as
required. Protocols should not be extensible just for the sake
of being extensible.
o All major extensions to IETF protocols should be done with
adequate review by or direct involvement of the IETF.
o The decision on whether an extension is major or minor should be
done with the direct involvement of the IETF.
Ideally, extensions should be done by IETF working groups using
draft-iesg-vendor-extensions-01.txt [Page 4]
INTERNET-DRAFT October 27, 2003
normal IETF processes or, if a working group does not consider a
proposed extension to be general enough, at least documented in an
IETF informational RFC that is reviewed by the working group and the
IESG. No individual, vendor, standards development organization or
forum should be able create what is viewed to be a major extension to
an IETF protocol on its own and legitimately be able to claim that
implementations that implement the extension are compliant to the
IETF specification, or that the extension is a part of the IETF
specification.
It should be noted that the second bullet above leads to the
possibility of a denial-of-service issue, as it implies that any
major extension should be done within or reviewed by the IETF. At the
same time, the IETF may not have the resources to develop (or even
review) every possible extension and will need to prioritize the use
of its resources. Thus, it is important to be pragmatic in terms of
what work can and will be taken on by the IETF, and to set
expectations accordingly. In those cases where the IETF is unable to
take on a particular work item, it should be understood that the IETF
will review extensions to its technology that it is asked to publish,
and may approve publication only after changes are made, or may not
agree to publish the extension at all. Thus, anyone proposing
extensions outside of the IETF is advised to coordinate any such
extensions with the IETF as early as possible. Waiting until the last
minute before consulting with the IETF and then assuming quick
publication of a finished extension is not recommended.
It should also be noted that there are limits to what the IETF can do
to prevent others from improperly extending protocols outside of the
IETF. The IETF's leverage is limited to such actions as recommending
against publication of an extension or denying the assignment of an
IANA code point (e.g., when relevant IANA considerations guidelines
apply). There is also the real possibility that the development of a
poor extension will generate ill-will in the IETF community, which
can greatly complicate subsequent attempts by the offending group to
carry out future work in the IETF, whether directly related to the
particular extension or not.
IETF protocols should not be designed to encourage the definition of
major extensions outside the IETF process. 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 [IANA-CONSID].
draft-iesg-vendor-extensions-01.txt [Page 5]
INTERNET-DRAFT October 27, 2003
4. Examples
This section discusses some specific examples, as it is not always
immediately clear what constitutes a major extension.
[note: to be completed, are the following good and representative
of some of the debates that have been had?]
4.1. RADIUS Vendor-Specific Attributes
4.2. LDAP Schema Extensions
4.3. 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 M-
bit.
draft-iesg-vendor-extensions-01.txt [Page 6]
INTERNET-DRAFT October 27, 2003
5. IANA Considerations
None.
6. Security Considerations
Insufficiently reviewed extensions can easily lead to protocols with
significant security vulnerabilities. In addition, a poorly designed
extension can circumvent strong security features that the IETF
designed into a protocol.
7. Acknowledgments
The initial version of this document was put together by the IESG.
8. Informative References
[IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC
2661, August 1999.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
9. Editor's Addresses
Scott Bradner
Harvard University
29 Oxford St
Cambridge MA 02138
USA
Phone: +1 617-495-3864
EMail: sob@harvard.edu
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
draft-iesg-vendor-extensions-01.txt [Page 7]
INTERNET-DRAFT October 27, 2003
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
draft-iesg-vendor-extensions-01.txt [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-22 14:47:44 |