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