Summary

  • draft-fengfar-led-01 recommends that IETF participants form their position before using AI, review output for fidelity and “always be transparent,” but it is an active individual draft rather than IETF policy.
  • The draft covers email, slides, repository discussion and possibly instant messages; it expressly leaves Internet-Draft and RFC body text outside its scope because those contributions also engage BCP 78 and BCP 79.
  • A useful disclosure must identify the accountable human, tool function, affected contribution, evidence and fidelity checks, final approval and correction path. “AI used” alone proves none of those things.

Three words, no defined record

The shortest recommendation in a 16-page Internet-Draft carries the largest governance burden: “Always be transparent.”

That sounds clear until a participant tries to comply. Does a grammar correction count? What about translation into English, retrieval of an old mailing-list thread, a generated counterargument, a rewritten paragraph, code produced for an example, or an agent allowed to send a message? Is disclosure attached to the whole email, one section, one claim or the enduring discussion record? What did the human actually check?

The draft does not pretend those questions are settled. Version 01 calls its recommendations extremely tentative. Its conclusion is even plainer: it is too early to say. The document's stronger claim is that the IETF should develop guidance before confidence in email discussion erodes.

That state matters. Datatracker lists draft-fengfar-led-01 as an active individual Internet-Draft. It has no RFC stream, responsible Area Director or telechat date. Its IESG state is simply I-D Exists. The 31 July message that introduced the work called it rough, non-prescriptive and non-authoritative. The 6 August revision incorporated points raised on the general discussion list. None of that constitutes Working Group adoption, rough consensus, IESG approval or an IETF rule.

The news on 26 August was attention, not adoption. An APNIC Blog essay by George Michaelson connected the IETF debate to the English-language burden in standards and RIR policy work and argued that communities should formalise how AI use is understood. The page also says that its author's views do not necessarily represent APNIC. It widens the question; it does not answer it for the IETF.

The draft draws an important scope line

The proposed discussion is narrower than “AI in standards.” It covers text used in IETF discussions: mailing-list messages, meeting slides, GitHub issues and pull requests, and potentially instant messages. It expressly excludes text inside Internet-Drafts and RFCs. Those documents engage additional contribution and intellectual-property arrangements under BCP 78 and BCP 79.

That distinction prevents a common shortcut. A future guideline for mailing-list messages would not automatically decide how authorship, contribution rights or disclosure work inside a standards document. Conversely, a declaration in an Internet-Draft acknowledgment would not necessarily explain whether dozens of surrounding list messages were translated, summarised, generated or sent autonomously.

The draft began with a concrete conflict of interpretation. One participant used AI to help express ideas formed independently. A reader saw LLM-like prose and disengaged because the human share was unclear. The authors present those two perspectives together rather than declaring one side correct. Their shared problem is the missing norm.

Their proposed human boundary is useful. Form the position before engaging AI. Review the output for fidelity to that position, not merely for grammatical correctness. Do not delegate the decision about what to think. Take full responsibility for what is sent under one's name.

But responsibility stated as a principle is not yet responsibility recorded as evidence.

Three neighbouring records have three different authorities

The closest operational comparison sits beside the IETF, not inside it. RFC 9775 is the IRTF Code of Conduct. It says explicitly that it represents consensus of the Internet Research Steering Group, is not an IETF product and is not a standard. The IRTF and IETF share infrastructure and meetings but have different purposes and processes.

For IRTF material, RFC 9775 already sets a threshold. Generative AI cannot be named as an author. Significant amounts of generated text or other content must be disclosed, for example by identifying the system and how it contributed. Spelling, grammar, translation and presentation improvements need not be disclosed.

That is one real rule, but only in its stated domain. Importing it silently into IETF discussion would erase the very authority boundary the RFC takes care to publish.

The World Wide Web Consortium offers a second comparison. A March 2026 W3C Advisory Board Group Note says each individual remains responsible for their output and recommends a clear label when content is primarily produced by an LLM. It also asks contributors to check correctness, protect confidential information and avoid replacing deliberation with automated replies. The document is endorsed by the Advisory Board, not by W3C as a whole or its Members.

The thresholds differ. IRTF says “significant amounts.” The W3C note says “primarily output.” The IETF individual draft says “always be transparent” while recording a warning that declarations could become as routine and uninformative as cookie banners. These are not three versions of one global rule. They are three differently authorised attempts to locate an accountability boundary.

The real asymmetry is reader time

AI assistance can lower a genuine participation cost. A precise technical idea and idiomatic English are not the same achievement. Translation and editing can let a participant spend less effort on surface form and more on the engineering question.

The same tool can move cost in the other direction. One sender can produce polished, exhaustive responses much faster than many readers can examine them. A civil message can still impose “second-hand burdening”: fact checking, finding the actual disagreement and deciding whether a human understands the claim. If many agents respond to one another, the volume can acquire the appearance of community attention without adding independent judgment.

