Summary

  • draft-moonesamy-authorship-ietf-00, posted on 9 September 2026, is an active individual Internet-Draft. It is not adopted IETF work, approved policy or evidence of a community decision.
  • The draft asks whether the IETF should create procedural guidance for generative-AI authorship and suggests a rapid verbal exchange as one way for a working group to sense a human element.
  • A spontaneous discussion can test a person’s command of a proposal. It cannot establish textual provenance, consent, intellectual-property clearance, the scope of software assistance or long-term responsibility for a revision.
  • I propose a revision-scoped authorship record that keeps those claims separate. It is an editorial governance proposal, not a requirement in either active authorship draft.

A new submission opens a question, not a rule

The news is the appearance of a process argument in the Internet-Draft repository. The Datatracker records revision 00 of Reflections on IETF Authorship at 11:19 UTC on 9 September. It is active and carries the state I-D Exists, but has no RFC stream, responsible Area Director or IESG processing path. The IETF’s own guidance is explicit that anyone may submit an I-D and that an individual draft has no formal standing unless a later process gives it one.

That status is particularly important here because the document speaks about institutional practice. It surveys recurring arguments over authors, editors, contributors and acknowledgements, then turns to generative AI. It asks whether the community should be expected to adopt or implement specifications written with such tools, and whether procedural guidelines would be better than leaving the question to author or editor discretion.

The draft does not answer those questions. It does not define prohibited or permitted tool use, a disclosure threshold, an authorship test, a reviewer, a sanction or an appeal route. Its observation that 2026 saw more -00 submissions, possibly because generative tools lowered the skill barrier to drafting, is the author’s explanation. It is not an IETF finding about cause, quality or abuse.

The proposal’s most concrete move is modest: a working group could use a quick “cut and thrust” discussion with an author to gain a sense of the human element. That is useful as a governance clue. It is not yet an authorship procedure.

The live exchange tests command, not provenance

A real-time technical discussion produces evidence that a prepared script cannot fully provide. A participant must connect assumptions, respond to objections, distinguish a counterexample from a change of scope and explain why one design choice survives another. A group can learn whether the person understands the proposal deeply enough to defend it and whether disagreement exposes a genuine gap.

That evidence is valuable. It is also narrow. A person can understand a document they did not write. A principal author can be a poor spontaneous speaker. A contributor may know one section better than the editor whose name appears on the first page. A multilingual participant may need more time to formulate an answer without having less responsibility for the technical result. None of those cases makes the live exchange dishonest; they show why it cannot carry every authorship claim.

The exchange also cannot reconstruct the document’s custody. It cannot tell a working group which paragraphs were supplied by a person, adapted from an earlier RFC, generated by a software tool, or rewritten after review. It cannot establish whether every listed author consented, whether copied material was acknowledged, whether the submitter could make the BCP 78 and BCP 79 assertions, or whether a later revision preserved the same division of labour.

A live answer is therefore an observation about command at a moment. Authorship is a continuing record about contribution, consent and responsibility across revisions. Treating the first as proof of the second would turn a useful discussion technique into an evidentiary shortcut.

Existing texts already separate several kinds of authority

The surrounding IETF and RFC record helps locate the gap. The active 2021 IESG statement rejects “surprise authorship”: no one should be listed as an author or contributor without consent and significant contribution. It warns that names must not be used to manufacture an appearance of support, and connects consent with the submitter’s BCP 78 and BCP 79 assertions.

RFC 7322 gives the relevant stream authority over the author or editor list. It generally limits the first page to five people, asks a stream-approving body to review larger lists, and connects listed authors and editors with AUTH48 approval and later inquiries such as errata. The 2024 IESG statement on comments and credit separately describes authors, contributors and acknowledgements by degree of contribution.

None of those records says that names on an IETF-stream document create consensus. RFC 8789 puts that authority elsewhere: an IETF-stream document must represent IETF rough consensus. The people who draft, edit, contribute, approve and implement a specification can overlap, but those roles are not interchangeable.

The second active individual draft matters too. Revision 06 of Principles and Guidelines for Assignment of RFC Authorship says listed authors and editors remain responsible for the content, an AI tool must not be credited as an author, and human authors remain responsible for AI-produced material and intellectual-property matters. Its possible expectation to disclose substantial AI use is explicitly labelled an open issue. It is evidence of active policy work, not a finished rule that the new reflection can assume.

The missing artifact is a revision-scoped authorship record

The practical answer is not to make every working-group conversation an examination. It is to ask each control for the proposition it can honestly support. A live exchange can test command. A contribution history can show who supplied or materially changed text. Explicit consent can show who accepted a name and role. A rights record can show what contribution assertions were made. Issue and ballot records can show how a group or stream reached a decision.

A compact authorship record for each material revision could preserve six things:

  1. the accountable authors and editors, their roles, and their explicit consent to be listed;
  2. significant human contributions and reused text that require credit or acknowledgement;
  3. the declared scope of software assistance, tied to sections or change sets rather than a vague document-wide label;
  4. the human verification performed, including important uncertainties that remain open;
  5. the working-group, stream or other process decision that accepted the text without pretending that acceptance proves authorship; and
  6. a final responsibility confirmation when the document enters stream review and again when listed authors or editors approve AUTH48 changes.

This would not be an AI detector. It would not score prose, demand disclosure for spelling tools, or infer deception from writing style. It would record accountable acts that participants can attest to. Nor would it replace the existing freedom of each RFC stream to determine its author list and procedures.

The result would also protect legitimate tool use. A contributor who used translation help or a grammar tool would not be forced into the same category as a team that delegated substantial technical drafting. A human who used generation, checked every claim and accepted responsibility could disclose that path without pretending the tool became an author. A community could then debate the acceptability of the method with a record of what actually happened.

Sources