]> Trinity College Dublin

College Green Dublin Ireland stephen.farrell@cs.tcd.ie

fengchongllly@gmail.com

General Network Working Group Internet-Draft 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. Discussion Venues Source for this draft and an issue tracker can be found at .

Introduction "IETF discussions" here includes emails sent to IETF lists, presentations (slides) used at meetings, text input during e.g. github issue or PR discussions, and potentially messages sent using IM tools. Text included within Internet-drafts and RFCs is not included in scope here, even though some of the same issues will arise. We omit those as Internet-drafts and RFCs are also covered by BCP 78 and BCP 79 so additional considerations apply for such text. AI language tools are now widely used in professional writing, including by some participants in standards development communities such as the IETF. This has produced at least two kinds of reaction: uncritical adoption, where AI output is used where previously a person would have written an email, and skepticism, where messages bearing the appearance of AI involvement are seen as problematic, on the basis that a reader cannot tell whether it is the person sending the email or just the AI tool, or some mixture. In order to explore these positions, it may be helpful to outline them in more detail, with the goal of better understanding what AI does well, what it does poorly, and where the boundary between them lies. This document grew out of a specific exchange on an IETF mailing list. One author described using AI to help express ideas developed independently; a reader flagged the output as LLM-generated and disengaged. Neither was wrong. But the exchange exposed a gap: the community lacks shared norms for how AI assistance should be used and disclosed in email discussions. Rather than treat this as a local disagreement, the two parties decided to try think through it and to document that discussion.

A Reader's Concerns This section is written by the first author. But readers may likely have guessed that anyway:-) Current AI tooling tends to emit text that can be readily seen to have involved that tooling. The following seem to be some of the current "tells" for AI having been used when one considers the stream of email messages arriving from a sender:

• Frequently being overly positive about a message to which this message is a reaction, e.g. "You've asked exactly the right question..."
• Unexpected/over-use of geometric terms, e.g. "The seam is..." or "There are 17 dimensions..."
• Specific phrasing patterns, e.g. "Fifteen wibbles: two designs."

However, a perhaps more disturbing pattern is the lack of uncertainty. It seems that people using AI tooling don't ask others what they mean, perhaps as AI tools make a statistical choice as to the meaning of earlier messages, then react as if that is a given. It's hard to see how that cannot lead to radical misunderstandings and, given AI tooling imperfections, senders emitting relative gibberish. Use of AI tooling also seems to correlate with "walls of text" that are very difficult to parse, both due to length (or seeming completeness), and complex sentence structures. Readers of such messages also generally have no insight into the tools used by senders, nor the level (if any) of human pre- or post-processing of AI inputs and outputs. In some cases, such messages may be sent in a time-frame that would seem impossible for a purely human-generated message, which also decreases confidence in the level of human input involved. All of the above means that a reader who considers that a message (or stream of messages) is largely the output from AI tools can have no confidence that they are really discussing a topic with the person who seemingly sent the email. At that point, the only rational action seems to be to ignore such messages as being equivalent to spam. Note that the above issues are not the same as the sock-puppet problem, or a sybil attack. These issues remain problems even when the sender of messages is known to be a real person engaged in IETF work. Despite all the above, readers do know that AI tools are being used and have to be dealt with, and that ignoring messages won't scale if use of those tools becomes more common, nor if the tools get better to the point where messages no longer expose use of such tools. And it has to be acknowledged that the translation capabilities of AI tools could be beneficial to the Internet community, in terms of opening up participation to many more capable engineers for whom communicating in English is a challenge. It therefore seems possibly useful to explore these issues in more detail, hence this draft. (This author does not expect this draft to eventually become an RFC.)

One Author's Workflow This section is written by the second author, who uses AI assistance in IETF participation. While this author's workflow does envisage use of AI tooling for Internet-draft and RFC text preparation, dealing with that aspect of tool-use isn't really part of this draft. The second author is a non-native English speaker who participates in IETF standardization work across several working groups. The following describes current practice in detail, as a basis for the discussion that follows.

Monitoring and Triage Incoming mailing list traffic is large and often spans multiple simultaneous threads. An AI assistant is used to scan the mailbox and identify threads or messages that appear relevant, including those that may warrant a reply. The author then reads the original messages directly. The AI provides a signal; the reading and judgment are the author's.

