The Emerging Application of AI in IETF Specifications

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. 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.

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.

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

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 never said: "What could possibly go wrong?"

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 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.

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.

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.

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.

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.

An obvious extension to 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.

Authors Note: This section was dictated to a transcription service 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.

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.

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.

If you can bake a cake, you can make a bomb . As noted in 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).

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. 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.

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.

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.

Consistent with , 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. 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.

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

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.