idnits 2.17.1 draft-haas-code-point-reservation-bcp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2015) is 3143 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-20) exists of draft-leiba-cotton-iana-5226bis-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Haas, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Best Current Practice September 18, 2015 5 Expires: March 21, 2016 7 Reservation Strategies for the Zeroth and Last Code Points in IETF 8 Registries and for Bit Field Registries 9 draft-haas-code-point-reservation-bcp-02 11 Abstract 13 This document describes common code point reservation strategies for 14 the zeroth and last code points in IANA-managed IETF registries and 15 for bit-field registries. This document additionally provides the 16 reasoning to support these strategies and their adoption as Best 17 Current Practices to be applied to all IETF registries. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. A Reservation Strategy for the Zeroth and Last Code-Points . 3 56 4. Reservation Strategies for Bit Fields . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 7.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Requirements Notation 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [RFC2119]. 71 2. Introduction 73 A fundamental component of networking protocols are the fields 74 contained within their Protocol Data Units (PDUs), a.k.a. packets. 75 The fields are typically enumerated and are often part of the common 76 syntactic form of a Type, Length, Value (TLV) tuple. An allocation 77 of one of these enumerated fields is a code point. 79 When designing or extending a networking protocol, some thought must 80 be put into the range of allowable values and format for these 81 fields. Additionally consideration must be given to how the 82 allocation of the code points for these fields is managed. Other 83 documents, for example [I-D.leiba-cotton-iana-5226bis], are dedicated 84 to strategies for the management of such code point registries. 86 The range of allowable values must be large enough to accommodate not 87 only immediate uses that are part of the design of a protocol or 88 protocol extension, but must also provide room for future 89 maintenance. Some protocols that are meant to be used in highly 90 constrained environments may also attempt to minimize the size of 91 packets to conserve networking resources. Thus, a balance between 92 being small enough to conserve resources but large enough to permit 93 future expansion provides a tension that protocol designers must 94 navigate. 96 One further matter for consideration for such code point registries 97 is pre-reserving some values. This document discusses a reasoning 98 for the reservation of the zeroth and last code point in an integer 99 field, and a general policy for the reservation of unused bits in 100 bit-vectors. 102 3. A Reservation Strategy for the Zeroth and Last Code-Points 104 When designing a protocol, a design decision must be made for integer 105 code-points as to how large to make its range. Some protocols may 106 prize density and thus elect for a small range, often a byte and 107 perhaps less. Other protocols may be dominated by a need for 108 flexibility and expansion and use a large range, four bytes or 109 larger. 111 When creating new integer code-point registries, this document makes 112 the following recommendation: 114 o The zeroth entry of the new registry SHOULD be reserved. This 115 permits implementors to avoid the need of separate boolean state 116 to represent that a code point remains unset. It is RECOMMENDED 117 that the reservation text should be of the form, "Reserved (not to 118 be allocated)". 120 o The last entry of the new registry SHOULD be reserved. This 121 provides future maintainers of the protocol the ability to extend 122 the functionality covered by the semantics of this code point when 123 all other numbers may have otherwise been allocated. (See 124 [I-D.leiba-cotton-iana-5226bis], Section 6, "Reserved".) It is 125 RECOMMENDED that the reservation text should be of the form, 126 "Reserved (for future registry extension)". 128 Implementations MAY specify that the zeroth code point is explicitly 129 prohibited in the protocol. Experience in implementation, however, 130 has suggested that fatal error conditions based on this behavior lend 131 itself to a brittleness in the protocol with unforseen future 132 consequences. 134 Implementations SHOULD NOT explicitly treat the use of the last code 135 point as an error condition outside the semantics otherwise specified 136 within the protocol for an unused code-point. Making this value 137 explicitly forbidden within the protocol eliminates its usefulness 138 for future expansion in the presence of older implementations that do 139 not understand the expanded semantic. In other words, future proof 140 your implementation. 142 An example of such an allocation for a registry: 144 Value | Meaning 145 ------+-------------------------------------------------- 146 0 | Reserved (not to be allocated) 147 : | 148 Max | Reserved (for future registry extension) 150 4. Reservation Strategies for Bit Fields 152 When code points representing bit-fields in protocols are made, many 153 of the new bits are generally unallocated and left for future 154 expansion. These bit-fields are either noted as Unassigned, 155 Reserved, or have other similar policies associated with them in the 156 registry containing them. 158 Specifications containing such fields are recommended to provide text 159 documenting these reserved fields similar to the following: "These 160 bit-fields are Unassigned and MUST be set to zero upon transmission 161 and SHOULD be ignored upon receipt." 163 5. Security Considerations 165 This document does not introduce any security considerations. 167 6. IANA Considerations 169 This document does not make any requests to IANA. However, future 170 documents may wish to utilize this document as an informative 171 reference for their reservation strategy when making requests to 172 IANA. 174 7. References 176 7.1. Normative References 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 7.2. Informative References 183 [I-D.leiba-cotton-iana-5226bis] 184 Cotton, M., Leiba, B., and T. Narten, "Guidelines for 185 Writing an IANA Considerations Section in RFCs", draft- 186 leiba-cotton-iana-5226bis-11 (work in progress), November 187 2014. 189 Appendix A. Acknowledgments 191 This document was originally a lunch discussion with John Scudder 192 about IETF code point allocations for BGP. While the above practices 193 were thought to be widely understood, they did not appear to be 194 written down anywhere to help educate new IETF participants. 196 Adrian Farrel provided substantial review on the first version of 197 this document. 199 This document has also benefited from excellent discussion of the 200 subject on the IETF Working Group Chairs e-mail list. 202 Author's Address 204 Jeffrey Haas (editor) 205 Juniper Networks 207 Email: jhaas@juniper.net