idnits 2.17.1 draft-moonesamy-ietf-conduct-3184bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 draft header indicates that this document obsoletes RFC3184, but the abstract doesn't seem to directly say this. It does mention RFC3184 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2014) is 3757 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) == Unused Reference: 'RFC2418' is defined on line 195, but no explicit reference was found in the text == Unused Reference: 'RFC3683' is defined on line 201, but no explicit reference was found in the text == Unused Reference: 'RFC3934' is defined on line 207, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3184 (Obsoleted by RFC 7154) -- Obsolete informational reference (is this intentional?): RFC 3979 (Obsoleted by RFC 8179) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Moonesamy, Ed. 3 Obsoletes: 3184 (if approved) 4 Intended Status: Best Current Practice 5 Expires: July 9, 2014 January 5, 2014 7 IETF Guidelines for Conduct 8 draft-moonesamy-ietf-conduct-3184bis-06 10 Abstract 12 This document provides a set of guidelines for personal interaction 13 in the Internet Engineering Task Force. The guidelines recognize the 14 diversity of IETF participants, emphasize the value of mutual 15 respect, and stress the broad applicability of our work. 17 This document is an updated version of the guidelines for conduct 18 originally published in RFC 3184. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as 28 Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright Notice 43 Copyright (c) 2014 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 50 S. Moonesamy IETF Guidelines for Conduct January 5, 2014 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 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials,this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 1. Introduction 73 The work of the IETF relies on cooperation among a diverse range of 74 people with different ideas and communication styles. The IETF 75 strives, through these guidelines for conduct, to create and maintain 76 an environment in which every person is treated with dignity, 77 decency, and respect. People who participate in the IETF are 78 expected to behave in a professional manner as we work together to 79 develop interoperable technologies for the Internet. We aim to abide 80 by these guidelines as we build consensus in person and through email 81 discussions. If conflicts arise they are resolved according to the 82 procedures outlined in RFC 2026 [RFC2026]. 84 This document obsoletes RFC 3184 [RFC3184] as it is an updated 85 version of the guidelines for conduct. 87 2. Guidelines for Conduct 89 1. IETF participants extend respect and courtesy to their colleagues 90 at all times. 92 IETF participants come from diverse origins and backgrounds; there 93 can be different expectations or assumptions. Regardless of these 94 individual differences, participants treat their colleagues with 95 respect as persons especially when it is difficult to agree with 96 them; treat other participants as you would like to be treated. 98 English is the de facto language of the IETF. However, it is not 99 the native language of many IETF participants. All participants, 101 S. Moonesamy IETF Guidelines for Conduct January 5, 2014 103 particularly those with English as a first language, attempt to 104 accommodate the needs of other participants by communicating 105 clearly, including speaking slowly and limiting the use of slang. 106 When faced with English that is difficult to understand IETF 107 participants make a sincere effort to understand each other and 108 engage in conversation to clarify what was meant. 110 2. IETF participants have impersonal discussions. 112 We dispute ideas by using reasoned argument rather than through 113 intimidation or personal attack. Try to provide data and facts 114 for your standpoints so the rest of the participants who are 115 sitting on the sidelines watching the discussion can form an 116 opinion. The discussion is easier when the response to a simple 117 question is a polite answer [SQPA]. 119 3. IETF participants devise solutions for the global Internet that 120 meet the needs of diverse technical and operational environments. 122 The mission of the IETF is to produce high quality, relevant 123 technical and engineering documents that influence the way people 124 design, use, and manage the Internet in such a way as to make the 125 Internet work better. The IETF puts its emphasis on technical 126 competence, rough consensus and individual participation, and 127 needs to be open to competent input from any source. We 128 understand that "scaling is the ultimate problem" and that many 129 ideas that are quite workable on a small scale fail this crucial 130 test. 132 IETF participants use their best engineering judgment to find the 133 best solution for the whole Internet, not just the best solution 134 for any particular network, technology, vendor, or user. While we 135 all have ideas that may stand improvement from time to time, no 136 one shall ever knowingly contribute advice or text that would make 137 a standard technically inferior. 139 4. Individuals are prepared to contribute to the ongoing work of the 140 group. 142 We follow the intellectual property guidelines outlined in BCP 79 143 [RFC3979]. IETF participants read the relevant Internet-Drafts, 144 RFCs, and email archives in order to familiarize themselves with 145 the technology under discussion. Working Group sessions run on a 146 very limited time schedule, and sometimes participants have to 147 limit their questions. The work of the group will continue on the 148 mailing list, and questions can be asked and answered on the 149 mailing list. It can be a challenge to participate in a working 150 group without knowing the history of longstanding working group 152 S. Moonesamy IETF Guidelines for Conduct January 5, 2014 154 debates. Information about a working group including its charter 155 and milestones is available on the IETF datatracker site [TRACK] 156 or from the working group chair. 158 3. Security Considerations 160 The IETF guidelines for conduct do not directly affect the security 161 of the Internet. However it is to be noted that there is an 162 expectation that no one shall ever knowingly contribute advice or 163 text that may affect the security of the Internet without describing 164 all known or foreseeable risks and threats to potential implementers 165 and users. 167 4. Acknowledgements 169 Most of the text in this document is based on RFC 3184 which was 170 written by Susan Harris. The editor would like to acknowledge that 171 this document would not exist without her contribution. Mike O'Dell 172 wrote the first draft of the Guidelines for Conduct, and many of his 173 thoughts, statements, and observations are included in this version. 174 Many useful editorial comments were supplied by Dave Crocker. 175 Members of the POISSON Working Group provided many significant 176 additions to the text. 178 The editor would like to thank Jari Arkko, Brian Carpenter, Dave 179 Cridland, Dave Crocker, Spencer Dawkins, Alan DeKok, Lars Eggert, 180 David Farmer, Adrian Farrel, Stephen Farrell, Russ Housley, Eliot 181 Lear, Barry Leiba, Ines Robles, Eduardo A. Suarez, Brian Trammell and 182 Sean Turner for contributing towards the improvement of the document. 184 5. IANA Considerations 186 [RFC Editor: please remove this section] 188 6. References 190 6.1. Informative References 192 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 193 3", BCP 9, RFC 2026, October 1996. 195 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 196 Procedures", BCP 25, RFC 2418, September 1998. 198 [RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC 199 3184, October 2001. 201 [RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF 203 S. Moonesamy IETF Guidelines for Conduct January 5, 2014 205 Mailing Lists", BCP 83, RFC 3683, March 2004. 207 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 208 Management of IETF Mailing Lists", BCP 25, RFC 3934, 209 October 2004. 211 [RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF 212 Technology", BCP 79, RFC 3979, March 2005. 214 [SQPA] 217 [TRACK] 219 Appendix A: Reporting transgressions of the guidelines 221 An individual can report transgressions of the guidelines for conduct 222 to the IETF Chair or the IESG. 224 Appendix B: Consequences of transgressing the guidelines 226 This document does not discuss about measures that can be taken 227 against a participant transgressing the guidelines for conduct. 229 RFC 2418 describes a measure where a Working Group Chair has the 230 authority to refuse to grant the floor to any individual who is 231 unprepared or otherwise covering inappropriate material, or who, in 232 the opinion of the Chair is disrupting the Working Group process. 234 RFC 3683 describes "posting rights" action to remove the posting 235 rights of an individual. RFC 3934 describes a measure where a Working 236 Group Chair can suspend posting privileges of a disruptive individual 237 for a short period of time. 239 Appendix C: Changes from RFC 3184 241 o Added text about the IETF striving to create an environment in 242 which every person is treated with dignity, decency, and respect. 244 o Added text about contributing advice or text that may affect the 245 security of the Internet. 247 o The recommendation that newcomers should not interfere with the 248 ongoing process in Section 2 was removed as it can be read as 249 discouraging newcomers from participating in discussions. 251 o The text about the goal of the IETF was replaced with text about 252 the mission statement and what the IETF puts its emphasis on. 254 S. Moonesamy IETF Guidelines for Conduct January 5, 2014 256 o The text about "think globally" was removed as the meaning was not 257 clear. 259 o The text about English as a first language was clarified. 261 o The guideline about impersonal discussions was reworded as a 262 positive statement. 264 7. Author's Address 266 S. Moonesamy (editor) 267 76, Ylang Ylang Avenue 268 Quatres Bornes 269 Mauritius 271 Email: sm+ietf@elandsys.com