idnits 2.17.00 (12 Aug 2021) /tmp/idnits43740/draft-hardie-advance-mechanics-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2026]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 15, 2010) is 4259 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ted. Hardie 3 Internet-Draft Panasonic Wireless Research Lab 4 Intended status: BCP September 15, 2010 5 Expires: March 19, 2011 7 Proposed mechanics for document advancement 8 draft-hardie-advance-mechanics-00 10 Abstract 12 The IETF has maintained a three-stage standards track for some time, 13 with basic mechanics set out in RFC 2026 [RFC2026]. The mechanics as 14 described, however, are not currently used in practice and 15 advancement along the standards track is both unusual and more 16 difficult than many IETF participants find reasonable. This document 17 proposes an update to those mechanics, in the interest of improving 18 the overall functioning of the IETF. It is compatible with, but does 19 not require, a move to a two-stage standards track. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 19, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Document processing . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Mechanics for moving from Proposed to Draft . . . . . . . . . . 3 64 4. Guidance for Objections . . . . . . . . . . . . . . . . . . . . 4 65 5. Mechanics for moving to Full Standard . . . . . . . . . . . . . 5 66 6. Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 The IETF has maintained a three-stage standards track for some time, 78 with basic mechanics set out in RFC 2026 [RFC2026]. The mechanics as 79 described, however, are not currently used in practice and 80 advancement along the standards track is both unusual and more 81 difficult than many IETF participants find reasonable. This document 82 proposes an update to those mechanics, in the interest of improving 83 the overall functioning of the IETF by aligning advancement along the 84 standards track with the current document processing model. 86 2. Document processing 88 In practice, IETF document processing has evolved to a model which 89 can be described as "objection based processing". A document put 90 forward by an author team advances from the relevant working group to 91 IETF consideration after all objections from within the working group 92 have been considered. The IETF Last Call is, in practice, a way for 93 the larger community to object to a document or elements within it. 94 IESG document processing is, fundamentally, a process by which a 95 sponsor resolves any objections raised by other area directors; 96 though the term used is "discuss" and some delegation occurs (to 97 document shepherds or review teams), the basic model is clear. 99 This document proposes using this model for the advancement of 100 documents along the standards track. Rather than requiring specific 101 actions to advance, it proposes instead to test for objections to 102 advancement at specific intervals. Documents for which no objections 103 to advancement are present or for which the objections can be met 104 advance. Those that have objections that cannot be met must be 105 revised and re-issued at the baseline level before they can advance. 107 While this might seem to run the risk of advancing documents too 108 early, in practice the current methods for assessing Proposed 109 standards are sufficiently stringent that they match earlier Draft 110 reasonably well. It is also relatively clear that the energy to 111 object can always be found in the IETF, even when the energy to 112 sponsor or shepherd a document is absent. By using objection based 113 processing with auto advancement, we move with, rather than against, 114 the methods currently at the heart of IETF mechanics. 116 3. Mechanics for moving from Proposed to Draft 118 All documents which are published as Proposed Standard RFCs shall be 119 entered in queue for advancement to Draft Standard, with automatic 120 advancement to take place two years from the issue date of the RFC. 122 A "Last Call for Objections to Advancement" must be issued 4 weeks 123 prior to advancement. If no objections are received, the document 124 advances. 126 If objections are received, the IESG issues a call for a document 127 shepherd willing to work for resolution of the objections and 128 advancement. If no document shepherd comes forward, the objections 129 are automatically sustained and the document remains at Proposed 130 Standard. If more than one volunteer steps forward, the relevant 131 area directors select from among them. An Area Director may serve as 132 shepherd for advancement, but there is no requirement that the AD do 133 so. If a document shepherd is available, he or she works to resolve 134 the objections. 136 If the objections are withdrawn, the document gets a new "Last Call" 137 and then moves forward as above. If they are not withdrawn, the 138 document shepherd may request consideration by the IESG of whether 139 the objections merit holding the document at Proposed. If the IESG 140 sustains the objections, the document remains at Proposed. If the 141 IESG is in favor of advancement, the document advances. This is 142 subject to appeal per the usual process. 144 If a new document must be prepared to meet the objections, it must 145 recycle at Proposed Standard and the clock for automatic advancement 146 starts again. 148 4. Guidance for Objections 150 Those who are entering errata for a published RFC should indicate 151 whether they believe the issue raised is sufficient to block 152 advancement. The collected errata which have been so flagged are 153 considered as objections at the Last Call period. Auto-posting of 154 these as a response to the "Last Call" for Objections to Advancement 155 might be worthwhile, in order to indicate the issues already raised 156 to others considering objections 158 Objections based on ongoing work to prepare a replacement document 159 should generally be upheld, especially when that work is taking place 160 within an IETF working group, but they are not automatic 162 Objections must be sent to the IETF main list in response to the last 163 call if they are not listed errata. Any individual who has been 164 banned from the IETF main list may not post an objection, and 165 repeated frivolous objections should be considered grounds for 166 removal of posting rights. 168 5. Mechanics for moving to Full Standard 170 The mechanics for moving to Full are the same as those for moving to 171 Draft, except that the clock runs for five years from the initial 172 publication as Proposed Standard. 174 6. Workload 176 The current system is effectively a single-stage standards process 177 for almost all documents. Any proposal to restore a multi-stage 178 standards process adds to the workload of those involved in the 179 document processing. This proposal attempt to manage that workload 180 by allowing documents with no objections to pass without further 181 effort. It also attempts to spread the load of managing objections 182 to the community, by using document shepherds from outside the IESG 183 in the common case. If no document shepherd from the community is 184 available, documents do stall, but this is a feature, not a bug. If 185 there are objections to advancement and no one willing to counter 186 them or work through them, community disinterest should be taken as 187 upholding the objection. 189 It would be possible to combine this procedure with a reduction in 190 the number of standards levels. This would further reduce the 191 workload if the advancement from stage two to stage three attracts 192 significant objections. 194 7. IANA Considerations 196 This document makes no request of IANA. 198 8. Security Considerations 200 This document has no direct implications for protocol security. If 201 the broader Internet community is judging protocol maturity based on 202 standards level, there is some risk that changing the mechanism by 203 which documents advance along the standards track may require that 204 judgement to change. 206 9. Acknowledgements 208 Jon Peterson, Russ Housley, and April Marine were kind enough to read 209 a draft of this document. Their good nature should not be taken as 210 supporting this proposal however, and all errors are the 211 responsibility of the author. 213 10. References 215 10.1. Normative References 217 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 218 3", BCP 9, RFC 2026, October 1996. 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, March 1997. 223 10.2. Informative References 225 Author's Address 227 Ted Hardie 228 Panasonic Wireless Research Lab 229 10900 Tantau Ave. 230 Cupertino, California 95014 231 USA 233 Phone: +1-408-628-5864 234 Email: ted.ietf@gmail.com