[nmrg] Re: IRSG ballot issued: <draft-irtf-nmrg-ai-challenges-06.txt> to Informational RFC

["Dikshit, Saumya" <[e-mail]>]

Hi Alex,

Thank you for the response and the proposed text updates. These changes address my comments well:

  *   the additional telemetry mechanisms in Section 6.2,
  *   the bridge sentence between Section 4 and Sections 5-7,
  *   and the explicit operationally harmful output example in Section 9.3.

Just caught my eye 😊 the Section 6.2  and hate to send these  nits but this one is hampering what it intend to convey :

  *
"continues routing-state observation” ….I believe you mean  "continuous routing-state observation"

I support the proposed updates and continue to support publication. Happy to review and contribute to further revs.


Best regards,
Saumya

From: Alexander Clemm <[e-mail]>
Date: Saturday, 15 August 2026 at 4:55 AM
To: Dikshit, Saumya <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: RE: [nmrg] IRSG ballot issued: <draft-irtf-nmrg-ai-challenges-06.txt> to Informational RFC

Hello Saumya,

many thanks for your review and support for this document.  Please find my responses inline below, <ALEX>

Thanks
--- Alex

From: Dikshit, Saumya <[e-mail]>
Sent: Thursday, August 13, 2026 12:10 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [nmrg] IRSG ballot issued: <draft-irtf-nmrg-ai-challenges-06.txt> to Informational RFC

[Updating the To, CC to authors of draft and nmrg ]

Hi all,
Not sure, if responding here is the right context for the review with “IRSG ballot issued”. If not kindly point me the right way.

I am from AIOPs group with Aruba networks, HPE. And warming up to nmrg ai leads with this read.

Since I work with lots of telemetry from networking devices (switches, WLAN, gateways), my observations are driven accordingly.

A few observations:

1) Section 6.2 covers data collection well but stops at IPFIX and SDN-based monitoring.
    Two frameworks that are now standardized and directly relevant to the ML input challenges in Section 6.1 needs more than a mention:

  *   YANG-Push (RFC 8641) for subscription-based datastore streaming,
  *    and BMP (RFC 7854) for continuous routing-state observation.
   Both produce the structured, schema-validated streams Section 6.1 is asking for. A sentence each would close the gap.

<ALEX> Thank you for your comment.  I agree that these are worthwhile mentioning (especially as a coauthor of RFC 8641;-) although this is not intended as an exhaustive list.  It might be useful to mention IOAM as well.  I suggest that we add the following text:

In section 6.2, right after “As a result, many different technologies can be used to retrieve meaningful data. ”:
Important mechanisms are already in place that provide a meaningful base for tihs.  For example, YANG-Push [RFC8641][RFC8639] allows AI-based management solutions to subscribe to updates from YANG datastores and to corresponding management data streams.  BGP Monitoring Protocol (BMP [RFC7854]) can be leveraged to provide continues routing-state observation.  In-situ OAM (iOAM [RFC9378, RFC9197])  provides the same applications with network telemetry observed as packets traverse the network.

Then start the next sentence “To support improved QoE…” in a new paragraph.
</ALEX>


2) Section 4 and Sections 5-7 use "challenge" for two different things: high-level adoption obstacles in Section 4,  and specific research sub-challenges with numbered headings in 5-7.
   Expert readers will track it, but a one-sentence bridge at the end of Section 4 might be of some help
   "The following sections decompose these obstacles into research-level sub-challenges" and would help readers new to the NMRG framing.
  As a reader/implementer I got stuck with this.

<ALEX> I am not sure I would phrase it exactly like this – an obstacle is not really a research challenge per se, although how to covercome the obstacle may well be.  However, the need for a sentence to provide a bridge is well taken and I am fine with keeping it as per you having trouble to provide a better alternative, so I am fine with adopting your suggestion.
</ALEX>

3) Section 9.3 covers out-of-bounds AI outputs (bandwidth exceeding link capacity) but not the adjacent failure mode:

  *   logically valid outputs that are operationally dangerous in context, like a correct route computation that induces a forwarding loop.
   This is distinct from adversarial ML (Section 9.2) and deserves explicit mention with a pointer to the verification/sandbox work already present in Section 5.5.

<ALEX> Thank you for this.  How about adding the following sentence in section 9.3 right after “For example, if an AI algorithm decides to change the filtering tables in a network it may compromise access control policies. ”:
Similarly, without safeguards, an AI algorithm might produce outputs that are operationally harmful, such as the introduction of forwarding loops by applications supposed to optimize network forwarding rules.
</ALEX>

I support publication.

Best regards,
Saumya

<ALEX> Thanks again! </ALEX>

From: IESG Secretary <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 13 August 2026 at 1:18 PM
To: The IRSG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [nmrg] IRSG ballot issued: <draft-irtf-nmrg-ai-challenges-06.txt> to Informational RFC
Evaluation for <draft-irtf-nmrg-ai-challenges-06.txt> can be found at
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-irtf-nmrg-ai-challenges/__;!!NpxR!mb3Lq7TV_7_wrRLrHAd5eiXR_lb53t4A3IhxZCYjJjICMMcnOUs8o2W5oeyWyPfCnY5IrWj3GKmMN1KLkJiIhl6DzQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-irtf-nmrg-ai-challenges/__;!!NpxR!mb3Lq7TV_7_wrRLrHAd5eiXR_lb53t4A3IhxZCYjJjICMMcnOUs8o2W5oeyWyPfCnY5IrWj3GKmMN1KLkJiIhl6DzQ$>

Ballot expires on: 2026-08-27 00:00 PDT

Needs a YES.



_______________________________________________
nmrg mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>