One document matched: draft-haas-code-point-reservation-bcp-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
    <!ENTITY rfc5226bis SYSTEM
    "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-leiba-cotton-iana-5226bis-11.xml">

]>

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="bcp" ipr="trust200902" docName="draft-haas-code-point-reservation-bcp-01">
<front>
	<title abbrev="Reservation Strategies for IETF Code Points">Reservation Strategies for the Zeroth and Last Code Points in IETF Registries and for Bit Field Registries</title>
	<author initials="J" surname="Haas" fullname="Jeffrey Haas" role="editor">
		<organization>Juniper Networks</organization>
		<address>
			<email>jhaas@juniper.net</email>
		</address>
	</author>
	<date month="September" day="14" year="2015"/>
	<area>General</area>
	<workgroup></workgroup>
	<keyword>IANA</keyword>
	<keyword>code-point</keyword>
	<abstract>
		<t>
		This document describes common code point reservation
		strategies for the zeroth and last code points in IANA-managed
		IETF registries and for bit-field registries.  This document
		additionally provides the reasoning to support these strategies
		and their adoption as Best Current Practices to be applied to
		all IETF registries.
		</t>
	</abstract>
</front>

<middle>

<section title="Requirements Notation">

<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119" />.
</t>
</section>

<section title="Introduction">
	<t>
	A fundamental component of networking protocols are the fields
	contained within their Protocol Data Units (PDUs), a.k.a. packets.
	The fields are typically enumerated and are often part
	of the common syntactic form of a Type, Length, Value (TLV) tuple.
	An allocation of one of these enumerated fields is a code point.
	</t>
	<t>
	When designing or extending a networking protocol, some thought must
	be put into the range of allowable values and format for these
	fields.  Additionally consideration must be given to how the
	allocation of the code points for these fields is managed.  Other
	documents, for example 
	<xref target="I-D.leiba-cotton-iana-5226bis"/>, are dedicated to
	strategies for the management of such code point registries.
	</t>
	<t>
	The range of allowable values must be large enough to accommodate
	not only immediate uses that are part of the design of a protocol or
	protocol extension, but must also provide room for future
	maintenance.  Some protocols that are meant to be used in highly
	constrained environments may also attempt to minimize the size of
	packets to conserve networking resources.  Thus, a balance between
	being small enough to conserve resources but large enough to permit
	future expansion provides a tension that protocol designers must
	navigate.
	</t>
	<t>
	One further matter for consideration for such code point registries
	is pre-reserving some values.  This document discusses a reasoning
	for the reservation of the zeroth and last code point in an integer
	field, and a general policy for the reservation of unused bits in
	bit-vectors.
	</t>
</section>


<section title="A Reservation Strategy for the Zeroth and Last Code-Points">
	<t>
	When designing a protocol, a design decision must be made for integer
	code-points as to how large to make its range.  Some protocols may
	prize density and thus elect for a small range, often a byte and
	perhaps less.  Other protocols may be dominated by a need for
	flexibility and expansion and use a large range, four bytes or larger.
	</t>

	<t>
	When creating new integer code-point registries, this document makes the following recommendation:

	<list style="symbols">
		<t>
		The zeroth entry of the new registry SHOULD be reserved.  This
		permits implementors to avoid the need of separate boolean
		state to represent that a code point has been set with the
		value zero.  It is RECOMMENDED that the reservation text
		should be of the form, "Reserved (not to be allocated)".
		</t>
		<t>
		The last entry of the new registry SHOULD be reserved.  This
		provides future maintainers of the protocol the ability to
		extend the functionality covered by the semantics of this code
		point when all other numbers may have otherwise been allocated.
		(See <xref target="I-D.leiba-cotton-iana-5226bis"/>, Section 6,
		"Reserved".)  It is RECOMMENDED that the reservation text
		should be of the form, "Reserved (for future use for
		registry extension)".
		</t>
	</list>
	</t>

	<t>
	Implementations MAY specify that the zeroth code point is explicitly
	prohibited in the protocol.  Experience in implementation, however, has
	suggested that fatal error conditions based on this behavior lend
	itself to a brittleness in the protocol with unforseen future
	consequences.
	</t>

	<t>
	Implementations SHOULD NOT explicitly treat the use of the last code
	point as an error condition outside the semantics otherwise specified
	within the protocol for an unused code-point. Making this value
	explicitly forbidden within the protocol eliminates its usefulness for
	future expansion in the presence of older implementations that do not
	understand the expanded semantic.  In other words, future proof your
	implementation.
	</t>

	<t>
	An example of such an allocation for a registry:
	<figure>
		<artwork>
Value | Meaning
------+--------------------------------------------------
  0   | Reserved (not to be allocated)
  :   |
 Max  | Reserved (for future use for registry extension)
		</artwork>
	</figure>
	</t>
</section>

<section title="Reservation Strategies for Bit Fields">
	<t>
	When code points representing bit-fields in protocols are made, many of
	the new bits are generally unallocated and left for future expansion.
	These bit-fields are either noted as Unassigned, Reserved, or have
	other similar policies associated with them in the registry
	containing them.
	</t>

	<t>
	Specifications containing such fields are recommended to
	provide text documenting these reserved fields similar to the
	following: "These bit-fields are Unassigned and MUST be set to zero
	upon transmission and SHOULD be ignored upon receipt."
	</t>
</section>

<section title="Security Considerations">
	<t>
	This document does not introduce any security considerations.
	</t>
</section>

<section title="IANA Considerations">
	<t>
	This document does not make any requests to IANA.  However, future
	documents may wish to utilize this document as an informative reference
	for their reservation strategy when making requests to IANA.
	</t>
</section>

</middle>

<back>

<references title="Normative References">
		&rfc2119;

</references> <!-- Normative References -->

<references title="Informative References">
		&rfc5226bis;

</references> <!-- Informative References -->

<section title="Acknowledgments">
	<t>This document was originally a lunch discussion with John Scudder
	about IETF code point allocations for BGP.  While the above practices
	were thought to be widely understood, they did not appear to be written
	down anywhere to help educate new IETF participants.</t>

	<t>Adrian Farrel provided substantial review on the first version of
	this document.</t>

	<t>This document has also benefited from excellent discussion of the
	subject on the IETF Working Group Chairs e-mail list.</t>
</section> <!-- Acknowledgments -->

</back>

</rfc>