Skip to main content

Expectations of Implementers of IETF Protocols
draft-housley-implementer-obligations-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Russ Housley
Last updated 2014-05-09 (Latest revision 2013-09-10)
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources
Stream WG state (None)
Document shepherd (None)
IESG IESG state In Last Call
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jari Arkko
Send notices to housley@vigilsec.com, draft-housley-implementer-obligations@tools.ietf.org
IANA IANA review state IANA - Review Needed
draft-housley-implementer-obligations-01
INTERNET-DRAFT                                                R. Housley
Intended Status: Informational                            Vigil Security
Expires: 10 March 2014                                 10 September 2013

             Expectations of Implementers of IETF Protocols
               <draft-housley-implementer-obligations-01>

Abstract

   By choosing to implement an IETF protocol, one is expected 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                                         10 September 2013

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   This document provides advice to implementers of IETF protocols to
   improve interoperability of their implementations.

   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, an implementor is
   expected to:

      (1) Follow the protocol specification;
      (2) Follow associated Best Current Practices (BCPs); and
      (3) Follow associated IANA registry practices.

   When implementers meet these expectations, protocols interoperate as
   intended by the IETF.

   These exceptions reflect the fundamental philosophy of the IETF.
   That is, interoperability is achieved when people choose to
   cooperate.  By taking these actions one can expect to achieve greater
   interoperability with others.

2.  First Expectation: 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 surprises 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.

   Many protocol specifications are living documents; things that change

Housley                                                         [Page 2]
INTERNET-DRAFT                                         10 September 2013

   over time.  An implementer needs to maintain their implementation
   into the future.  It is not sufficient to do an initial
   implementation of the protocol.  One needs to apply changes as they
   come out.  The most obvious and urgent example involves specification
   revisions that fix security issues that are found after the initial
   publication of a protocol specification.

3.  Second Expectation: 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
   common experience when using the protocol, regardless of their point
   of attachment to the Internet.

   Sometimes BCPs are referenced in the protocol specification.  Often
   the implementer needs to look through the BCP index to find related
   BCPs.

4.  Third Expectation: 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 expected 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.

Housley                                                         [Page 3]
INTERNET-DRAFT                                         10 September 2013

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 improve interoperability, and
   these actions may also reduce security incidents due to incomplete
   protocol implementations.

   It is not sufficient to do an initial implementation of the protocol.
   Maintenance is needed to apply changes as the come out in the future,
   especially to fix security issues that are found after the initial
   publication of a protocol specification.

   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, 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.

7.  Acknowledgements

   Thanks to the people that reviewed this document and suggested
   important improvements, including Bernard Aboba, Richard Barnes,
   Scott Brim, John Curran, Lars Eggert, Adrian Farrel, Stephen Farrell,
   and Joel Jaeggli.

8.  References

8.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.

8.2.  Informative References

   [RFC760]   Postel, J., "DoD standard Internet Protocol", RFC 760,
              January 1980.

Housley                                                         [Page 4]
INTERNET-DRAFT                                         10 September 2013

Author's Address

   Russ Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley@vigilsec.com

Housley                                                         [Page 5]