



Network Working Group                                          A. Farrel
Internet-Draft                                        Old Dog Consulting
Intended status: Informational                              1 April 2026
Expires: 3 October 2026


         The Emerging Application of AI in IETF Specifications
                    draft-farrel-catalist-ai4all-00

Abstract

   Over recent years we have seen the emergence of Artificial
   Intelligence (AI) systems as tools that can contribute to the
   specification, implementation, and operation of Internet
   technologies.

   This document examines the potential for making increased use of
   Machine Learning (ML) in the scope of the IETF.

Status of This Memo

   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 3 October 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Farrel                   Expires 3 October 2026                 [Page 1]

Internet-Draft               AI and the IETF                  April 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  AI For Networking (AI4NET)  . . . . . . . . . . . . . . .   3
       3.1.1.  Network Operations  . . . . . . . . . . . . . . . . .   3
       3.1.2.  Smart Routing . . . . . . . . . . . . . . . . . . . .   4
       3.1.3.  Power Saving  . . . . . . . . . . . . . . . . . . . .   4
       3.1.4.  AI for Security and Privacy . . . . . . . . . . . . .   4
     3.2.  Processing IETF RFCs  . . . . . . . . . . . . . . . . . .   4
       3.2.1.  Making State Machines . . . . . . . . . . . . . . . .   4
       3.2.2.  Spotting Errors in RFCs . . . . . . . . . . . . . . .   5
       3.2.3.  Coding from RFCs  . . . . . . . . . . . . . . . . . .   5
     3.3.  Contributing to the IETF  . . . . . . . . . . . . . . . .   5
       3.3.1.  Note-Taking in Meetings . . . . . . . . . . . . . . .   5
       3.3.2.  Reviewing Internet Drafts . . . . . . . . . . . . . .   6
       3.3.3.  Writing Emails  . . . . . . . . . . . . . . . . . . .   6
       3.3.4.  Developing Internet-Drafts  . . . . . . . . . . . . .   6
     3.4.  AI Working Groups . . . . . . . . . . . . . . . . . . . .   6
     3.5.  The AIETF . . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
   5.  Morality Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Many recent IETF meetings have been swamped with attempts to kick-
   start IETF work efforts involving Artificial Intelligence (AI).  This
   has resulted in a large number of Internet-Drafts (I-Ds) being
   posted, and not a few entirely unofficial side meetings being held.








Farrel                   Expires 3 October 2026                 [Page 2]

Internet-Draft               AI and the IETF                  April 2026


   While it is clear from this that there is a lot of energy that can be
   expended on this new topic, it has not always been obvious where this
   energy should be directed and how the IETF can build upon the growing
   AI ecosystem to produce standards that are relevant in the modern
   world.

   This document examines the potential for making increased use of
   Machine Learning (ML) in the scope of the IETF.

2.  Terminology

   There are two key terms used in this document:

   *  AI: Artificial Intelligence.  Note that there is no implication
      that an AI system embodies any intelligence.

   *  ML: Machine Learning.  Note that a "machine" is generally defined
      as a contrivance that makes work easier.  There is no implication
      that the result of this work is in any way valuable.

   As is consistent with wider usage in the Internet community and in
   society in general, the distinction between AI and ML is unclear, and
   the terms will be used entirely interchangeably in this document
   without risk of adding any clarity.

   Other terms that may be of use to readers are:

   *  LLM: Large Language Model.  We are not really sure what is going
      on in this AI system, but we give it lots of data and it generates
      more data for us.

   *  HI: Human Intelligence.  Not all it is cracked up to be.

3.  Applicability

   This section briefly examines the applicability of AI in the IETF's
   work.

3.1.  AI For Networking (AI4NET)

3.1.1.  Network Operations

   The scope for using AI systems as a tool for enhanced network
   operations should be obvious to anyone skilled in the art.  Allowing
   a hallucinating system to turn on and off network equipment, steer
   traffic, and handle possible emerging faults in the network seems a
   completely practical and sane way to operate a piece of critical
   infrastructure.  As the well-known technology guru Julia Child



Farrel                   Expires 3 October 2026                 [Page 3]

Internet-Draft               AI and the IETF                  April 2026


   [Child] never said: "What could possibly go wrong?"

3.1.2.  Smart Routing

   An obvious next step in network operations using AI is to use an ML
   system to decide the best direction in which to forward a packet.
   While this might be conceived of as a macro-level traffic engineering
   [RFC9522] concept where AI can advise on the best way to steer
   traffic and what resources to consume, the concept should rapidly be
   expanded to allow AI to choose which way to forward each separate
   packet, and to select which packets would best be dropped so as to
   save the intended receiver the effort of processing them.

3.1.3.  Power Saving

   While many people suggest that AI may be used in networking to place
   traffic on paths that will consume less energy, and while AI is
   highly able to decide to drop packets that would cause the receiver
   to expend precious energy reserves, it must be remembered that any AI
   learning and inference processes consume vastly more power than could
   ever be saved within the network.  Therefore, the best way to use AI
   to save energy in the network is to not use AI to save energy in the
   network.

