Re: Dealing with LLMs in IETF discussions draft
Orie <[email protected]> Fri, 31 Jul 2026 06:31:57 -0500
| Newsgroups | gmane.ietf.general |
|---|---|
| Message-ID | <CAMzqgox__8peG87iqX05pMLm+6K1ZUKuMkpATcCdUZ0S9gsjxg@mail.gmail.com> |
--000000000000ec6e890657e689d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Nick Hilliard <[email protected]> wro= te: > 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 o= f > generative AI for legal documents. > > > https://www.courts.ie/practice-directions/full-practice-direction?url=3Dp= ractice-direction-on-the-responsible-use-of-generative-artificial-intellige= nce-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 int= o > it. Perhaps there are things in the document that could be used to inform > the ietf discussion / your ID. > > Nick > > --000000000000ec6e890657e689d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi,<br><br>Allow me to jump straight to solutions : )<br><= br>It sounds like the goal is more effective use of AI in IETF discussions.= <br>Banning it won't work. <br>New participants won't be familiar w= ith our policies, and we want AI to bring them to us, and help them stay en= gaged, not push them away.<br>Over time we hope the dialogue will self-corr= ect toward a set of norms we all enjoy living with, or can at least tolerat= e.<br><br>Initially we would hope for voluntary adoption of additional=C2= =A0context, skills and methodology that improves everyone's experience.= <br>This could=C2=A0be accomplished by offering IETF contributors some cont= ext they can feed to their agents to improve the agents' behavior in th= is community, for example:<br><br>1. Do not use emdashes.<br>2. Use bottom = line up front when communicating=C2=A0on mailing lists.<br>3. Avoid walls o= f text with technical jargon, provide citations for terms readers might not= be familiar=C2=A0with.<br>4. Focus on technical discussions not personalit= y issues, or non technical=C2=A0commentary<br>5. Double check your assertio= ns before posting them on a mailing list.<br>...etc.<br><br>Providing an ea= sy way for IETF contributors=C2=A0to improve the quality of their AI-assist= ed IETF contributions seems like an easy first step.<br><br>Another thing w= e can do, is invest in better reputation systems and tooling for accessing = them.<br>When I read comments from Stephen, I naturally consider them in th= e context of my previous interactions with him and his expertise.<br>If you= have an agent assisting you with judging consensus or focusing you on wher= e problems in a discussion may exist, you want to give that agent some simi= lar ability.<br>In small teams, you can address this by putting your org ch= art in the agent's context, so it knows who you are and who your manage= r is, and can generate text relevant to your role.<br>In the IETF, you migh= t consider comments from previous security ADs on security issues in your d= raft worth addressing before comments from first time participants.<div>How= will your AI know this?<br><br>Taking mailing list participation or intern= et draft counts directly would not be wise, but other signals like in perso= n meeting attendance, RFCs in multiple streams, or other signals that are h= ard for an AI to forge can be helpful when considering a contribution in th= e context of wider community discussions.<br><br>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:=C2=A0<a href=3D"https://en.wikipedia.org= /wiki/Moltbook">https://en.wikipedia.org/wiki/Moltbook</a><br><br>Cheers,<b= r><br>OS<br><br>PS: Here is this same email rewritten by Claude with the pr= ompt: "Make this email shorter, and more professional"<br><br>Hi,= <br><br>Let me jump straight to solutions.<br><br>The goal here is more eff= ective use of AI in IETF discussions. Banning it won't work. New partic= ipants won't know our policies, and we want AI to bring them in and kee= p them engaged rather than push them away. Over time the dialogue should se= lf-correct toward norms we can all live with.<br><br>A reasonable first ste= p is voluntary adoption of shared context that improves agent behavior in t= his community. We could publish a short set of guidelines IETF contributors= can feed to their agents, for example:<br><br>1. Do not use em dashes.<br>= 2. Use bottom line up front on mailing lists.<br>3. Avoid walls of jargon; = cite terms readers may not know.<br>4. Focus on technical substance, not pe= rsonalities.<br>5. Verify assertions before posting.<br><br>Making it easy = for contributors to improve the quality of their AI-assisted contributions = is low cost and high value.<br><br>A second step is better reputation signa= ls 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 helpi= ng you judge consensus or locate problems in a thread needs something simil= ar. Small teams solve this by putting the org chart in the agent's cont= ext. In the IETF, you might want comments from former Security ADs on a sec= urity issue addressed before those from first-time participants. How would = your agent know that?<br><br>Raw mailing list or draft counts would be the = wrong measure. Signals that are harder to game, such as in-person meeting a= ttendance or RFCs across multiple streams, are more useful when weighing a = contribution against the wider discussion.<br><br>This is worth tackling no= w. If we don't, IETF mailing lists will end up as their own flavor of <= a href=3D"https://en.wikipedia.org/wiki/Moltbook">https://en.wikipedia.org/= wiki/Moltbook</a>.<br><br>Cheers,</div><div><br>OS=C2=A0+ Claude<br><br><br= ><br></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div = dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 31, 2026 at 5:50=E2=80=AFAM Ni= ck Hilliard <<a href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div><span>Stephen Farrell wrote on 31/07/2026=20 02:20:</span><br> <blockquote type=3D"cite">Myself and=20 Chong Feng have posted an I-D [1] that (from two <br> pretty different perspectives) aims to progress discussion <br> of how we might better handle LLM text in IETF discussions. <br> <br> I think this'd be a fine topic for broad discussion.<br> </blockquote> <br> Hi Stephen,<br> <br> ok, this is interesting.<br> <br> On a separate issue in a separate domain, the president of the high=20 court of Ireland published a set of guidelines on Wednesday regarding=20 the use of generative AI for legal documents.<br> <br> <blockquote type=3D"cite"><a href=3D"https://www.courts.ie/practice-directi= ons/full-practice-direction?url=3Dpractice-direction-on-the-responsible-use= -of-generative-artificial-intelligence-in-court-documents" target=3D"_blank= ">https://www.courts.ie/practice-directions/full-practice-direction?url=3Dp= ractice-direction-on-the-responsible-use-of-generative-artificial-intellige= nce-in-court-documents</a></blockquote> <br> I haven't read the document thoroughly yet, but it's an interim leg= al=20 guidance document so is likely to have had some competent thought put=20 into it. Perhaps there are things in the document that could be used to=20 inform the ietf discussion / your ID.<br> <br> Nick<br> <br> </div> </blockquote></div> --000000000000ec6e890657e689d2--