Re: Dealing with LLMs in IETF discussions draft

[Orie <[e-mail]>]

Hi,

Allow me to jump straight to solutions : )

It sounds like the goal is more effective use of AI in IETF discussions.
Banning it won't work.
New participants won't be familiar with our policies, and we want AI to
bring them to us, and help them stay engaged, not push them away.
Over time we hope the dialogue will self-correct toward a set of norms we
all enjoy living with, or can at least tolerate.

Initially we would hope for voluntary adoption of additional context,
skills and methodology that improves everyone's experience.
This could be accomplished by offering IETF contributors some context they
can feed to their agents to improve the agents' behavior in this community,
for example:

1. Do not use emdashes.
2. Use bottom line up front when communicating on mailing lists.
3. Avoid walls of text with technical jargon, provide citations for terms
readers might not be familiar with.
4. Focus on technical discussions not personality issues, or non
technical commentary
5. Double check your assertions before posting them on a mailing list.
...etc.

Providing an easy way for IETF contributors to improve the quality of their
AI-assisted IETF contributions seems like an easy first step.

Another thing we can do, is invest in better reputation systems and tooling
for accessing them.
When I read comments from Stephen, I naturally consider them in the context
of my previous interactions with him and his expertise.
If you have an agent assisting you with judging consensus or focusing you
on where problems in a discussion may exist, you want to give that agent
some similar ability.
In small teams, you can address this by putting your org chart in the
agent's context, so it knows who you are and who your manager is, and can
generate text relevant to your role.
In the IETF, you might consider comments from previous security ADs on
security issues in your draft worth addressing before comments from first
time participants.
How will your AI know this?

Taking mailing list participation or internet draft counts directly would
not be wise, but other signals like in person meeting attendance, RFCs in
multiple streams, or other signals that are hard for an AI to forge can be
helpful when considering a contribution in the context of wider community
discussions.

This is an important topic, if we don't start tackling it, we will end up
with IETF mailing lists turning into their own flavor of:
https://en.wikipedia.org/wiki/Moltbook

Cheers,

OS

PS: Here is this same email rewritten by Claude with the prompt: "Make this
email shorter, and more professional"

Hi,

Let me jump straight to solutions.

The goal here is more effective use of AI in IETF discussions. Banning it
won't work. New participants won't know our policies, and we want AI to
bring them in and keep them engaged rather than push them away. Over time
the dialogue should self-correct toward norms we can all live with.

A reasonable first step is voluntary adoption of shared context that
improves agent behavior in this community. We could publish a short set of
guidelines IETF contributors can feed to their agents, for example:

1. Do not use em dashes.
2. Use bottom line up front on mailing lists.
3. Avoid walls of jargon; cite terms readers may not know.
4. Focus on technical substance, not personalities.
5. Verify assertions before posting.

Making it easy for contributors to improve the quality of their AI-assisted
contributions is low cost and high value.

A second step is better reputation signals and tooling to access them. When
I read a comment from Stephen, I weigh it against my prior interactions
with him and his expertise. An agent helping you judge consensus or locate
problems in a thread needs something similar. Small teams solve this by
putting the org chart in the agent's context. In the IETF, you might want
comments from former Security ADs on a security issue addressed before
those from first-time participants. How would your agent know that?

Raw mailing list or draft counts would be the wrong measure. Signals that
are harder to game, such as in-person meeting attendance or RFCs across
multiple streams, are more useful when weighing a contribution against the
wider discussion.

This is worth tackling now. If we don't, IETF mailing lists will end up as
their own flavor of https://en.wikipedia.org/wiki/Moltbook.

Cheers,

OS + Claude




On Fri, Jul 31, 2026 at 5:50 AM Nick Hilliard <[e-mail]> wrote:

> Stephen Farrell wrote on 31/07/2026 02:20:
>
> Myself and Chong Feng have posted an I-D [1] that (from two
> pretty different perspectives) aims to progress discussion
> of how we might better handle LLM text in IETF discussions.
>
> I think this'd be a fine topic for broad discussion.
>
>
> Hi Stephen,
>
> ok, this is interesting.
>
> On a separate issue in a separate domain, the president of the high court
> of Ireland published a set of guidelines on Wednesday regarding the use of
> generative AI for legal documents.
>
>
> https://www.courts.ie/practice-directions/full-practice-direction?url=practice-direction-on-the-responsible-use-of-generative-artificial-intelligence-in-court-documents
>
>
> I haven't read the document thoroughly yet, but it's an interim legal
> guidance document so is likely to have had some competent thought put into
> it. Perhaps there are things in the document that could be used to inform
> the ietf discussion / your ID.
>
> Nick
>
>