idnits 2.17.1 draft-rfc-editor-author-lists-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (8 May 2002) is 8017 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Reynolds 3 draft-rfc-editor-author-lists-00.txt R. Braden 4 Category: Informational RFC Editor 5 Expires: November 2002 8 May 2002 7 RFC Editor Guidelines on Author Lists 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 This memo presents a new set of guidelines to govern lists of 37 authors on RFC documents. It is intended to counteract a recent 38 tendency towards author list inflation. 40 1. INTRODUCTION 42 Over the past few years, there has been a tendency toward inflation 43 of the author lists on RFCs, contrary to the traditional culture of 44 the IETF and to long-standing RFC editorial policies. This memo 45 summarizes guidelines that have been formulated by the RFC Editor and 46 the IESG to limit future author list inflation. 48 2. BACKGROUND 50 2.1 Historical RFC Policy 52 During the 30 year history of the RFC series, long lists of 53 authors on a single RFC have been rare. In general, the front 54 page header of an RFC has listed only the person (or the few 55 people) who wrote the document. When there were more than a few 56 contributors to developing the specification, some RFCs listed 57 important contributors in an Acknowledgment section; the single 58 person who had been tasked with integrating the results into a 59 single document was listed as "Editor" (see RFC 1122 for an 60 example). One of the reasons for limiting the author list is 61 practical: the long-existing RFC formatting conventions do not 62 comfortably handle large author lists. We now discuss the 63 philosophical reasons. 65 2.2 The IETF Culture 67 Most standards bodies publish anonymous standards, whereas the 68 IETF attaches the names of the responsible authors to its 69 technical specifications. This relates directly to the IETF's 70 tradition of individual rather than corporate representation 71 (which in turn arose from the academic research origins of the 72 Internet technology). The person(s) who actually write an RFC 73 take responsiblity for it, even if the specifification recorded in 74 the RFC originated in a working group of several hundred people. 75 At the opposite extreme, some academic communities (e.g., high- 76 energy physics) have adopted a very liberal view of authorship, 77 resulting in papers listing hundreds of authors. The IETF 78 community does not wish to emulate this approach. 80 The selection and ordering of authors on any publication is always 81 a sensitive issue. Those individuals who contributed 82 substantially to the content of an RFC naturally wish to be 83 recognized. On the other hand, there are rumors that some 84 Internet companies are paying bounties for getting their corporate 85 names on RFCs, and in some cases there is reason to believe that 86 corporate marketing functions may play a role in author list 87 inflation. 89 Some see a list of 17 authors on one RFC as motivated by a desire 90 for corporate name-dropping, which would be inappropriate in the 91 IETF/RFC context. If there is a desire to demonstrate that many 92 companies are interested in this spec, Contributor and/or 93 Acknowledgment sections, described below, can accomplish the same 94 goal without "author overload." 96 To prevent erosion of the IETF's traditional (and highly 97 successful) approach to protocol standardization, the guidelines 98 in the following section have been crafted. They are an 99 elaboration of rules suggested independently in several different 100 recent email discussions of this topic. These guidelines are 101 intended to apply both to working group output and to individual 102 submissions. 104 3. GUIDELINES ON RFC AUTHOR LISTS 106 (1) A small set of author names, with affiliations, may appear on 107 the front page header. These should be the lead author(s) who 108 are most responsible for the actual text. When there are many 109 contributors, the best choice will be to list the person or 110 (few) persons who acted as document editor(s) (e.g.,"Tom Smith, 111 Editor"). 113 There is no rigid limit on the size of this set, but there is 114 likely to be a discussion if the set exceeds five authors, in 115 which case the right answer is probably one editor. 117 The RFC Editor will hold all the people listed on the front page 118 equally responsible for the final form and content of the 119 published RFC. In particular, the "Author's 48 Hours" final 120 approval period will require signoff from all listed authors. 122 (2) An RFC may include a Contributors section, listing those 123 contributors who deserve significant credit for the document 124 contents. When a long author list is replaced by a single 125 Editor in the front page header, the displaced authors can be 126 properly and fully acknowledged in the Contributors section. 128 The Contributors section may include brief statements about the 129 nature of particular contributions ("Sam contributed section 3") 130 and it may also include affiliations of listed contributors. It 131 may also include contact addresses for some or all of the 132 contributors cited; see item (4). 134 (3) An RFC may include an Acknowledgements section, in addition to 135 or instead of a Contributors section. The Acknowledgment 136 section may be lengthy, and it may explain scope and nature of 137 contributions. It may also specify affiliations. 139 (4) The Author Address section at the end of the RFC must include 140 the authors listed in the front page header. The purpose of 141 this section is to (1) unambiguously define author/contributor 142 identity (e.g., the John Smith who works for FooBar Systems) and 143 to (2) provide contact information for future readers who have 144 questions or comments. 146 At the discretion of the author(s), contact addresses may also 147 be included in the Contributors section for those contributors 148 whose knowledge makes them useful future contacts for 149 information about the RFC. 151 (5) The RFC Editor may grant exceptions to these guidelines upon 152 specific IESG request or in other exceptional circumstances. 154 The optional Contributors section is intended to provide a level of 155 recognition greater than an acknowledgment and nearly equal to 156 listing on the front page. The choice of either, both, or none of 157 Contributor and Acknowledgment sections in a particular RFC depends 158 upon the circumstance. There is no fixed position for a Contributors 159 section or an Acknowledgments section within the body of the RFC. If 160 they appear, they must appear later than the Abstract section and 161 earlier than the Author's Address section. 163 4. TRANSITION 165 These guidelines will be published for Last Call. It is intended 166 that they will become applicable to all RFCs after the Yokahama 167 meeting. Until then, the RFC Editor and the IESG will ask for 168 voluntary compliance with these guidelines, even on documents that 169 have long been in process. 171 ACKNOWLEDGMENTS 173 We are grateful for the input from IESG members and from a number of 174 individual members of the IETF community who share our concern for 175 doing the right thing. 177 Security Considerations 179 There are no security issues in this document. 181 Authors' Addresses 183 Joyce K. Reynolds 184 RFC Editor 185 4676 Admiralty Way 186 Marina del Rey, CA 90292 188 EMail: rfc-editor@rfc-editor.org 190 Robert Braden 191 RFC Editor 192 4676 Admiralty Way 193 Marina del Rey, CA 90292 195 EMail: rfc-editor@rfc-editor.org 197 Full Copyright Statement 199 Copyright (C) The Internet Society (2002). All Rights Reserved. 201 This document and translations of it may be copied and furnished to 202 others, and derivative works that comment on or otherwise explain it 203 or assist in its implementation may be prepared, copied, published 204 and distributed, in whole or in part, without restriction of any 205 kind, provided that the above copyright notice and this paragraph are 206 included on all such copies and derivative works. However, this 207 document itself may not be modified in any way, such as by removing 208 the copyright notice or references to the Internet Society or other 209 Internet organizations, except as needed for the purpose of 210 developing Internet standards in which case the procedures for 211 copyrights defined in the Internet Standards process must be 212 followed, or as required to translate it into languages other than 213 English. 215 The limited permissions granted above are perpetual and will not be 216 revoked by the Internet Society or its successors or assigns. 218 This document and the information contained herein is provided on an 219 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 220 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 221 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 222 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 223 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 225 Acknowledgement: 227 Funding for the RFC Editor function is currently provided by the 228 Internet Society.