Forming a Position After reading, the author thinks about the issue independently. This step is not delegated. The AI may be used at this stage to stress-test an argument --- to articulate the strongest counter-position, or to explore whether an alternative interpretation holds --- but it does not originate the position. The author decides what to think before asking AI to help express it.

Drafting in English Once the author has decided what to say, an AI assistant produces an English draft. English is not the author's first language, and producing precise, idiomatic technical prose in a second language carries a real cognitive cost. AI removes that cost without changing who is responsible for the ideas. The author reviews this draft critically --- not for grammatical correctness, but for fidelity. If the output is too long, too polished, too neutral, or does not accurately represent the intended position, revisions are requested. This can take several rounds. The test is not "does this read well" but "does this say what I meant." One specific issue encountered is that AI output tends toward an artificially "balanced" stance --- hedging between positions instead of committing to one. Draft outputs may under-commit when compared to the author's actual position. This effect may not show up as a "tell" visible to readers of the eventual message, but can be visible to the author as one.

Final Review and Send The author personally reviews the final text before sending. The AI does not send mail autonomously. The author takes full responsibility for anything sent under their name.

The Role of Odyssey The author has developed a personal AI agent called Odyssey (https://github.com/meetodyssey). Odyssey maintains long-term context across conversations --- what subjects the author cares about, how they normally reason, what positions they have taken over time. The long-term goal is for AI-assisted output to become increasingly consistent with how the author would write independently, as the system accumulates a genuine model of the author's thinking rather than producing generic fluent prose. This points toward something important: the right relationship between a person and their AI tools is one that deepens over time, becoming more accurate to the individual rather than more generic.

Human and AI: Complementary Capabilities This section is also written by the second author. The issues described above reflect a genuine tension. To resolve it, it helps to be precise about what AI systems actually do well and what they do not.

What AI Does Well AI language systems operate effectively within known boundaries. Given a well-defined problem space --- an established body of knowledge, a clear communication goal, a defined set of constraints --- AI can draft, translate, and refine text with speed and consistency no individual can match; identify relevant prior work across large corpora; stress-test arguments by generating counter-positions; and execute repetitive cognitive tasks without fatigue. For participants in international technical communities, the language function alone is significant. The ability to express a precise technical idea in idiomatic English is not the same as having the idea. AI collapses the gap between the two, allowing non-native speakers to participate on more equal terms. More fundamentally, AI excels at operating within accumulated knowledge. The existing literature of a field, its terminology, its conventions, its prior decisions --- this is exactly the kind of material AI systems are built to handle.

What AI Does Poorly AI systems have a structural limitation that is frequently underestimated: they cannot originate. They recombine, extrapolate, and interpolate within the space of what they have been trained on. This is not a temporary limitation awaiting a better model. It is a consequence of what these systems are. Genuine innovation --- the creation of new conceptual territory rather than more efficient mapping of existing terrain --- remains a human capacity. The ideas that change a field do not emerge from pattern completion. They emerge from the collision of lived experience, accumulated frustration, specific domain knowledge, and the kind of lateral connection that has no prior example to learn from. The recognition that the current framework is wrong, or that the question being asked is the wrong question, is not available to a system trained to operate within existing frameworks.

The Symmetry Humans have the inverse limitation. We are slow to acquire and integrate knowledge within established boundaries. Learning a field takes years. Staying current across adjacent areas is nearly impossible for any individual. Expressing ideas precisely in a second language imposes a constant cognitive cost. AI removes these constraints. A researcher with AI assistance can engage with a much larger body of prior work, express ideas more precisely across language barriers, and iterate on arguments more rapidly than was previously possible. The symmetry is clean: humans originate, AI executes. Humans open new territory; AI operates efficiently within it. Neither is complete without the other.

A Collaborative Paradigm From this symmetry, a working paradigm emerges.

The Core Principle Humans originate. AI executes. The position, the argument, and the judgment are formed by the human before AI involvement begins. AI is used to express, refine, translate, or stress-test what the human has already worked out. The human reviews AI output not for grammatical correctness but for fidelity to their actual position. The human takes full responsibility for anything sent or published. This boundary is not always clean in practice. Using AI to stress-test an argument can surface considerations the human had not thought of, which then reshape the position. This is legitimate --- the AI is functioning as a thinking partner within a bounded space, not as an originator. The human remains the decision-maker about what to accept and what to discard. What falls outside this paradigm is delegating the thinking itself: asking AI what position to take, what arguments to make, or what conclusions to draw --- and signing the output.

Transparency as a Norm The workflow described in Section 3 was questioned. The author described it in detail. This exchange --- uncomfortable at first --- produced this document. Transparency is not a concession to critics of AI assistance. It is what makes the collaboration legitimate. An author who can describe exactly how AI was used, and who can stand behind the resulting text as an accurate representation of their position, has nothing to hide. An author who cannot answer those questions has a different problem, and it is not the AI.

The Deepening Relationship Generic AI assistance produces generic-sounding output. A system that accumulates genuine knowledge of an author's thinking, positions, and style produces output that more accurately represents them --- not because it is deceiving anyone, but because it has become a better instrument. This is the direction Odyssey points toward. Over time, the gap between "what the author would have written" and "what the AI-assisted author sent" narrows. The tool becomes more personal, more accurate, and paradoxically more transparent: the output is more genuinely the author's, not less.

What Becomes Possible The significance of this paradigm is not merely defensive --- not simply a justification for a practice that would otherwise be suspect. It is expansive. Things that were previously impossible for one person to accomplish --- engaging seriously with a large technical field while also pushing its boundaries, participating in international discourse while thinking in another language, tracking developments across multiple working groups while developing original contributions --- become achievable. This is the door the current moment opens. Not AI replacing human contribution, but AI extending the reach of what any human can contribute. The combination of human originality and AI execution capacity creates possibilities that neither possesses alone.

Risks The risks of AI-assisted writing are real, but frequently misdescribed. Attempting to describe them precisely should help. Both authors contributed to this section.

• AI replacement of thought. A primary risk is not AI assistance but the delegation of thinking itself --- asking AI what to believe, not just how to express a belief. This produces output that is fluent but not genuine, and over time it degrades the author's own capacity for independent thought, as well as putting the reader in an impossible position.
• Drift from the author's position. An author may form a genuine position but accept an AI draft that misrepresents it --- more confident, more agreeable, or more hedged than intended --- without noticing. Careful review of AI output exists to catch this. It requires the author to know their own position well enough to recognize when it has been distorted.
• Reader inability to distinguish. AI-assisted expression and AI-replaced thinking may produce similar surface output. Readers cannot easily tell them apart. This erodes the trust that makes mailing list discussion valuable, and it creates an asymmetry that disadvantages responsible users alongside irresponsible ones.
• Homogenization of discourse. AI systems have characteristic tendencies --- toward confidence, toward agreement, toward certain rhetorical patterns. Widely adopted without discipline, these tendencies flatten the diversity of perspective that technical communities depend on. A list where everyone's prose sounds similar, however polished, is a less productive list.
• Writing what one does not believe. Distinct from the above, an author may knowingly send AI output that does not reflect their actual position, using the tool as a shield against accountability.
• Emitting gibberish. AI tooling is imperfect, if we end up with multiple senders using AI tools and so essentially have AI tools running a substantive discussion, we are more likely to end up with gibberish.
• Discussion based on bad information. AI tooling might emit text that is based on outdated information or even hallucinated material. Senders need to check messages they send, and may need to be very familiar with the topic(s) being discussed, to ensure this does not occur.

While not properly described as a risk, the two authors of this draft do not currently agree as to whether it would be an overall positive or negative were there to be no "tells" visible in messages emitted with the assistance of AI tooling. More discussion is needed on that:-)

