idnits 2.17.1 draft-kuehlewind-tcpm-flags-registry-00.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 111 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 18, 2019) is 1621 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kuehlewind 3 Internet-Draft Ericsson 4 Intended status: Standards Track November 18, 2019 5 Expires: May 21, 2020 7 Registration Policy for TCP Header Flags 8 draft-kuehlewind-tcpm-flags-registry-00 10 Abstract 12 RFC2780 specifies the registration policy for reserved TCP header 13 flags as Standards Action. RFC3168 created an IANA registry for 14 these header flags and registered bit 8 (CWR) and 9 (ECE). This 15 draft changes the registration policy of the registration to IETF 16 Review as usually new TCP mechanisms that could use the remaining 17 reserved flags will be first specified as experimental. Not noting 18 any of those experiments in the registry would undermine the purpose 19 of having a registry. However, care must be taken, as only a few 20 reserved flags are left and if a new (experimental) mechanism sees 21 deployment in the Internet, the flag cannot be unassigned anymore or 22 used for something else. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 21, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Registration Policy for TCP Header Flags . . . . . . . . . . 3 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 5. Security Consideration . . . . . . . . . . . . . . . . . . . 4 63 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 64 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 67 8.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 [RFC2780] specifies the registration policy for reserved TCP header 73 flags as Standards Action. In section 9.2 (Reserved Bits in TCP 74 Header) is says: 76 "The reserved bits in the TCP header are assigned following a Standards Action process." 78 Earlier on, in section 2 (Temporary Assignments) it also says 80 "From time to time temporary assignments are made in the values for fields in these headers for use in experiments. IESG Approval is required for any such temporary assignments." 82 However, it does not specify what exactly is meant with a temporary 83 assignment and how this could work for TCP header given they can 84 hardly be re-purposed once deployed on the Internet. 86 [RFC3168] created a IANA registry for these header flags and 87 registered bit 8 (CWR) and 9 (ECE). [RFC3540] assigned bit 7 to the 88 experimental ECN Nonce extension and [RFC8311] recently declared 89 RFC3540 as historic and changed the assignment to reserved, as ECN 90 Nonce was not deployed on the Internet. The purpose of RFC8311 was 91 to concentrate updates to Standard Track RFCs in one document in oder 92 to enable new experimentation with various ECN-related mechanisms. 93 However, RFC8311 does not provide any recommendation of the use of 94 bit 7 and the TCP flags registry. 96 2. Notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. Registration Policy for TCP Header Flags 106 This draft changes the registration policy of the registration to 107 IETF Review as usually new TCP mechanisms that could use the 108 remaining reserved flags will be first specified as experimental. 109 Not noting any of those experiments in the registry would undermine 110 the purpose of having a registry. However, assignments based on 111 experimental RFC should be marked as such in the "Comments" field and 112 potentially even provide hints about the nature of the experiment or 113 provide a pointer to a section in an RFC where the experiment is 114 explained. 116 Further, care must be taken, when assigning TCP header flags for 117 experimental use, as a) only a few reserved flags are left, and b) if 118 a new (experimental) mechanism sees deployment in the Internet, the 119 flag cannot be unassigned anymore or used for something else. 120 Therefore, any experimental RFC that registers a reserved flags in 121 the TCP flags registry MUST provide ways to alter the proposed 122 mechanism at the end of the experimental phase without using 123 additional TCP header flags. E.g. it would be possible to add an 124 additional negotiation mechanism after the TCP handshake that would 125 make it possible to use different versions of the general mechanism/ 126 extension that was negotiated or indicated during the TCP handshake 127 using the newly assigned flag. Further, any experimental extension 128 SHOULD discussion the scope of the experiment and potential failure 129 cases or open questions that need to be answered when running the 130 experiment and explain how these could be addressed in an updated 131 version. 133 TCP flags can only be de-assigned if no deployment of an experimental 134 extension happened. This should be evaluated some years after the 135 assignment to an experimental extension, in order to change the 136 registry entry back to "RESERVED" and move the respective 137 experimental RFC to history, or assign it permanently. This might be 138 done by IESG Approval or based on an Standards track document. 139 However, even when reversed to "RESERVED", the experiment should 140 still be noted (as failed and over) in the "Comments" field of the 141 registry entry. 143 4. IANA Considerations 145 IANA is requested to change the registration policy of the "TCP 146 Header Flags" registry (https://www.iana.org/assignments/tcp-header- 147 flags/tcp-header-flags.xhtml) to IETF Review or IESG Approval and 148 note this accordingly on the registry page. 150 In addition, the registry should be updated with a new column called 151 "Comments". The text in the "name" field of the entry for bit 7 152 there should be moved into this new column while the name will then 153 only say "RESERVED". Further, bits 4, 5, 6 should be added to the 154 registry and marked as "RESERVED". 156 Moreover, as a matter of cleaning-up, IANA is requested to move the 157 registry to a sub-registry on the Transmission Control Protocol (TCP) 158 Parameters page (https://www.iana.org/assignments/tcp-parameters/tcp- 159 parameters.xhtml). 161 5. Security Consideration 163 TBD 165 6. Contributors 167 7. Acknowledgments 169 8. References 171 8.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, 175 DOI 10.17487/RFC2119, March 1997, 176 . 178 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 179 Values In the Internet Protocol and Related Headers", 180 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 181 . 183 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 184 of Explicit Congestion Notification (ECN) to IP", 185 RFC 3168, DOI 10.17487/RFC3168, September 2001, 186 . 188 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 189 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 190 May 2017, . 192 8.2. Informative References 194 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 195 Congestion Notification (ECN) Signaling with Nonces", 196 RFC 3540, DOI 10.17487/RFC3540, June 2003, 197 . 199 [RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion 200 Notification (ECN) Experimentation", RFC 8311, 201 DOI 10.17487/RFC8311, January 2018, 202 . 204 Author's Address 206 Mirja Kuehlewind 207 Ericsson 209 Email: mirja.kuehlewind@ericsson.com