| Internet-Draft | LLM Email Discussions | July 2026 |
| Farrell & Feng | Expires 31 January 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/sftcd/led.¶
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 31 January 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.¶
"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 [RFC5378] and BCP 79 [RFC8179] 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.¶
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.)¶
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.¶
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.¶
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.¶
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.¶
From this symmetry, a working paradigm emerges.¶
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.¶
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.¶
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.¶
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.¶
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:-)¶
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.¶
It's too early to say really.¶
This document makes no request of IANA.¶
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.¶
The second author used https://github.com/meetodyssey in preparing and discussing the above text.¶
The first author made no use of AI tooling.¶