Initial Discussions This draft was raised on the IETF "discuss" list with some discussion ensuing. This section aims to record points raised in a way that may be more easily found than the list archive, as well as a few points raised off-list. Thus far, there has been no discussion solely on the github repo for this draft.

Possibly Relevant Policies Elsewhere Some other relevant policies and discussions were brought to the authors' attention and could feed into discussion of an IETF policy:

• one from W3C , which seems very relevant to this discussion, but that also seems nearly as tentative as this draft
• the EU AI act might contain some relevant clauses that might (or might not) call for disclosure of use of AI tooling in contexts such as standards-development
• the Irish courts have a very recent policy on the use of LLMs in court documents
• the IRTF's RASPRG discussed related topics at IETF-126

Other points

• one poster expressed that using LLMs during discussions seemed less "honest" to them, whereas using LLMs for Internet-draft text, tool development or testing/analysis seemed more acceptable
• the IETF may have some "self-defense" mechansisms that help us avoid some of the worst potential problems that could arise from using LLMs in discussions, e.g., physical (or online synchronous) meetings and slow progress making it easier to spot LLM usage over extended durations
• another risk is that people using LLMs might deliberately manipulate LLM tools to produce outputs that aren't really intended as part an IETF discussion, but rather to try to distort or disturb that discussion
• attempts to ban the use of LLMs as described here won't work
• any policy in this space won't be known to new participants who are therefore more likely to not conform to that policy (while this could be argued generally about any policy, it's perhaps very relevant here, given current trends)
• the IETF could encourage doing better in this space rather than simply denounce such uses
• there's a risk that if we don't try tackle this issue IETF mailing lists might end up like
• a sender's use of LLMs may make it harder for a reader to distinguish between a sender that is less well informed but who will learn from discussion, versus a sender that is not actually willing to learn from a discussion (and who perhaps doesn't understand that the LLM output is gibberish)
• over time, readers learn to expect and better interpret senders who use their own "voice" - interposing an LLM risks changes to that in ways that remove a tool IETF discussants have used for decades, (and for senders, LLM version changes might totally change the "voice" that readers perceive)
• some people just skip message they consider "vacuous and wordy" and believe many of those are LLM outputs
• some consider the "voice" of known participants as helpful in evaluating their inputs
• messages largely based on LLM outputs may be "boring"
• LLMs might be helpfule in discussions about the history of draft and e.g. whether or not merging some drafts might be good or bad
• "unfinished" LLM generated outputs seemingly describing something may waste the time of the (possibly many) readers of a message
• some code-of-conduct for use of LLMs might be useful, along with bans for breaches
• to the extent we assume "good faith" participation, use of LLMs may change our threat model for participation
• assuming that IETF participants have the resources and/or time to engage with LLM tools could be yet another barrier to participation
• IETF discussions should be for humans, and respect the amount of time readers have available to consider messages
• one could use LLM tools to shorten the messages one sends
• senders are 100% responsible for what they send - use any tooling (or send any message) at the risk of your reputation
• we are capable of bikeshedding on the name of a mailing list for disucssion of this topic, but we should have such a list
• perhaps the end result of this discussion should be a wiki page that evolves and not a policy expressed in an RFC
• well-connected people, with good English language skiils, have had an easier time in the past, maybe these tools might change that
• the IETF should actively take a position and declare requirements (for discussion) that suit our needs
• requiring declaration of LLM tool use might be like cookie-banners and become so common as to not be useful
• so far, someone's LLM output concluded "the discussion is constructive rather than polarised" ;-)
• LLM tools can help with translation, but increased acceleration (in terms of producing output) may inevitably correlate with a lack of understanding from the sender
• LLM use may disrupt reader's evaluation of sender reputation over time
• one poster suggested publishing community-specific guidance that participants could feed to their AI agents (e.g., bottom line up front, avoiding walls of jargon, double-checking assertions before posting) so that AI-assisted contributions start out closer to community norms

