Obligations of Implementers of IETF Protocols
draft-housley-implementer-obligations-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Russ Housley | ||
| Last updated | 2013-09-09 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Reviews | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-housley-implementer-obligations-00
INTERNET-DRAFT R. Housley
Intended Status: Informational Vigil Security
Expires: 9 March 2014 9 September 2013
Obligations of Implementers of IETF Protocols
<draft-housley-implementer-obligations-00>
Abstract
By choosing to implement an IETF protocol, one accepts an obligation
to follow the specification, associated best current practices, and
IANA registry practices.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Housley [Page 1]
INTERNET-DRAFT 9 September 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
IETF protocols foster interoperability. This interoperability brings
great benefits. IETF protocols are building blocks for many products
and services, and they enable innovation. Yet, IETF standards are
voluntary standards. No one is required to implement them.
Implementation is a choice. By making this choice, implementor
accept three obligations:
(1) Follow the protocol specification;
(2) Follow associated Best Current Practices (BCPs); and
(3) Follow associated IANA registry practices.
Following these obligations allow protocols to interoperate as
intended by the IETF.
2. First Obligation: Follow the Protocol Specification
To repeat, IETF protocols foster interoperability, and this
interoperability brings great benefits. If one does not follow the
protocol specification, then interoperability is jeopardized.
Of course, one should follow Postel's Law while implementing the
specification:
In general, an implementation should be conservative in its
sending behavior, and liberal in its receiving behavior. [RFC760]
Following Postel's Law simply increases interoperability. One should
be careful to send well-formed protocol data units and carefully
follow elements of procedure; which avoids surprised for
communicating peers that use other implementations. On the other
hand, one should accept any protocol data unit that can be
interpreted, which heightens interoperability in the face of
technical errors by others.
3. Second Obligation: Follow Associated Best Current Practices
Best Current Practices (BCPs) about IETF protocols (not the BCPs that
define IETF processes and procedures) are intended to standardize
practices.
The Internet is composed of networks operated by a great variety of
organizations, with diverse goals and rules. By following the BCPs,
implementers, operators, and administrators are able to provide a
Housley [Page 2]
INTERNET-DRAFT 9 September 2013
common experience when using the protocol, regardless of their point
of attachment to the Internet.
4. Third Obligation: Follow Associated IANA Registry Practices
Many IETF protocols use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployed, new values may be needed. To ensure that such quantities
have consistent values and interpretations across all
implementations, assignment is administered by a central authority,
the Internet Assigned Numbers Authority (IANA). In order to manage a
namespace (which might also be called an assigned number, an assigned
value, a code point, a a protocol constant, or a protocol parameter)
in support of a particular IETF protocol, IANA is given instructions
and conditions under which new values should be assigned or when
modifications to existing values can be made.
Implementers are obligated to follow the IANA registry practices
associated with the protocol, especially in the assignment of new
values. By following these practices, other implementations will
learn about new values and make the appropriate updates to handle
them properly.
Note that IP addresses and the top levels of the DNS name hierarchy
are managed in IANA registries [RFC2860]. Please follow the IANA
registry practices for the assignment of special IP addresses and
top-level DNS names in the rare cases where such values are needed.
5. Security Considerations
This document calls for implementers to follow the protocol
specification, follow associated best current practices, and follow
IANA registry practices. These actions should greatly improve
interoperability, and these actions may also reduce security
incidents due to incomplete protocol implementations.
Security processing is an exception to Postel's Law. For example, a
password that is close, but not exactly right, is not sufficient to
gain access. Processing associated with integrity, authentication,
access control, non-repudiation, and confidentiality mechanisms
cannot be forgiving.
6. IANA Considerations
{{ RFC Editor: Please remove this section prior to publication. }}
This document has no actions for IANA.
Housley [Page 3]
INTERNET-DRAFT 9 September 2013
7. References
7.1. Normative References
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
7.2. Informative References
[RFC760] Postel, J., "DoD standard Internet Protocol", RFC 760,
January 1980.
Author's Address
Russ Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Housley [Page 4]