idnits 2.17.1 draft-farrel-soon-04.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 (February 21, 2017) is 2620 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-leiba-rfc2119-update-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Farrel 3 Internet-Draft Juniper Networks 4 Intended status: Informational February 21, 2017 5 Expires: August 25, 2017 7 A Definition of the Term "Soon" for Use in Discussions with Working 8 Group Chairs and Area Directors 9 draft-farrel-soon-04 11 Abstract 13 Many discussions with IETF Area Directors and Working Group Chairs 14 utilize the word "soon" to qualify a commitment to action. This 15 document attempts to provide a definition of that term so that common 16 expectations may be realistically set. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 August 25, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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. We Are All Volunteers . . . . . . . . . . . . . . . . . . . . 3 60 3. The Kompella Time-Dilation Effect . . . . . . . . . . . . . . 3 61 4. Possible Interpretation of the Term 'Soon' . . . . . . . . . 3 62 5. Optimism Is the Curse of the Drinking Man . . . . . . . . . . 4 63 6. Towards A Definitive Meaning . . . . . . . . . . . . . . . . 4 64 7. Guidance in the Use of This Term . . . . . . . . . . . . . . 5 65 8. Boilerplate for Inclusion in All Communications . . . . . . . 5 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 10.1. Privacy Considerations . . . . . . . . . . . . . . . . . 6 69 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 70 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 72 12.2. Informative References . . . . . . . . . . . . . . . . . 6 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 In everyday exchanges between IETF participants and those with IETF 78 management roles (for example, Area Directors and Working Group 79 Chairs) commitments are often made to deliver actions. 81 For example, a Working Group Chair may say "I will issue a working 82 group last call on this document," or an Area Director could say "I 83 will process your publication request and review your document." 84 Alternatively, a document author might say "I will produce a new 85 revision of this document," and a participant sometimes says "I will 86 provide more details / suggested text / a follow-up review." 88 In all of these interactions it is common for the speaker to offer 89 some expected completion time for the action. Sometimes this is 90 expressed in elapsed time (for example, "I will do this within the 91 next two lunar cycles"), frequently it is stated with reference to an 92 absolute point in time (such as, "I will do this by the third Sunday 93 in Lent"), but usually the qualifier applied is "Soon." 95 Frustration and disappointment are common currency in the modern 96 world, but there is no need for the IETF to add to this state of 97 affairs. Nor should the IETF be responsible for increasing cynicism 98 and jaundiced pessimism. Therefore, this document attempts to 99 provide a definition of the term "Soon" so that common expectations 100 may be realistically set. 102 2. We Are All Volunteers 104 It is a commonly held belief that in the IETF "we are all 105 volunteers." Even those of us who are paid to do our jobs are 106 confident that we are only working out of the goodness of our hearts 107 and that our salaries are poor recompense for our daily travails. 109 And, of course, it is well known that you cannot induce a volunteer 110 to do anything that might interfere with their otherwise compulsory 111 activities of looking at pictures of cats, creating memes, or pipe- 112 smoking. Therefore, it is highly inappropriate for this document to 113 make any attempt to constrain anyone into giving a meaningful 114 delivery date for any action that they promise. To that end it is 115 expected that this document will be withdrawn and a fulsome apology 116 issued soon. 118 3. The Kompella Time-Dilation Effect 120 When serving as co-chair of the CCAMP working Group, Kireeti Kompella 121 was often called to account for not offering a completion date for 122 tasks to which he committed. 124 After wise consideration of this situation, Kireeti would offer an 125 answer such as "I will do this before the end of June," and everyone 126 would go away content. It was only as July gave way to August that 127 Kireeti would explain that he had failed to indicate to which year he 128 was referring. 130 In such cases of high residual KTDE, use of the term "Soon" would 131 better set expectations, and Kireeti has given an undertaking to 132 transition to this term by the end of the second quarter. 134 4. Possible Interpretation of the Term 'Soon' 136 Many learned articles have been written on possible interpretation of 137 the term "Soon". No doubt the author will add citations and 138 references one day soon. 140 Readers should note that "SOON" is also an FLA [RFC5513] although has 141 not yet been registered as such by IANA. This document has not 142 (noticeably) been endorsed by the Standards Organisation of Nigeria. 144 5. Optimism Is the Curse of the Drinking Man 146 The software industry is infamous for its inability to provide 147 reliable estimates for development projects. No-one is quite sure 148 why this should be. Is it because troops of evil mice come into the 149 workshop late at night while the cobbler is asleep in his bed 150 alongside his long-suffering wife and unpick the seams of carefully 151 constructed function calls? Is it because coders make it all up as 152 they go along and have no idea what they are doing? And is it a 153 coincidence that sotware is so appropriately spelled? 155 IETF working group milestones (or "millstones" as they are more 156 correctly termed) are commonly held in disrepute. They are certainly 157 not dates that anyone had ever been held to, and inspection of most 158 working group charters will show that either the chairs intend 159 employing time travel or that no one pays any attention to the 160 milestones. It may be because Area Directors often say to working 161 group chairs that "milestones are just a tool for you to manage the 162 working group", or it may be because no one likes a bully. 164 These two factors obviously contribute to an environment in which the 165 term "soon" has little or no currency except as padding to fill an 166 awkward gap between a promise and the full stop at the end of the 167 sentence. 169 None of which is intended to imply that: 171 o Women don't drink 173 o Women are less optimistic than men 175 o Women are more optimistic than men 177 6. Towards A Definitive Meaning 179 The purpose of this document is to provide a working definition of 180 the term "soon" so that parsers of IETF communications may reasonably 181 understand the meaning, and so that a degree of linguistic 182 interoperability between speakers may be achieved. The following 183 definition applies: 185 SOON This word, or the adverb "SHORTLY", mean that an item is 186 truly optional. One IETF participant may choose to deliver the 187 item because a particular marketplace requires it or because the 188 participant feels that it enhances their reputation while another 189 participant may omit to deliver the same item. A participant who 190 does not deliver a particular item MUST be prepared to continue to 191 work with with another participant who does deliver the item, 192 though perhaps with reduced credulity. In the same vein, a 193 participant who does deliver a particular item MUST be prepared to 194 continue to work with another participant who does not deliver the 195 item, though perhaps with less respect (except, of course, for 196 communications about the feature the item provides). 198 TOO LATE This phrase, and the phrase "NEVER MORE", mean that the 199 optimality of an item has been pushed to its limit, and then 200 slightly further. For the benefit of everyone, once one of these 201 phrases has been used in a communication, all work on the 202 referenced deliverable SHOULD be halted and all further discussion 203 SHOULD be transmitted as silence and MUST be ignored on receipt. 204 Document authors MAY choose to ignore either of these terms, but 205 they do so at the risk of their immortal souls. Further guidance 206 on this issue can be obtained from your moral guardian, your 207 household gods, or from any member of the IMM (Internet Moral 208 Majority) [RFC4041]. 210 7. Guidance in the Use of This Term 212 Terms of the type defined in this memo must be used with care and 213 sparingly. In particular, they MUST only be used where it is 214 actually required for explanation of when a deliverable will arrive 215 or to limit behavior which has potential for causing harm (e.g., 216 limiting retransmissions of requests for action). For example, they 217 MUST NOT be used to try to impose a particular schedule on 218 participants where the schedule is not required for anything other 219 than vanity. 221 8. Boilerplate for Inclusion in All Communications 223 In many IETF communications a word is often used to signify the 224 proximity of an event described in the communication. This word is 225 often capitalized. This document defines this word as it should be 226 interpreted in IETF communications. Authors who follow these 227 guidelines should incorporate this phrase near the beginning of their 228 communication: 230 The key words "SOON", "SHORTLY", "TOO LATE", and "NEVER MORE" in 231 this communication are to be interpreted as described in 232 [This.I-D]. 234 Contrary to the overweening pedantry of [I-D.leiba-rfc2119-update], 235 words used in this document mean what they say regardless of what 236 font they are in and notwithstanding the color in which thy are 237 rendered. 239 To quote from Through the Looking Class by Charles Dodgson: 241 "When I use a word," Humpty Dumpty said in rather a scornful tone, 242 "it means just what I choose it to mean - neither more nor less." 244 "The question is," said Alice, "whether you can make words mean so 245 many different things." 247 "The question is," said Humpty Dumpty, "which is to be master - 248 that's all." 250 Thus, the term "soon" is as meaningful when it is presented in 251 "uppercase" as it is when found in "LOWERCASE". 253 9. IANA Considerations 255 This document makes no request for any IANA actions. 257 10. Security Considerations 259 Just say no! 261 Further security consideration will be added to this document SOON. 263 10.1. Privacy Considerations 265 See "Author's Address" Section. 267 11. Acknowledgements 269 Kireeti Kompella reminded me of millstones and corrected my grammar. 271 Thanks to John Scudder for his own overweening pedantry. 273 Benoit Claise supplied comments NOT BEFORE TIME. 275 12. References 277 12.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, 281 DOI 10.17487/RFC2119, March 1997, 282 . 284 12.2. Informative References 286 [I-D.leiba-rfc2119-update] 287 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", draft-leiba-rfc2119-update-01 (work in 289 progress), February 2017. 291 [RFC4041] Farrel, A., "Requirements for Morality Sections in Routing 292 Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005, 293 . 295 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 296 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 2009, 297 . 299 Author's Address 301 Adrian Farrel 302 Juniper Networks 304 Email: afarrel@juniper.net