Operations & Management Area Open Meeting (opsarea) Minutes - IETF 125

• ADs: Mohamed Boucadair & Mahesh Jethanandani
• Minutes: Thomas Graf
• When: 2026-03-16 07:00-09:00 CET

Introduction (ADs)

The slides can be found here.

State of OPS Nation

The full slides (covering all OPS WGs/Directorates) can be found
here.

Mohamed Boucadair commented about the WGs rechartering status and
leadership update since 03/2025. More than half of OPS WGs were
rechartered and their leadership updated.

GROW

Paolo Lucente went throgh GROW slides.

Mahesh Jethanandani: What is the coverage of the BMP YANG module?
What are the transport protocols? IPFIX? YANG-Push?

Paolo Lucente: It covers the BMP configuration and also operational
statistics to BMP itself.

SRV6OPS

Dhruv Dhodi went throgh SIDROPS slides.

Mohamed Boucadair: There was fear that there are overlaps with other
SRv6/IPv6 related working groups, especially with SPRING, when the
working group started. Can you comment looking back back at the last 2
years on how the coordination with other SR/SRv6/IPv6 related working
groups worked.

Dhruv Dhodi: In general it worked very well, but I suggest to ask
directly Alvaro, from a SPRING perspective.

Alvaro Retana: The coordination effort is like with all the other
working groups. It works very well. No specific issues encountered.

Zoom on YANGDOCTORS: Operation, Issues, and More (Per/Qiufang)

The slides can be found here.

