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]