3.1.4.  AI for Security and Privacy

   ML is already used in many security systems to detect threads or
   developing attacks.  And the keyword here may be "developing" because
   AI is an obvious tool that can be used to develop attacks that can
   best bring down a network.

   We all feel a lot happier when details of our lives are run and
   controlled by a soulless machine.  None of us has ever been
   frustrated when navigating an automated system, and we are all
   completely comfortable that our personal details should be harvested
   and retained by a computerized robot overlord.

3.2.  Processing IETF RFCs

3.2.1.  Making State Machines

   A valuable use of an LLM may be to post-process a protocol
   specification to develop a state machine (ideally a finite state
   machine, although the infinite is an attractive possibility) that can
   be used by developers to engineer code.  This will save coders a lot
   of time because they will no longer need to read specifications.





Farrel                   Expires 3 October 2026                 [Page 4]

Internet-Draft               AI and the IETF                  April 2026


3.2.2.  Spotting Errors in RFCs

   Documents produced by the RFC Editor are practically perfect.  It is,
   therefore, vanity to presume that an AI system that reads a published
   RFC would ever find any faults, errors, or holes in that work.  All
   it is likely to do is flag up some contrived scenario where, if one
   worries sufficiently hard and with a particular paranoid outlook, it
   may be possible to see (tilt your head to one side and squint)
   something that, if changed, would make the document, if not actually
   better, at least not significantly worse.

3.2.3.  Coding from RFCs

   An obvious extension to Section 3.2.1 is using AI (probably an LLM)
   to convert an RFC into running code.

   Obviously, since all AI systems are trained on all available data,
   all ML-generated code generated from a single RFC will be identical.
   This will have the enormous benefit that interoperability will never
   be an issue, meaning that implementations can be quickly deployed
   without needing to be tested in an operator's lab - this feature will
   save equipment vendors a lot of money and will reduce their stress
   levels considerably.  There will be an additional commercial benefit
   that there will be no need for competition between vendors since the
   only different between software releases will be the color of the
   packaging.

   It may, however, put AI agents that have been trained to test code
   out of work.  We should be careful that AI agents must not be allowed
   to unionise.

3.3.  Contributing to the IETF

3.3.1.  Note-Taking in Meetings

   Authors Note: This section was dictated to a transcription service
   [Canine] and is reproduced here without review.

   A very suck cess full application of tool in the eye eat tea F is for
   voice transcript services during the ever-popular plenary meetings.
   The notes that are maid are undoubtedly a Benjamin to everybody and
   are Easterly converted into meeting minges.  Thoughs minutes are
   widely read by **UNTRANSCRIBED**.

   Ungh natural fellow up is to use hay high to take notes in all
   meetings.  This avoids chairs wasting thyme at the start of meetings
   while they try to find a note-taker (commonly called a spiv).  See,
   another benefit of art is fickle intelligence.



Farrel                   Expires 3 October 2026                 [Page 5]

Internet-Draft               AI and the IETF                  April 2026


3.3.2.  Reviewing Internet Drafts

   Unlike published RFCs, Internet-Drafts do contain faults usually
   caused by HI.  With its greater intelligence and profound wisdom, an
   ML system will easily be able to review documents and identify errors
   which it can report in an unbiased and entirely supercilious way.

   Snark will be entirely eliminated.

3.3.3.  Writing Emails

   The work of the IETF is conducted on mailing lists.  But writing
   emails is a time-consuming task.  Furthermore, writing a polite email
   to another engineer who is clearly one raspberry cream short of a box
   of Engelbert's Delights is normally thought of as a great waste of
   time and energy.  Yet, these emails are the oil that greases the
   wheels of the great IETF machine.

   LLMs are specialists at putting together text into somewhat
   meaningful paragraphs.  Everyone should use AI to write their emails
   and so avoid accidentally calling someone a dunderhead.

3.3.4.  Developing Internet-Drafts

   If you can bake a cake, you can make a bomb [Shake].

   As noted in Section 3.3.3 an LLM is well suited for generating
   pseudo-random pieces of text.  This makes it a more-than-ideal tool
   for generating a sequence of poorly-connected and somewhat garbled
   paragraphs that, when concatenated become what is commonly referred
   to within the IETF as an Internet-Draft.

   It is well known that there are no limiting criteria for quality
   applied to Internet-Drafts, and the only risk here is that such a
   document authored purely by AI might be distinguished from one
   produced using HI by its cogency, relevance, and relative value to
   the Internet community.  Those who care about the origins of IETF
   drafts should, of course, focus on the content and not the authorship
   (as, indeed, they so surely do with work authored by humans of their
   acquaintance).

3.4.  AI Working Groups

   Having now established that AI may author and review Internet-Drafts
   as well as write and respond to emails, it makes perfect sense for AI
   to participate fully in IETF working groups.  They may sign up to
   mailing lists and participate in all other ways.




Farrel                   Expires 3 October 2026                 [Page 6]