Thomas Graf: The I-D YANG template
(https://github.com/IETF-OPS-AD/I-D-with-yang-template) is very useful.
Regarding the YANG validation in the datatracker. Mahesh as an AD made a
very good decision to delay the YANG semantic versioning
(https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver)
RFC process until IETF datatracker YANG validation tooling is supporting
such a YANG extension. However, this was not the case in the past such
as YANG structure (https://datatracker.ietf.org/doc/html/rfc8791).
Libyang supports in the latest devel
(https://github.com/CESNET/libyang/compare/master...devel) release YANG
structure. It would be very helpful that libyang on IETF datatracker
could be upgraded so that all documents using YANG modules with YANG
structure are properly validated.

Joe Clarke: Per Anderson needs to merge the latest libyang and pyang in
Debian stble in order to use it for the IETF datatracker. We require
this update not only for YANG structure but also for YANG semantic
versioning.

Mahesh Jethanandani: Reaching out to the community for having more
"Young" colleagues joining YANG doctors. What is the current load
typically for a YANG doctor?

Qiufang Ma: The preference is configurable. For instance by monthly.

Joe Clarke: I for myself have a few documents per month. The load is
rather lightly.

RFC 5706 Refresh (Benoît Claise)

The slides can be found here.

Benoît Claise explained the rationale of this work and how this effort
is intented to help WGs, authiors, not delaying or being a hurdle for
the document progress. Benoît also provided an overview of all
directorate reviews received so far and that overall the reviews are
positive, except one comment about the mandatory nature of the OPS
section. No objection was raised after Benoît presented the
recommendation and its rationale.

Chonfeng Xie: I believe that informational IETF documents don't need a
operational considerations section. Would you agree?

Benoît Claise: Correct! This is why we have a exception clause.
Operational considerations section shall only applies where it is
needed. However I believe it is good to add such a section even though
the section writes that there are no operational considerations. That
ensures that the authors have reviewed operational considerations.

Bo Wu: The document provides help for OPS DIR regarding areas, e.g. art
and security, other than routing, and ops with sufficient operational
guidance. It is helpful for OPS DIR reviewer if there is persistent wiki
link.

Benoît Claise: The OPS directorate have their own wiki. Security-related
operations has triggered a specific draft to cover those aspects (given
that the content was too big to be included in this bis).

Operators Slot: Focus on AINETOPS

Mohamed Boucadair: the following three slots are invited talks from
operators to share their thoughts, perspectives, and challenges in the
AINETOPS space.

OPS Challenges and Practices in the AI Era (Qiong Sun & Yu Fu（China Telecom))

The slides can be found here.

Benoît Claise: China Telecom is one of the largest network operators.
You are in terms of AI one of the front runners. Could you please give
IETF advice on what to focus on.

Qiong Sun: We need support on how to make agents operational and
manageable.

Benoît Claise: Can you expand a bit a more about manageability, what the
needs are.

Qiong Sun: Tracebility and setting AI boundaries are two important
aspects we should focus on.

Challenges of AIOPS for Carrier IP Networks (Xiaoqiu Zhang (China Mobile))

The slides can be found here.

Mohamed Boucadair: Thanks for providing concrte examples of what the
IETF can do in this field. I have one clarification about the first
poingt i the last slide: what is specific to AI? What not reusing
existing tools would be sufficient?

Thomas Graf: I really resonate with your presentation. Especially on the
importance of having data done right by preserveing data taxonomy and
the semantics. To answer question 2 and 3. I believe that with existing
Network Telemetry protocols (RFC 9232) and YANG as a data modelling
language (RFC 7950) we have already good data collection and modelling
protocols which work at large scale deployments and allowing semantic
rich data. At NMOP we are working on data integration into Data Mesh to
improve and automate data processing and acessability in terms of
usaebility and scale.

Dan Voyer: These two presentations are great. I like that you are
defining the problems which are obvious in my opinion as a network
engineer. I suggest to clearly call out what is needed in terms of
network management at IETF.

Intelligent Operation & Maintenance: Practices and Reflections (Jing Zhao (China Unicom))

The slides can be found here.

Mohamed Boucadair (chat): For full transparency, the guidance I have
provided to the presenters is to to hilghight the specifics of their
deployments and how the challenges/pb to be solved are connected to
their deployment.

Benoit Claîse (chat): Thank you Med for inviting those 3 operators (and
providing the presentation guidelines). When I sum up the number of
their subscribers (which shows the network scale), the IETF would be
really stupid not to listen carefully which problems to tackle next!

Joe Abley (chat): wave

Thomas Graf (chat): Fully agree Benoît. I am taken aback listening to
those 3 presentations and clearly speak out their network operator
challenges and show what is possible with AI.

Joe Clarke (chat): @Benoît, I agree. But when I break some of this down,
I don't necessarily see "AI" as novel piece. In some ways data
management is not new, and we've been struggling to get vendors to
align. In fact, AI is interesting (in my experience) as it helps
normalize some of this unstructured or unaligned data. What spoke best
to me (in my experience) is the non-determinism of AI. I'm not sure
that's something the IETF should tackle. But, if I had to pull out a
couple of common themes they would be digital twin, and perhaps data
reduction and distribution of data processing.

Qin Wu (chat): Good presentations, I see Top 3 common use cases
discussing here include fault management, network optimization, network
change. Good to see investigate how AI can help address challenges
raised here.

Cuiling Zhang (chat): Splitting protocol development from operational
maintenance would help +1

Benoît Claise (chat): @Joe, I agree. This is why I also mentioned
different areas, not all related to AI: digital twin, knowledge graph,
opentelemetry, etc.

Qin Wu (chat): @Joe, If we can make data better structured with context,
semantics, constraints, , these data can be better consumed by AI and
Model.

DNS Consultation Task (Wes Hardaker/Joe Abley)

The slides can be found here.

Mohamed Boucadair (chat): The draft Wes is talking about is
https://datatracker.ietf.org/doc/html/draft-hardaker-dns-wgs-at-ietf-02

Ondrej Sury: I believe it is a commonality that different kind of groups
needs different kinds of people with a different kind of focus.

Wes Hardaker: I might not have expressed it correctly, but I think we
agree here.

Ondrej Sury: The second observation is that for people new to the IETF,
when DNS dispatch says yes and DNSOP says no, thats very confusing to
them. I don't have a solutioon for this but from what I have observed
this might be common.

Wes Hardaker: I believe we already have that today with dispatch. The
draft talks about it. Maybe we need some sort of shepherding.

Ondrej Sury: And my last point. The DNS dispatch colleagues will be
burned out quickly.

Wes Hardaker: Does the DNSOP chairs already have that burden already
right?

Ondrej Sury: Splitting up DNSOP in smaller groups won't resolve the
problems.

Wes Hardaker: Fair enough. I leave that to Med.

Benno Overeinder: Before this was called liaison and now its DNS
dispatch. I wonder how the decisions are made in terms of balancing the
load.

Wes Hardaker: Quoting other people. DNSOP chairs doing the dispatching
caused for other people a lot of headaches and work. However are we sure
that everybody is heard and this is the best solution? Probably not. I
think what you are saying is that both chairs from DNSOP and DNS
protocol could share the dispatch role. That is an interesting idea.

David Plonka: Regarding the protective DNS presentation earlier. I think
its kind of a wild west thing where many people want to make money. Can
we take that as an example to show how DNS dispatch would work?

Wes Hardaker: Good question. We actually went already through such an
excercise. There is a section in the document describing the dispatch
function. Most of it came from Joe Abley. There are good examples. We
suggested the IESG that we could do a test DNS dispatch session just to
see how it would work out.

Florian Obser: I like the idea of DNS dispatch and also Benno's idea of
having the chairs of each DNS group doing the DNS dispatch. In case
there are to many chairs, why not do something similar like the
directorates already do, rotate them.

Wes Hardaker: There was a thought of having DNS directorate getting
involved in the DNS dispatch as well. But from my experience,
directorates can get quickly overloaded.

Mohamed Boucadair: I'd like to thank the community for the constructive
discussion, Joe and Lars-Johan for helping to digest and structure the
feedback and recommendations, and special thank you to Wes for leading
the effort. I also appreciate that the planning as initially sketched
was met. My plan is to formally conclude the consultation right after
Wes publishes a revised version that takes into account the feedback
received during the IETF#125 week. Will be then discussing with the IESG
about changes and implementing them.