]> Fastmail

brong@fastmailteam.com

Internet-Draft Participation in the IETF is by individuals. This document makes that principle concrete for an environment in which software agents can produce and submit text. Each Datatracker account belongs to one human who has acknowledged the Note Well. Every IETF Contribution is vouched for by one human who is accountable for it. Anonymous Contributions are not accepted, and no human may use more than one identity in the same piece of work. Reading the IETF's work remains open to everyone, with no account or identification required.

Introduction The IETF has always said that its participants act as individuals. The existing statements of this principle are collected in . Those statements were written when every message to a mailing list and every Internet-Draft was typed by a person. That is no longer a safe assumption. Agents can now draft text, post to mailing lists, open issues, and submit documents, and can do so at a volume no person could. This document doesn't restrict the tools people use. It states who is responsible for what those tools produce.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses "Contribution", "Contributor", and "Participant" as defined in and .

Human:

A natural person.

Account:

A Datatracker account, and the credentials associated with it.

Agent:

Software that produces or submits text, or takes other actions, on behalf of a human.

Requirements

One Account per Human Each human participating in the IETF SHOULD have one Datatracker account. describes the limited case in which a human holds more than one. A human MAY associate multiple email addresses with their account. Using different addresses for different affiliations, or for personal and work use, is common and expected. Addresses on one account are linked, and the IETF treats them as one participant.

One Human per Account Each Datatracker account MUST belong to exactly one human. That human MUST have acknowledged the Note Well . An account MUST NOT be shared between people, and MUST NOT be operated by an organization or a role in place of a named human.

Every Contribution Has an Accountable Human Every Contribution MUST be vouched for by one human, who is accountable for it as its Contributor. That human MAY use any tools, including agents, to prepare or submit the Contribution. The obligations that apply to a Contributor, including IPR disclosure under and conduct under , apply to the human who vouches for it. They apply in the same way whether the human typed the text or an agent produced it.

Anonymity This document uses "anonymous" and "pseudonym" as defined in . Anonymity has real value. People use it to take part in political life where speaking under their own name would put them, their families, or their jobs at risk. treats anonymity as a human rights consideration in protocol design for these reasons. Anonymous participation is still incompatible with the IETF standards process. The process depends on knowing which human made each Contribution: A Contributor grants rights in their Contribution and makes representations about it (). A grant or a representation from nobody in particular is worth nothing. IPR disclosure obligations attach to IPR that the Contributor "reasonably and personally" knows of, including IPR held by their employer or sponsor (). Nobody can tell whether that obligation has been met without knowing who the Contributor is. Rough consensus is judged by chairs who read the discussion. If one human can appear as several participants, the chairs can't tell how much support or opposition there really is. The guidelines for conduct and the moderation processes act on people. A sanction that can be escaped by creating a new account has no effect. Affiliations "are often used for identification" (). Readers weigh an argument partly by knowing who is making it and what interests they may have. Every Contribution MUST therefore be attributable to an identified human, as required by . The IETF does not accept anonymous Contributions.

Reading Requires No Identity The requirements in this document apply to contributing. They do not apply to reading. The IETF's mission commits it to "making our documents, our WG mailing lists, our attendance lists, and our meeting minutes publicly available on the Internet" (), and the standards process requires a "publicly accessible record" of its activities (). Anyone MUST be able to read Internet-Drafts, RFCs, mailing list archives, issue trackers, meeting materials, minutes, and recordings without an account, without logging in, and without identifying themselves. Nothing in this document anticipates or requires a login to read the IETF's work. A reader can stay anonymous. A contributor can't. The IETF already draws this line for meetings. Attending a session has long been recorded: the blue sheets were "paper forms on which everyone writes their name and their affiliation", and for remote attendance "attendance is handled by accessing the application" (). Today, entering a session means logging in to Meetecho, and attendance lists are part of the public record (). The minutes, materials, and recordings of those sessions are published for anyone to read without logging in. This document applies the same split to every other way of taking part.

Multiple Identities A human may want to take part in the IETF under an identity that is not publicly linked to their existing account. Reasons include changing employers, working in an area that is sensitive for their employer or government, or separating personal and professional work. A human MAY hold more than one account, each used for a different piece of work, without publicly linking them. Each account is still subject to every requirement in this document: it belongs to one identified human who has acknowledged the Note Well, and that human is accountable for every Contribution made from it. A human MUST NOT use more than one identity to contribute to the same piece of work. For the purposes of this document, a "piece of work" includes at least: an Internet-Draft and any later document derived from it; any discussion, issue, review, or consensus call about such a document; and any nomination, petition, or other process in which participants are counted. A human MUST NOT create a new account to avoid a sanction applied to an existing one, or to avoid the history attached to it on an existing topic.

Open Questions This document is a starting point for discussion. These questions are expected to be debated. Is a working group the right scope for a "piece of work", or is a single document enough? Working group scope is easier to check, but it may exclude people who have good reasons to keep two lines of work apart. Should an account with no public link to a human's other accounts still be linked privately, for example by disclosure to the IETF Secretariat or the Ombudsteam? That would allow enforcement of without exposing the link publicly. Is a pseudonym acceptable on a single account, if the human behind it is known to the IETF and accountable in the same way as anyone else? How should the IETF verify that an account belongs to one human, and how much verification is proportionate?