Recommendations These are extremely tentative recommendations, that may be wrong, but that seem worth considering:

• Form your position before engaging AI. The argument should be yours before the draft exists.
• Review AI output for fidelity, not just correctness. If the AI has softened, generalized, or shifted your position, correct it before sending.
• Always be transparent. Describing your workflow in detail builds trust rather than eroding it.
• Question senders if you think they are using AI tooling as to what they are doing. Doing that on-list should be considered acceptable, if it is not done in an accusatory manner.

Less tentatively, the IETF should develop guidelines for use of AI tooling when sending messages (esp email) in IETF discussions. That won't be easy and will be a moving target, but absent such guidance, confidence in email discussions may evaporate, which would cause significant damage to the IETF.

Conclusion It's too early to say really.

IANA Considerations This document makes no request of IANA.

Security Considerations Mischievous IETF participants could include AI prompts inside messages used in IETF discussions that could form part of an attack on participants who use AI tooling. Such text could, for example, only be present in the text/html part of a multipart/alternative email and so might not be rendered in a presentation of a mailing list archive. Presumably AI tool users will need to mitigate such threats in any case, so the new aspect here is perhaps only the use of IETF archives as the distribution medium for AI prompt attacks. Otherwise, see the section on risks.

Acknowledgments The second author used https://github.com/meetodyssey in preparing and discussing the above text. The first author made no use of AI tooling.

References Normative References 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. Informative References n.d.

Change Log

Draft-00

• This is based on email and github interactions between the authors.

Draft-01

• Reflect points raised on the IETF "discuss" list.