]> Fastmail

brong@fastmailteam.com

Internet-Draft Participation in the IETF is by individuals. This document applies that principle now that software Agents can write and submit text. Each Identity belongs to one Human, and every Contribution has at least one accountable Human. Anonymous Contributions are not accepted, and no Human may use two Identities in the same piece of work. Reading the IETF's work requires no account or identification. Rough consensus is unchanged.

Introduction The IETF has always said that its Participants act as individuals (). Those statements assumed that a person typed every message and every draft. Agents can now draft text, post to mailing lists, open issues, and submit documents. This can be done at a volume no person could, and without Human supervision. This document doesn't restrict the tools people use. It says who is responsible for what they produce.

Out of Scope This document covers the link between a Human and their Identities. It does not cover coordination between separate Humans, such as "meatpuppets" recruited or directed to support a position, or the relationships between Humans and their employers, sponsors, or other affiliations. Rough consensus is not determined by counting Participants . Chairs and the IESG must still apply judgement, including to participation that appears coordinated. This document does not alter this responsibility.

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.

Identity:

The name a Human participates under, with the email addresses and accounts they use, such as a Datatracker account, a mailing list subscription, or a code repository account.

Agent:

Software that acts on behalf of a Human, including by producing or submitting text.

Requirements People can participate in the IETF via email, through the Datatracker, at in-person meetings, or through other issue trackers. The only requirement is that they be a Human, and are aware of their obligations under the IETF's BCPs as enumerated in the Note Well .

One Identity per Human Each Human SHOULD use one Identity; covers reasons why they might choose not to. An Identity MAY include several email addresses and accounts, for example for different affiliations or for personal and work use. Together they are one Participant.

One Human per Identity Each Identity MUST belong to exactly one Human, who is bound by the Note Well like every Participant. An Identity MUST NOT be shared. An organization or role, such as a working group's chairs or the IETF Secretariat, may act through its own address or account. It MUST have one or more accountable Humans. Each is accountable as if they had acted under their own Identity. Such an address is not an Identity and is not counted as a Participant.

Names A Human MAY participate under a name other than their real name, such as a pen name or a nickname. They MUST be willing to give their real name to the IETF when asked. Registering for an IETF meeting, in person or remote, already requires a real name .

Every Contribution Has an Accountable Human Every Contribution MUST be vouched for by at least one Human, who is accountable for it as a Contributor. They MAY use any tools, including Agents. Contributor obligations, including IPR disclosure and conduct , apply whether the Human typed the text or an Agent produced it. Nobody has to declare which tools they used, though it is polite to, except where the IPR rules require disclosure.

Co-authored Contributions When a Contribution has several authors, such as an Internet-Draft or a joint review, each author is a Contributor and fully accountable for it. Obligations are not divided between them. Each author MUST be a separate Human. An Agent MUST NOT be listed as an author, and a Human MUST NOT list another of their own Identities as a co-author.

Anonymity This document uses "anonymous" and "pseudonym" as defined in . Anonymity has real value: it lets people take part in political life when speaking under their own name would endanger them, their families, or their jobs . It is still incompatible with the IETF standards process, which depends on knowing who made each Contribution: Contributors grant rights and make representations (). From nobody in particular, these are worth nothing. IPR disclosure covers IPR the Contributor "reasonably and personally" knows of, including their employer's or sponsor's (). Nobody can check that without knowing who the Contributor is. A Human who takes part in the same discussion under several undisclosed Identities is deliberately misleading the chairs and other Participants. There are other ways to mislead; this document addresses only this one. Conduct guidelines and moderation act on people. A remedy escaped by creating a new Identity has no effect. Affiliations "are often used for identification" (). Readers weigh an argument partly by who is making it. Every Contribution MUST therefore be attributable to an identified Human. The IETF does not accept anonymous Contributions. A pseudonym is acceptable, provided the Human behind it will give their real name when asked ().

Reading Requires No Identity These requirements apply to contributing, not reading. The IETF commits to making its documents, mailing lists, attendance lists, and minutes publicly available (), and keeps a "publicly accessible record" (). Anyone MUST be able to read Internet-Drafts, RFCs, mailing list archives, issue trackers, meeting materials, minutes, and recordings without an account, a login, or identifying themselves. A reader can stay anonymous. A Contributor can't. Meetings already draw this line. Attendance has long been recorded, first on paper blue sheets and now by logging in to Meetecho (), and attendance lists are public. Minutes, materials, and recordings are open to anyone. This document applies the same split everywhere.

Multiple Identities A Human MAY use more than one Identity without publicly linking them, for example to work in an area that is sensitive for their employer or government, or to separate personal and professional work. Each Identity is subject to every requirement in this document. A Human MUST NOT use more than one Identity in the same piece of work, which includes at least: an Internet-Draft, any document derived from it, and any discussion, issue, review, or consensus call about them; a working group charter or BoF, and any discussion about either; and any nomination, petition, or other process in which Participants are counted. A Human MUST NOT create a new Identity to escape a remedy, or their history on an existing topic.

Enforcement Breaches are handled through the moderation processes in . Remedies apply to the Human, and so to all of their Identities.

Open Questions This document is a starting point. These questions are open: Should a "piece of work" be a single document or a whole working group? Working group scope is easier to check, but constrains people with good reasons to keep lines of work apart. Should unlinked Identities be linked privately, for example to the IETF Secretariat or the Ombudsteam, so that can be enforced without public exposure? When can a Human be asked for their real name, who can ask, and who can see it once given? Without a Datatracker account, what ties an email address to an Identity? How should the IETF verify that an Identity 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

Denial of service:

Agents can produce Contributions faster than people can read them. This document doesn't limit volume, but every Contribution has an accountable Human that moderation can act on, and all of a Human's Identities count as one.

False identification:

A claim that two Identities are the same person can be used to discredit someone or discount their support. Such a finding needs evidence and a chance to respond. If it is wrong, it and any remedy based on it must be withdrawn.

Credential compromise:

Contributions made by someone who has taken over a Human's address or account were not vouched for by that Human, who should report the compromise promptly. A claim of compromise can also be false, made to disown a Contribution, and is judged on its evidence. Credentials given to an Agent are not compromised: the Human is accountable for what the Agent does.

Privacy:

A link between Identities, or between an Identity and an affiliation, can expose a Human to the risks in . Any private record of such links is sensitive, and access to it should be limited to those enforcing this document.

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. The IETF has had a long tradition of doing its technical work through a consensus process, taking into account the different views among IETF participants and coming to (at least rough) consensus on technical matters. In particular, the IETF is supposed not to be run by a "majority rule" philosophy. This is why we engage in rituals like "humming" instead of voting. However, more and more of our actions are now indistinguishable from voting, and quite often we are letting the majority win the day without consideration of minority concerns. This document explains some features of rough consensus, what is not rough consensus, how we have gotten away from it, how we might think about it differently, and the things we can do in order to really achieve rough consensus. Note: This document is quite consciously being put forward as Informational. It does not propose to change any IETF processes and is therefore not a BCP. It is simply a collection of principles, hopefully around which the IETF can come to (at least rough) consensus. 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 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 Thanks to Martin Thomson for raising co-authored Contributions and whether an Agent could be a co-author.