Summary

  • The IESG's 24 September agenda carries an RFC 5742 conflict review of draft-irtf-nmrg-ai-challenges-06, an IRTF Network Management Research Group paper intended as Informational, not an Internet Standard.
  • The -00 conflict-review proposal paired “no conflict” with an advisory note on adversarial AI versus unsafe AI output. The 24 September -01 revision retains the proposed no-conflict conclusion but removes the note. The Datatracker still records IESG Evaluation and a DISCUSS; there is no adopted response yet.
  • Sections 9.2 and 9.3 of the draft address different failure paths. Defending the model and constraining the network actions it proposes are separate operational questions.

Imagine two recommendations arriving at the same change-control gate. One was derived from poisoned training data; its apparent confidence conceals an attack on the model. The other came from an uncompromised system but asks for more bandwidth than a link can provide. Both may be unsafe to execute, yet the evidence needed to catch them is different. The first asks what entered and influenced the AI. The second asks whether the proposed effect remains within the network's physical and policy limits.

That distinction briefly appeared in the proposed IESG response itself. The -00 version said the NMRG paper did not conflict with IETF work and asked the authors to consider an IRSG comment about sections 9.2 and 9.3. Ballot history records Mohamed Boucadair agreeing with no conflict but objecting to a request that IRSG comments be addressed through this response; Tommy Jensen supported that concern. The new -01 text removes the advisory note and leaves only the proposed no-conflict conclusion. The chronology is visible, but the record does not establish a final IESG decision or prove why every edit was made. Datatracker still says IESG Evaluation and shows a DISCUSS. The two-risk distinction remains in the research draft, not in the current proposed IESG wording.

Section 9.2 is about assaults on an AI system: manipulated training inputs, evasion of a traffic classifier and extraction of information about training data. Section 9.3 moves from the model to its consequences. Its examples include an automated change to filtering tables that undermines access policy and a quality-of-service allocation larger than available link capacity. Testing only for corrupted input would miss the latter class. Conversely, a configuration-limit check would not explain how a classifier was subverted before it made its recommendation.

RFC 5742 gives the IESG a deliberately narrower job than certifying either safeguard. For an IRTF-stream submission, the IESG checks whether the proposed publication conflicts with IETF work; the IRTF draft explicitly identifies its research-group status and intended Informational category. A no-conflict response, if eventually adopted, would not turn research into an IETF standard, approve an AI controller or demonstrate that its mitigation works in production. There is no public evidence here of a deployment or an outage.

An operator considering ideas from the paper could keep two records. One would specify the model and data threat assumptions, tests for poisoning or evasion, and who can alter those inputs. The other would specify what configurations the system may change, which bounds are checked independently, how changes are staged, when a person or automatic control stops them, and what a rollback actually restored. That two-part receipt is Daniel Kade's editorial proposal, not a new IETF requirement.

It follows the draft's concern with incremental action and rollback while refusing to let a clean model-health report stand in for safe network effects.

Sources