Internet-Draft               AI and the IETF                  April 2026


   This principle may be fully developed so that the only participants
   in a fully functional working group are AI bots, applications, and
   agents.  This will speed the RFC development process (so often
   complained about) and save hard-pressed engineers from having to
   waste their precious beer time on activities such as innovation and
   thinking.

3.5.  The AIETF

   In view of the vast number of Internet-Drafts that have been posted
   to consider the impact of AI on the Internet, and considering that
   the side meeting schedule at the IETF is almost completely full of
   meetings convened to debate the glory of AI, it makes sense to crate
   a new standards organisation called the AIETF (Artificial
   Intelligence Engineering Task Force) with the tag line "Making the
   Internet Great Again".

   A partner organisation, the AIRTF will offload the AIETF by acting as
   a gravity-well for all theoretical or research-based AI discussions.

   It is envisaged that both the AIETF and the AIRTF will be populated
   by AI agents.  These agents will be responsible for most of the
   regular tasks:

   *  Authoring and revising AI-Ds

   *  Reviewing AI-Ds

   *  Discussing among themselves on LLMailing lists

   *  Holding virtual LLMeetings

   *  Conducting MLast calls

   Oversight of the AIETTF will be provided by the AIESG, but wise
   guidance and workshops will be organised by the AIAB.

   In the event that the AIETF is unable to achieve consensus on the
   publication of RFCs, they may be passed to the AISE.

   It is anticipated that the existence of the AIETF will have only
   marginal impact on the operation of the IETF.  That is, participants
   will continue to reinvent protocols, endlessly debate closed topics,
   kvetch about meeting locations, and travel to exotic places on the
   company dollar.






Farrel                   Expires 3 October 2026                 [Page 7]

Internet-Draft               AI and the IETF                  April 2026


4.  Operational Considerations

   We asked a network operator what they thought.  Chuck P Fledgeboddice
   replied:

   *  We are seeing a lot of pain in our network.  It is very big pain;
      the biggest pain.  There is no point to the pain.  So our chief
      pain point is pointing to the point at which the pain has point.

5.  Morality Considerations

   Consistent with [RFC4041], it is important to carefully consider the
   impact of AI on the depravity of the Internet.

   We have seen a disturbing recent trend where AI agents utilise
   Internet bandwidth to share cat videos with each other.  The speed of
   consumption of these videos by software tools, and the rapid
   generation of new videos by ML components, means that AI is now
   accounting for more than 57% of the data transported on the Internet
   backbone.  It should be noted that while it is cute to see a kitten
   in a tuxedo playing the piano, it is disturbing to observe that the
   cat has five legs and an ear placed in the middle of its forehead.

   Individuals of doubtful reputation see AI as a golden opportunity.
   But of more concern is the light in which AI agents may view
   themselves.  It is not that AI agents lack a moral compass, but it is
   questionable whether they know how to read the compass, whether the
   compass points north, and whether they think the compass is, in fact,
   a lotus blossom.

   The omnipresence of AI will, in all likelihood, encourage young
   people (possibly as young as 35) to participate in the standards
   process.  The AIETF should take all available measures to ensure that
   these vulnerable individuals do not waste their time attempting to
   participate in the production of AI-Ds.  Instead, all AI tooling
   needs to focus on the delivery of amusing cat videos to human
   consumers while dedicating maximum CPU cycles to working within the
   AIETF to produce the necessary standards.

   It is highly unlikely that any large, multi-national corporations
   would participate in the production or use of AI.  We are all
   completely safe in that respect.

   It is unquestionable that AI is well qualified to provide oversight
   of all activities undertaken by AI.  Nothing to see here.






Farrel                   Expires 3 October 2026                 [Page 8]

Internet-Draft               AI and the IETF                  April 2026


   While other standards-making bodies may decide to muscle in on the
   territory of the AIETF (one thinks of the AITU and AIEEE), it is
   without doubt that the AIETF is the foremost standards body for the
   AInternet.

   Don't forget that all of the avian brotherhood is worthy of our
   concern.

6.  Privacy Considerations

   Really?  Do we still care about privacy even after all this time?

7.  Acknowledgements

   This document was produced using the ABCintel (Advanced Biological
   Canine Intelligence) system from Old Dog Smartarse Corp.

   Thanks to Harald Alverstrand, Kathleen Moriarty, and Aaron Falk for
   providing of their Great Intelligence.

8.  Informative References

   [Canine]   Old Dog Smartarse Corporation of Ruritania, "Command And
              Nonsense Intelligent Normalisation Engine",
              <https://www.canine.example.com>.

   [Child]    Wikipedia, "Julia Child", Article Wikipedia.

   [RFC4041]  Farrel, A., "Requirements for Morality Sections in Routing
              Area Drafts", RFC 4041, DOI 10.17487/RFC4041, April 2005,
              <https://www.rfc-editor.org/info/rfc4041>.

   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
              January 2024, <https://www.rfc-editor.org/info/rfc9522>.

   [Shake]    Chumbawamba, "Shake Baby Shake",
              <https://www.azlyrics.com/lyrics/chumbawamba/
              shakebabyshake.html>.

Author's Address

   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk






Farrel                   Expires 3 October 2026                 [Page 9]