Existing Principle The following documents state that participation in the IETF is by individuals. (BCP 11):

• For all purposes relevant to the Internet Standards development process, membership in the IETF and its WGs is defined to be established solely and entirely by individuals who participate in IETF and WG activities. These individuals do not formally represent any organizations they may be affiliated with, although affiliations are often used for identification.

(BCP 25):

• There is no formal membership in the IETF. Participation is open to all. [...] Participation is by individual technical contributors, rather than by formal representatives of organizations.

(BCP 79):

• This document refers to the IETF Participant making disclosures, consistent with the general IETF philosophy that Participants in the IETF act as individuals.

defines a "Contributor" as "an individual submitting a Contribution", and a "Participant" as "any individual Participating in an IETF discussion or activity". (BCP 78) uses the same definition of "Contributor". :

• All IETF participants act as individuals. There is no concept of "IETF membership".

:

• While IETF participants are expected to participate as individuals, their actions could still be construed as representing their employer, whatever their role.

:

• Meeting attendees participate as individuals.

describes the IPR obligations as "personal requirements applying to all IETF participants as individuals". notes that the IAB and IESG "are composed of individuals who may participate, as individuals, in the technical work of the IETF". The final version of the Tao of the IETF, archived in , says "There is no membership in the IETF." The IRTF's code of conduct says a generative tool must not be listed as an author of a document, and that significant amounts of AI-generated content must be disclosed.

Security Considerations TODO

IANA Considerations This document has no IANA actions.

This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process. The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries. This document is not an Internet Standards Track specification; it is published for informational purposes. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work. This document is an updated version of the guidelines for conduct originally published in RFC 3184. This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441. Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication. This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973). The other parts of this document explain the background of the guidelines and how they were developed. This document is the first milestone in a longer-term research effort. It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group. The IETF Administration Support Activity (IASA) is responsible for arranging the selection and operation of the IETF plenary meeting venue. This memo specifies IETF community requirements for meeting venues, including hotels and meeting space. It also directs the IASA to make available additional process documents that describe the current meeting selection process. This document retires and obsoletes the Tao of the IETF as an IETF-maintained document. This document also obsoletes RFC 6722, which describes the publication process of the Tao. Furthermore, this document describes the rationale for the retirement of the Tao. For archival purposes, the last version of the Tao is included in the appendix. Information that new participants need to engage in the work of the IETF will continue to be provided through the IETF website in a more timely and accessible manner. This is the way. This document provides education and guidance for IETF participants on compliance with antitrust laws and how to reduce antitrust risks in connection with IETF activities. This document describes the code of conduct for participants in the Internet Research Task Force (IRTF). The IRTF believes that research is most effective when done in an open and inclusive forum that encourages diversity of ideas and participation. Through this code of conduct, the IRTF continues to strive to create and maintain an environment that encourages broad participation, and one in which people are treated with dignity, decency, and respect. This document is a product of the Internet Research Steering Group (IRSG). The IETF community will treat people with kindness and grace, but not endless patience. This memo obsoletes RFCs 3683 and 3934, and it updates RFCs 2418 and 9245 by establishing a policy for the moderation of disruptive participation across the IETF's various public contribution channels and discussion fora. It establishes guardrails for moderation and a moderator team. That team will develop a set of moderation procedures and facilitate their consistent implementation with chairs and administrators. Trinity College Dublin The rapid adoption of AI language tools has prompted concern across professional and technical communities, including the IETF, about authenticity, accountability, and the integrity of human contribution. This document approaches the question from two directions: a critical reader's concerns about what AI use means for IETF discussion, and a practitioner's account of how AI is currently being used in IETF discussions. We aim to explore some of the issues arising, and perhaps make some specific (but tentative) recommendations, but the main recommendation is that the IETF should develop guidelines for use of AI tooling when engaging in IETF discussions. The University of Auckland This document discusses principles and guidelines for assigning authorship in RFC documents, including guidelines for the use of software tools during document preparation, and for inclusion of material from other sourcess. An important focus is on authors' responsibility for the content. The document also discusses the related issues of acknowledgements, editors and contributors. The various RFC streams are expected to apply these guidelines, and possibly define their own variations, which will have priority. [RFC825] was intended to provide guidance to authors of future RFCs. The memo also listed several reasons for publishing a memo as an RFC. It did not discuss who would be listed as author. This memo discusses authorship within the IETF and the use of generative Artificial Intelligence for IETF RFCs. Akamai Technologies Google LLC Harvard University (retired) The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. Akamai Technologies Harvard University (retired) This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. IETF

Related Work RFC Editor: please remove this appendix before publication. Other documents under discussion cover parts of the same ground: discusses the use of AI tools in IETF mailing list discussions and recommends that the IETF develop guidelines for them. It notes that the sock-puppet problem is a separate issue. This document addresses that issue. states that authors remain entirely responsible for any content generated by AI, and that an AI tool must not be credited as an author. This document applies the same principle to every Contribution, not only to RFC authorship. reflects on authorship in the IETF and asks whether the IETF should set guidelines for the use of generative AI by authors. Some documents cited here are being revised. would replace and keeps the text quoted in . would replace . References will be updated if those documents are published first.

Acknowledgments TODO