Internet DRAFT - draft-haas-code-point-reservation-bcp
draft-haas-code-point-reservation-bcp
Network Working Group J. Haas, Ed.
Internet-Draft Juniper Networks
Intended status: Best Current Practice September 18, 2015
Expires: March 21, 2016
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
Haas Expires March 21, 2016 [Page 1]
Internet-Draft Reservation Strategies for IETF Code PointsSeptember 2015
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. A Reservation Strategy for the Zeroth and Last Code-Points . 3
4. Reservation Strategies for Bit Fields . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Haas Expires March 21, 2016 [Page 2]
Internet-Draft Reservation Strategies for IETF Code PointsSeptember 2015
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:
o 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)".
o 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.
An example of such an allocation for a registry:
Haas Expires March 21, 2016 [Page 3]
Internet-Draft Reservation Strategies for IETF Code PointsSeptember 2015
Value | Meaning
------+--------------------------------------------------
0 | Reserved (not to be allocated)
: |
Max | Reserved (for future registry extension)
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.leiba-cotton-iana-5226bis]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", draft-
leiba-cotton-iana-5226bis-11 (work in progress), November
2014.
Haas Expires March 21, 2016 [Page 4]
Internet-Draft Reservation Strategies for IETF Code PointsSeptember 2015
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
Jeffrey Haas (editor)
Juniper Networks
Email: jhaas@juniper.net
Haas Expires March 21, 2016 [Page 5]