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", . [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, . [RFC9522] Farrel, A., Ed., "Overview and Principles of Internet Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522, January 2024, . [Shake] Chumbawamba, "Shake Baby Shake", . Author's Address Adrian Farrel Old Dog Consulting Email: adrian@olddog.co.uk Farrel Expires 3 October 2026 [Page 9]