| Internet-Draft | All Individuals | November 2026 |
| Gondwana | Expires 6 May 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 6 May 2027.¶
Copyright (c) 2026 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The IETF has always said that its Participants act as individuals (Section 8). 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.¶
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. The exception is IPR disclosure for ideas a Contributor takes from others (Section 4.1).¶
Rough consensus is not determined by counting Participants [RFC7282]. Chairs and the IESG must still apply judgement, including to participation that appears coordinated. This document does not alter this responsibility.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses "Contribution", "Contributor", and "Participant" as defined in [RFC8179] and [RFC5378].¶
A natural person.¶
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.¶
Software that acts on behalf of a Human, including by producing or submitting text.¶
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 [NOTEWELL].¶
Each Human SHOULD use one Identity; Section 5 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.¶
Each Identity MUST belong to exactly one Human, who is bound by the Note Well [NOTEWELL] 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.¶
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 [MEETING-TERMS].¶
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 [RFC8179] and conduct [RFC7154], 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 [RFC5378] [RFC8179] require disclosure.¶
This document uses "anonymous" and "pseudonym" as defined in Section 3.3 of [RFC6973].¶
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 [RFC8280]. It is still incompatible with the IETF standards process, which depends on knowing who made each Contribution:¶
Contributors grant rights and make representations (Section 5 of [RFC5378]). 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 (Section 5.6 of [RFC8179]). 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 [RFC7154] and moderation [RFC9945] act on people. A remedy escaped by creating a new Identity has no effect.¶
Affiliations "are often used for identification" (Section 3.2 of [RFC9281]). 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 (Section 3.3).¶
Contributions often carry ideas from people who are not Participants, such as colleagues who discussed a draft with its author. The Contributor need not name them. The Contributor is accountable for the whole Contribution as if every idea in it were their own. This is not an anonymous Contribution, because an identified Human has taken responsibility for it.¶
That accountability includes IPR. A Contributor SHOULD ask the people whose ideas they bring into a Contribution whether they know of IPR that Covers those ideas. What they learn is then IPR they personally know of, which they MUST disclose [RFC8179]. Bringing ideas in through someone else, so that the person who knows of IPR never Participates and the person who Participates never learns of it, is a violation of IETF IPR policy, just as failing to disclose is (Section 6 of [RFC8179]).¶
These requirements apply to contributing, not reading. The IETF commits to making its documents, mailing lists, attendance lists, and minutes publicly available (Section 1 of [RFC3935]), and keeps a "publicly accessible record" (Section 8 of [RFC2026]).¶
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 ([RFC9592]), and attendance lists are public. Minutes, materials, and recordings are open to anyone. This document applies the same split everywhere.¶
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.¶
Breaches are handled through the moderation processes in [RFC9945]. Remedies apply to the Human, and so to all of their Identities.¶
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 Section 5 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?¶
The following documents state that participation in the IETF is by individuals.¶
Section 3.2 of [RFC9281] (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.¶
Section 1 of [RFC2418] (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.¶
Section 5 of [RFC8179] (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.¶
Section 1 of [RFC8179] defines a "Contributor" as "an individual submitting a Contribution", and a "Participant" as "any individual Participating in an IETF discussion or activity". Section 1 of [RFC5378] (BCP 78) uses the same definition of "Contributor".¶
Section 2.2 of [RFC7241]:¶
All IETF participants act as individuals. There is no concept of "IETF membership".¶
Section 4.1 of [RFC9680]:¶
While IETF participants are expected to participate as individuals, their actions could still be construed as representing their employer, whatever their role.¶
Section 2.1 of [RFC8718]:¶
Meeting attendees participate as individuals.¶
Appendix A.1 of [RFC6702] describes the IPR obligations as "personal requirements applying to all IETF participants as individuals".¶
Section 5 of [RFC2026] 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 [RFC9592], says "There is no membership in the IETF."¶
The IRTF's code of conduct [RFC9775] 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.¶
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 [RFC9945] can act on, and all of a Human's Identities count as one.¶
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.¶
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.¶
A link between Identities, or between an Identity and an affiliation, can expose a Human to the risks in Section 4. Any private record of such links is sensitive, and access to it should be limited to those enforcing this document.¶
This document has no IANA actions.¶
Thanks to Martin Thomson for raising co-authored Contributions and whether an Agent could be a co-author.¶