This is why a generic label is too thin. It tells the reader that a tool was somewhere in the path. It does not reveal whether the tool translated a completed position, supplied an unverified factual claim, generated a summary of prior consensus, wrote the entire response or posted it without final human review.

Nor can style supply the missing evidence. The draft records concerns about walls of text, unnatural confidence and changed voice, but those are observations, not provenance. Treating polished English, speed or rhetorical pattern as proof would predictably burden non-native speakers and people who use accessibility tools. A detector score is an inference. A disclosure is an attributable statement. Neither automatically proves that the underlying claim is correct.

Daniel Kade's responsibility record

The smallest adequate unit is a contribution-scoped responsibility record.

It begins with a human sender and a stable contribution identifier. It names the tool's function: translation, editing, summarisation, drafting, retrieval, analysis, coding, moderation assistance or autonomous sending. It binds that function to a scope—the whole message, a named section, an attachment, a code fragment or selected claims.

It then records the material boundary. Did the tool operate only on public sources, on the sender's own local notes or on confidential material? That field should classify the boundary without exposing the material itself. Publishing full prompts, credentials, private deliberation or proprietary context would turn transparency into a new security failure.

The next fields record human work. Which factual sources and citations were checked? Was the prose reviewed for fidelity to the sender's actual position? Did a person approve the final contribution? Could the tool send or publish autonomously? Which policy version governed the disclosure, and where can an incorrect disclosure or contribution be corrected or superseded?

The model name may be useful context, but it is not the centre of the record. A vendor can update behaviour without changing a product label. More importantly, knowing the model does not prove that the human understood a protocol, checked a citation or accepted responsibility.

This is Daniel Kade's proposed record design, not a requirement in the draft. Its purpose is to preserve the human decision surface while making tool execution visible enough to audit.

Moderation cannot be the first definition

Current IETF governance already separates forum roles. RFC 9245 defines the general discussion list and routes IETF direction, policy and standards-process questions there when no better venue exists. RFC 9945 gives participants, administrators, moderators, Area Directors and the IESG different responsibilities across public online fora. It requires public procedures, reconsideration and appeal, and limits moderation action to disruptive communication.

Neither RFC creates an AI authorship detector or makes suspected AI use a standalone violation. If future guidance is tied to moderation, the disclosure rule must exist before sanctions do. It needs a threshold, evidence standard, notice, correction path and appeal. Otherwise a stylistic accusation can become procedural power.

The draft itself captures this danger. It recommends that questions about suspected tool use be non-accusatory. It also records concern that new participants will not know a new policy and that assumptions about access to AI tools can create another participation barrier.

The safe sequence is therefore narrow: define functions and scope, test a responsibility record, measure whether it reduces reader burden, and only then decide whether any undisclosed use is conduct, moderation or merely guidance. A tool label should never become a speech licence, and its absence should not become proof of deception.

What should not be inferred

The IETF has not adopted or rejected AI-assisted participation. The draft does not show that generated text altered an actual consensus outcome. It does not establish that every assisted message must be disclosed today.

RFC 9775 does not govern ordinary IETF standards discussion simply because it is published in the RFC Series. The W3C Group Note does not express W3C Member consensus. Michaelson's APNIC Blog essay does not announce APNIC policy.

There is no evidence in this package that a named participant misrepresented authorship or sent material autonomously. Language assistance neither proves nor disproves substantive understanding. No detector can replace attributable provenance, and no provenance record can replace technical review.

The bounded conclusion is that the discussion has correctly located the accountable human but has not yet defined the record that lets a reader inspect that responsibility. “Always be transparent” is a sound direction. Governance begins when the object, authority, evidence and correction path become specific.

Sources

  1. https://datatracker.ietf.org/doc/draft-fengfar-led/
  2. https://www.ietf.org/archive/id/draft-fengfar-led-01.html
  3. https://mailarchive.ietf.org/arch/msg/ietf/3VaBJ6pEdhtkpOtnZYA_HcVHejU/
  4. https://mailarchive.ietf.org/arch/msg/i-d-announce/_nalEUgYdyn7LdNfwQghXW9dPRc/
  5. https://blog.apnic.net/2026/08/26/the-emerging-role-of-ai-in-governance-discussion/
  6. https://www.ietf.org/rfc/rfc9775.html
  7. https://www.w3.org/TR/2026/NOTE-llms-standards-20260324/
  8. https://datatracker.ietf.org/doc/html/rfc9245
  9. https://datatracker.ietf.org/doc/html/rfc9945
  10. https://datatracker.ietf.org/doc/html/rfc5378
  11. https://datatracker.ietf.org/doc/html/rfc8179