idnits 2.17.1 draft-carpenter-whats-an-author-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 (June 14, 2015) is 3237 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-crocker-rfc2418bis-wgguidelines-00 -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational June 14, 2015 5 Expires: December 16, 2015 7 What is an Author of an IETF Stream Draft? 8 draft-carpenter-whats-an-author-02 10 Abstract 12 This draft suggests guidelines for assigning authorship in IETF 13 stream Internet-Drafts. It also discusses the related issues of 14 acknowledgements, editors and contributors. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 16, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 51 2. General Issues of Authorship Ethics . . . . . . . . . . . . . 2 52 3. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Editors . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. List of Acknowledgements . . . . . . . . . . . . . . . . . . 5 56 7. Revised or Replacement Documents . . . . . . . . . . . . . . 6 57 8. Other Exceptions and Discussions . . . . . . . . . . . . . . 6 58 9. Intellectual Property Rights . . . . . . . . . . . . . . . . 7 59 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 13. Change log . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 14. Informative References . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction and Scope 68 The question sometimes comes up of who should be listed as the 69 author(s) of a draft, who should be listed as editors or 70 contributors, and what acknowledgements are appropriate. The 71 guidelines below are aimed at Internet-Drafts in the IETF publication 72 stream [RFC4844], [RFC5741]. 74 Any inconsistency with [RFC7221] is unintentional, and related issues 75 are discussed in [I-D.crocker-rfc2418bis-wgguidelines]. The 76 guidelines are intended to be compatible with the RFC Editor's style 77 guide [RFC7322], with the RFC Editor's authorship policies 78 and with the IESG statement on 80 Internet Draft Authorship . 83 This draft has been written to aid discussion and is not intended to 84 be published as an RFC. It in no way, shape or form intends to 85 change the IETF standards process and the related rules on 86 intellectual property. It could be used as input to revision of the 87 Tao of the IETF or of other relevant IETF documents. 89 2. General Issues of Authorship Ethics 91 There are some quite general aspects of the ethics of professional 92 authorship of academic or technical documents that naturally apply to 93 IETF drafts. This is not the place for a detailed discussion of 94 authorship ethics, but the most important points are 95 o Factual accuracy. 97 o Avoidance of misleading or obfuscating statements. 99 o Avoidance of misleading omissions. 101 o Balance between opposing arguments, when relevant. 103 o Careful acknowledgement and citation of sources and references. 105 o Avoidance of unacknowledged plagiarism. 107 Factual accuracy includes accuracy about who wrote the document: only 108 people who made a real contribution should be listed as authors or 109 contributors. 111 Other aspects are that personal or business considerations should not 112 affect accuracy and balance, and any hidden conflicts of interest 113 should be documented. Corrections, clarifications and retractions 114 should be made promptly when needed. 116 Many academic journals and universities have published policies about 117 authorship ethics. Examples from life sciences are 118 , and . 122 However, the IETF has some peculiarities. Perhaps the most important 123 is that we generally encourage the free flow of ideas and their re- 124 use in fresh documents. Sometimes that means that small or large 125 sections of text are copied from one document into another, and 126 subsequently changed as the discussion evolves. In the world at 127 large that is considered to be plagiarism. In the IETF, we consider 128 it to be normal business as long as due acknowledgement is given. 129 This document is specifically scoped for IETF Internet-Drafts and is 130 not intended to apply to non-IETF Internet-Drafts. Some parts might 131 apply to other document streams but that is incidental. (See 132 Section 5 of [RFC4844] for an explanation of the various document 133 streams.) 135 3. Authors 137 Authors are people who have made a substantial creative contribution 138 to the document. Normally this means writing text or drawing 139 diagrams. Occasionally, with the consent of the other authors, it 140 means making some other substantial creative contribution to the 141 document, for example by writing a software implementation as part of 142 the design process. It's a matter of judgement whether a person who 143 simply makes a key intellectual contribution should rank as an 144 author. 146 People who did not make any such substantial contribution should not 147 be listed as authors. Funding support, professional reputation, 148 managerial or supervisory status, and CV embellishment don't count. 149 It's also worth noting that in the IETF, authorship by an employee 150 does not imply endorsement by the employer. Therefore, authors 151 should not be added just because of who they work for. 153 There are quite a few subjective judgements to be made about whether 154 a contribution is substantial enough to count as authorship. What 155 fraction of new or corrected text counts? Is a particular brilliant 156 idea enough? Should the author of a previous trail-blazing document 157 be invited to join? Should someone who promised to contribute 158 significantly, but only contributed fragments, be removed? It's hard 159 to give definite guidelines for such cases. 161 In normal circumstances, people should never be listed as authors 162 without their explicit permission. In case of doubt, the person 163 submitting the draft should check with each listed author in advance 164 to avoid any misunderstandings. If an author wishes to withdraw, 165 this should be honoured, although the person may then be listed as a 166 contributor or be mentioned in the acknowledgements. 168 The practical impact is that the authors will be listed as such on 169 the front page if the document becomes an RFC, and in public 170 bibliographies. 172 4. Contributors 174 Contributors are people who made smaller creative contributions to 175 the document than the authors, for example providing initial ideas 176 that others have transformed into publishable text, or drafting only 177 a few paragraphs. 179 People who did not make any such contribution should not be listed as 180 contributors. People should not normally be listed as contributors 181 without their explicit permission. 183 The dividing line between contributors and authors is a matter of 184 judgement and cannot be rigidly defined. However, the RFC Editor's 185 policy is to query any document that has more than five listed 186 authors. Any list of more than five authors will need to be 187 negotiated if the document is approved for publication as an RFC. 189 5. Editors 191 When a document has a large number of contributors and potential 192 authors, it may be appropriate to designate one or two people as both 193 "Authors" and "Editors" and list the others as contributors. The 194 editors will indeed do the actual work of editing the document on 195 behalf of the community. The practical impact of this is that the 196 editors will be listed as such on the front page if the document 197 becomes an RFC, and in public bibliographies. 199 In some cases, it may be appropriate to retain a list of authors of 200 which one or two are designated as editors. What matters is "truth 201 in advertising": the people involved should all feel happy that the 202 designations of editors, authors and contributors are fair and 203 accurate. 205 It's worth noting that in some people's opinion, once a draft has 206 been adopted by a WG, all future changes are performed as an editing 207 action on behalf of the WG. Traditionally, the IETF has chosen to 208 retain the word "Author" in most cases, with the formal designation 209 of editors being exceptional. Some other standards development 210 organizations always remove individual authorship when a document is 211 formally adopted. 213 6. List of Acknowledgements 215 Acknowledgements should be given to people who have made significant 216 creative contributions smaller than those from the authors and 217 contributors, or to people who have made useful comments, provided 218 critical reviews, or otherwise contributed significantly to the 219 development of the document. If text or ideas have been adopted from 220 other written sources, including IETF documents, clearly a reference 221 is an ethical requirement, but an acknowledgement might also be 222 appropriate. 224 Acknowledgements may also be given to people or organizations that 225 have given material support and assistance, but this should not 226 include the authors' regular employers unless there are exceptional 227 circumstances. 229 An acknowledgement should be written as a description of a fact. It 230 does not and should not signify that the person acknowledged agrees 231 with or supports the document. In general, people who do not wish to 232 be listed as an author or a contributor, but have in fact made a 233 significant contribution, should be given an acknowledgement. In 234 unusual circumstances, acknowledgements of contributions have 235 specifically indicated that the contributor does not support the 236 document as posted. Language such as the following might be used: 238 Thanks to for their valuable comments and help 239 during the development of this document, even though they did not 240 fully agree with the WG's conclusion. 242 When in doubt, it is usually better to include an acknowledgement 243 than to omit it. 245 7. Revised or Replacement Documents 247 A common occurrence is that an IETF document from some years ago 248 requires updating. This is often done by people who were not the 249 original authors. The question then arises of whether to list the 250 original authors on the "bis" draft, even if they are long gone from 251 IETF participation. 253 When an Internet-Draft is prepared by one or more new people but 254 reuses significant amounts of text from one or more earlier RFCs and/ 255 or I-Ds, a situation arises that often requires thought and careful 256 handling. The criteria above suggest that the authors of the 257 original documents should continue to be listed as authors. After 258 all, there is rarely any question that the earlier publications 259 constitute "a substantial creative contribution" to the revised 260 document. However, there are no guarantees that the prior authors 261 will want to be listed as authors of the new draft and take on 262 whatever responsibilities that implies. Ideally, those assembling 263 the newer version will consult with the authors of the previous ones 264 and make mutually acceptable arrangements, but, especially when that 265 is not feasible, sensitivity to all possible issues will be needed. 267 8. Other Exceptions and Discussions 269 It goes without saying that normally nobody should be listed as an 270 author, contributor or editor against their will. Ideally, the 271 parties involved will agree among themselves, or defer to the 272 judgement of the WG Chairs or Area Directors. Practice may vary 273 between WGs. However, we need flexibility to deal with unusual 274 cases, such as these: 276 o As noted above, an acknowledgement is a statement of fact (the 277 person contributed to the discussion). In some cases it may be 278 included even if the person acknowledged objects, for example if 279 they made a suggestion that might later be viewed as prior art. 281 o Generalising the point made in Section 7, an earlier author or 282 contributor may deserve to be listed, even if they cannot be 283 contacted when a document is updated after a long interval. Each 284 such case needs to be considered on its merits. 286 o In particular, an author or contributor might be deceased. 288 9. Intellectual Property Rights 290 This document does not discuss intellectual property rights and in no 291 way preempts or alters the IETF's rules and requirements concerning 292 intellectual property rights. In particular some of the ethical 293 guidelines above might be mandatory requirements under those rules. 294 All IETF participants are strongly advised to be familiar with the 295 rules. 297 It is worth noting that if a draft includes complete acknowledgements 298 and references, it will be much simpler to clarify its status as 299 possible prior art in years to come. 301 Copyright in IETF documents is governed by BCP 78 [RFC5378] and its 302 predecessors, the IETF Trust's Legal Provisions, and applicable 303 national and international law. 305 The word "contributor" used in this draft might not mean the same 306 thing as the word "Contributor" used in BCP 79 [RFC3979]. That BCP 307 should be consulted by anyone concerned about the IETF requirement 308 for disclosure of intellectual property rights. 310 10. Security Considerations 312 None, really. 314 11. IANA Considerations 316 This memo includes no request to IANA. 318 12. Acknowledgements 320 Valuable comments were received from Loa Andersson, Andy Bierman, 321 Carsten Bormann, Dave Crocker, David Farmer, John Klensin (who also 322 contributed some text), Larry Kreeger, Eliot Lear, Tom Petch, 323 Alexandru Petrescu, Yaron Sheffer, and Joe Touch. 325 Especially given the topic of this draft, the author apologises for 326 any accidental omissions. 328 13. Change log 330 draft-carpenter-whats-an-author-02, 2015-06-14: more comments, nits, 331 some reorganisation. 333 draft-carpenter-whats-an-author-01, 2015-05-30: incorporating 334 community comments, citing RFC Editor and IESG statements. 336 draft-carpenter-whats-an-author-00, 2015-04-24: original version. 338 14. Informative References 340 [I-D.crocker-rfc2418bis-wgguidelines] 341 dcrocker, d. and R. Droms, "IETF Working Group Guidelines 342 and Procedures", draft-crocker-rfc2418bis-wgguidelines-00 343 (work in progress), March 2015. 345 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 346 Technology", BCP 79, RFC 3979, March 2005. 348 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 349 Series and RFC Editor", RFC 4844, July 2007. 351 [RFC5378] Bradner, S. and J. Contreras, "Rights Contributors Provide 352 to the IETF Trust", BCP 78, RFC 5378, November 2008. 354 [RFC5741] Daigle, L., Kolkman, O., and IAB, "RFC Streams, Headers, 355 and Boilerplates", RFC 5741, December 2009. 357 [RFC7221] Farrel, A. and D. Crocker, "Handling of Internet-Drafts by 358 IETF Working Groups", RFC 7221, April 2014. 360 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 361 September 2014. 363 Author's Address 365 Brian Carpenter 366 Department of Computer Science 367 University of Auckland 368 PB 92019 369 Auckland 1142 370 New Zealand 372 Email: brian.e.carpenter@gmail.com