RFC 7154

IETF Guidelines for Conduct 🎀

Okay bestie, so this is RFC 7154, published in March 2014 and written by S. Moonesamy, Ed. It's a Best Current Practice (BCP 54) from the Internet Engineering Task Force (IETF), and it obsoletes RFC 3184. The ISSN is 2070-1721. It's giving "updated and improved" energy 💅

Abstract ✨

This doc is a set of guidelines for how we act toward each other in the IETF 🫶 It's all about recognizing that people here are super diverse, valuing mutual respect, and remembering that our work applies to the whole Internet, not just one corner of it 🌈

This is an updated version of the conduct guidelines that first came out in RFC 3184.

Status of This Memo 🦋

This memo documents an Internet Best Current Practice.

This doc is a product of the IETF, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on BCPs, check out Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7154.

Copyright Notice 🌸

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this doc. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. Unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC or translating it into languages other than English.

1. Introduction 💖

The IETF runs on cooperation between a super diverse mix of people with different ideas and communication styles. Through these guidelines, the IETF wants to keep an environment where everyone is treated with dignity, decency, and respect 🫶 Participants are expected to act professionally as we build interoperable technologies for the Internet together. We try to follow these guidelines when we build consensus in person and over email. If conflicts come up, they get resolved using the procedures in RFC 2026 [RFC2026].

This document obsoletes RFC 3184 [RFC3184], because it's the updated version of the guidelines for conduct.

2. Guidelines for Conduct 👑

1. IETF participants extend respect and courtesy to their colleagues at all times.

IETF participants come from all kinds of origins and backgrounds, so expectations or assumptions can be different. No matter those differences, participants treat their colleagues with respect as people, especially when it's hard to agree with them. Basically: treat other participants the way you'd want to be treated 🥹

English is the de facto language of the IETF, but it's not the native language for many participants. Everyone, especially folks who speak English as a first language, should try to help others out by communicating clearly, like speaking slowly and not overusing slang. When English is hard to understand, participants make a sincere effort to understand each other and chat it out to clarify what was meant ✨

2. IETF participants have impersonal discussions.

We debate ideas with reasoned argument, not intimidation or personal attacks 🙅‍♀️ Try to bring data and facts to back up your standpoints, so everyone watching from the sidelines can form their own opinion. Discussion gets easier when the response to a simple question is a polite answer [SQPA] 🍓

3. IETF participants devise solutions for the global Internet that meet the needs of diverse technical and operational environments.

The IETF's mission is to produce high-quality, relevant technical and engineering documents that influence how people design, use, and manage the Internet, so that it works better. The IETF puts its emphasis on technical competence, rough consensus, and individual participation, and it needs to stay open to competent input from any source. We get that "scaling is the ultimate problem," and plenty of ideas that work great on a small scale fail that crucial test 📈

IETF participants use their best engineering judgment to find the best solution for the whole Internet, not just the best one for a particular network, technology, vendor, or user. We all have ideas that could use improvement from time to time, but no one shall ever knowingly contribute advice or text that would make a standard technically inferior 🧚

4. Individuals are prepared to contribute to the ongoing work of the group.

We follow the intellectual property guidelines in BCP 79 [RFC3979] 📜 IETF participants read the relevant Internet-Drafts, RFCs, and email archives so they get up to speed on the technology being discussed. Working Group sessions run on a super limited schedule, so participants sometimes have to limit their questions. The group's work keeps going on the mailing list, and questions can be asked and answered there. It can be a real challenge to join a Working Group without knowing the history of its longstanding debates 😭 Info about a Working Group, including its charter and milestones, is on the IETF datatracker site [TRACK] or from the Working Group Chair.

3. Security Considerations 🔐

The IETF guidelines for conduct do not directly affect the security of the Internet. However, there is an expectation that no one shall ever knowingly contribute advice or text that may adversely affect the security of the Internet without describing all known or foreseen risks and threats to potential implementers and users that they are aware of. This one is serious, bestie. Don't skip it 💀

4. Acknowledgements 🫶

Most of the text in this document is based on RFC 3184, which was written by Susan Harris. The editor wants to acknowledge that this document would not exist without her contribution. Mike O'Dell wrote the first draft of the Guidelines for Conduct, and many of his thoughts, statements, and observations are in this version. Many useful editorial comments came from Dave Crocker. Members of the POISSON Working Group added many significant bits to the text 🌈

The editor would also like to thank Jari Arkko, Brian Carpenter, Dave Cridland, Dave Crocker, Spencer Dawkins, Alan DeKok, Lars Eggert, David Farmer, Adrian Farrel, Stephen Farrell, Russ Housley, Eliot Lear, Barry Leiba, Ines Robles, Eduardo A. Suarez, Brian Trammell, and Sean Turner for helping improve the document ✨

5. References 📚

5.1. Informative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[RFC3184] Harris, S., "IETF Guidelines for Conduct", BCP 54, RFC 3184, October 2001.

[RFC3683] Rose, M., "A Practice for Revoking Posting Rights to IETF Mailing Lists", BCP 83, RFC 3683, March 2004.

[RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004.

[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005.

[SQPA] Perlman, R., "Miss Manners meets the IETF", March 2002, <http://www.ietf.org/proceedings/53/slides/plenary-3/index.html>

[TRACK] "The IETF Datatracker Tool", Web Application: <https://datatracker.ietf.org/wg>, Version 5.0.2.

Appendix A. Reporting Transgressions of the Guidelines 🚨

An individual can report transgressions of the guidelines for conduct to the IETF Chair or the IESG.

Appendix B. Consequences of Transgressing the Guidelines ⚖️

This document doesn't talk about measures that can be taken against a participant who transgresses the guidelines for conduct.

RFC 2418 [RFC2418] describes a measure where a Working Group Chair has the authority to refuse the floor to any individual who is unprepared or otherwise covering inappropriate material, or who, in the Chair's opinion, is disrupting the Working Group process.

RFC 3683 [RFC3683] describes "posting rights" action to remove the posting rights of an individual. RFC 3934 [RFC3934] describes a measure where a Working Group Chair can suspend the posting privileges of a disruptive individual for a short period of time.

Appendix C. Changes from RFC 3184 🦋

• Added text about the IETF striving to create an environment in which every person is treated with dignity, decency, and respect.
• Added text about contributing advice or text that may affect the security of the Internet.
• The recommendation that newcomers should not interfere with the ongoing process in Section 2 was removed, since it can be read as discouraging newcomers from joining discussions.
• The text about the goal of the IETF was replaced with text about the mission statement and what the IETF puts its emphasis on.
• The text about "think globally" was removed because its meaning wasn't clear.
• The text about English as a first language was clarified.
• The guideline about impersonal discussions was reworded as a positive statement.

Author's Address 💌

S. Moonesamy (editor) 76, Ylang Ylang Avenue Quatres Bornes Mauritius

EMail: sm+ietf@elandsys.com