Reservation Strategies for the Zeroth and Last Code Points in IETF Registries and for Bit Field Registries
draft-haas-code-point-reservation-bcp-02

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on March 21, 2016.

Copyright Notice

Copyright (c) 2015 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Requirements Notation
• 2. Introduction
• 3. A Reservation Strategy for the Zeroth and Last Code-Points
• 4. Reservation Strategies for Bit Fields
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Appendix A. Acknowledgments
• Author's Address

1. Requirements Notation

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 [RFC2119].

2. Introduction

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.

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 [I-D.leiba-cotton-iana-5226bis], are dedicated to strategies for the management of such code point registries.

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.

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.

3. A Reservation Strategy for the Zeroth and Last Code-Points

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.

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

• 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 remains unset. It is RECOMMENDED that the reservation text should be of the form, "Reserved (not to be allocated)".
• 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 [I-D.leiba-cotton-iana-5226bis], Section 6, "Reserved".) It is RECOMMENDED that the reservation text should be of the form, "Reserved (for future registry extension)".

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.

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.

Value | Meaning
------+--------------------------------------------------
  0   | Reserved (not to be allocated)
  :   |
 Max  | Reserved (for future registry extension)
		

An example of such an allocation for a registry:

4. Reservation Strategies for Bit Fields

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.

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

5. Security Considerations

This document does not introduce any security considerations.

6. IANA Considerations

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.

7. References

7.1. Normative References

7.2. Informative References

Appendix A. Acknowledgments

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.

Adrian Farrel provided substantial review on the first version of this document.

This document has also benefited from excellent discussion of the subject on the IETF Working Group Chairs e-mail list.

Author's Address