Minutes IETF126: opsawg: Mon 12:00
minutes-126-opsawg-202607201200-00

Operations and Management Area Working Group (OPSAWG) - IETF 126

When: Monday, July 20th 2026 14:00 to 16:00
Co-Chairs: Joe Clarke & Benoît Claise
Secretary: Chongfeng Xie

Compact Agenda
Session: OPSAWG
Slot Topic Presenters
14:00 - 14:10 Introduction & Document Status & Agenda Bashing Chairs (On
site)
14:10 - 14:15 Export of Gigabit Passive Optical Network Encapsulation
Mode in IP Flow Information Export (IPFIX) Thomas Graf (On site)
14:15 - 14:25 A YANG Data Model for Network Diagnosis using Scheduled
Sequences of OAM Tests Wu Qin (On site)
14:25 - 14:30 IP Flow Information Export (IPFIX) Alternate-Marking
Information Elements Giuseppe Fioccola (On site)
14:30 - 14:40 Applying COSE Signatures for YANG Data Provenance Ana
Mendez & Diego Lopez (On site)
14:40 - 14:55 YANG deVELpment PrOCEss & maintenance (VELOCE) Mahesh
Jethanandani (On site)
14:55 - 15:05 Security Operations Fundamentals and Guidance Michael P
(On site)
15:05 - 15:10 QUIC Transport for Network Telemetry Benoit Claise (On
site)
15:10 - 15:15 Export of BIER Information in IP Flow Information Export
(IPFIX) Yisong Liu (On site)
15:15 - 15:20 Export of BGP Prefix Origin Validation in IP Flow
Information Export (IPFIX) Yisong Liu (On site)
15:20 - 15:25 Ordered Information Element Export in IP Flow Information
Export (IPFIX) Benoit Claise (On site)
15:25 - 15:30 Export of L4S ECN in IP Flow Information Export (IPFIX)
Xueyan Song (On site)
15:30 - 15:35 Export of Segment Routing Policy Attributes in IP Flow
Information Export (IPFIX) Changwang Lin (On site)
15:35 - 15:40 Export of QUIC Information in IP Flow Information Export
(IPFIX) Changwang Lin (On site)
15:40 - 15:45 Export of Source Address Validation (SAV) Information in
IPFIX Qian Cao (On site)
15:45 - 15:50 Export of BGP VPN Information in IPFIX Yao Liu (On site)
15:50 - 15:55 Problem Statement for Network Resilience Jing Zhao (On
site)
buffer of 5 min
Detailed Agenda

1. Introduction & Document Status & Agenda Bashing (10 min)

   Presenter: Joe Clarke & Benoît Claise

   Joe Clarke： RFC9950、RFC9951、RFC9977、RFC10014 have been published.
   PCPng needs a Shepherd (Chongfeng Xie has responded to take on this
   role)
   Benoit Claise: These are a group of Alt Mark documents, all of them
   are inter-connected. Giuseppe, you should show them together even
   when you present only one of them, which proves they must progress
   together.
   Lots of IPFIX-related documents have been received, but it does not
   mean that all IPFIX documents need to be in this WG. If you believe
   you will have more feedback from a specific technology WG, it's fine
   to have the IPFIX document in THAT WG, exactly like YANG models.
   Joe Clarke: We don't get enough document reviews, and we don't get
   lots of discussion on the mailing list. For authors, it is your
   responsibility to promote the discussion. Please join the AIOPS side
   meeting on Firday.

2. Export of Gigabit Passive Optical Network Encapsulation Mode in IP
   Flow Information Export (IPFIX) (5 min)

   Presenter: Thomas Graf
   Reading Material: draft-ietf-opsawg-ipfix-gpon-gem

   Joe Clarke: This document can go to the last call.

   From the chat:
   Mahesh Jethanandani: I did have a question on the GPON draft. Did
   we resolve all 17 issues that Paul brought up as part of Expert
   Review.
   Benoît Claise@Mahesh, not yet. So WGLC would be done after.
   Mahesh Jethanandani： Makes sense. Thanks.
   Qin Wu：@Thomas, it will be useful to clarify why we can not use
   IPFIX exported data fields for debugging purpose? or we will not use
   any IPFIX fields for debugging.
   AI: Chairs to do a WGLC, after the next revision (addressing Paul's
   issues)

3. A YANG Data Model for Network Diagnosis using Scheduled Sequences of
   OAM Tests (10 min)

   Presenter: Wu Qin
   Reading Material: draft-ietf-opsawg-scheduling-oam-tests

   A design issue was raised concerning whether a 32-bit Router ID is
   sufficient as a unique identifier (EID) for non-router elements
   (e.g., Layer 2 switches, firewalls). Qin Wu presented three options
   for importing identifier definitions (e.g., from network topology or
   inventory models).

   Jeff Haas: Context really matters. While a Router ID works well for
   routing protocols, it is not sufficient or guaranteed to be unique
   for non-IP elements. I advise against making it the sole unique key.

   Joe Clarke: if a Router ID is used, the draft must provide clear
   guidance on what values non-router devices (like L2 switches) should
   populate (e.g., management IP). Pick their preferred approach and
   send to the mailing list.

   From the chat:
   Reshad Rahman: Would it help if router-id is used now but embedded
   in a choice statement。Disclaimer: haven’t checked the document
   recently.
   AI: Chairs to ask for a shepherd, do DIR reviews, and do a WG LC

4. IP Flow Information Export (IPFIX) Alternate-Marking Information
   Elements (5 min)

   Presenter: Giuseppe Fioccola
   Reading Material: draft-ietf-opsawg-ipfix-alt-mark

   Mahesh Jethanandani: Have the comments from the Expert Review by
   Paul Aitken been addressed.
   Giuseppe Fioccola: Yes, I think so.
   Paul Aitken: Made the same comment as Mahesh. It didn't look like
   my feeback had been incorporated. [Paul confirmed online that he
   has not seen any response either]
   Giuseppe Fioccola: The updates are in my local copy and I have not
   posted the updated version yet. I replied on the mailing list and
   will submit the new version soon.
   Joe Clarke: Follow-up on the list.

5. Applying COSE Signatures for YANG Data Provenance (10 min)

   Presenter: Ana Mendez & Diego Lopez
   Reading Material: draft-ietf-opsawg-yang-provenance

   Rob Wilton: Thanks for work. I have some comments, will send to the
   list:

   1. You end up with different signatures if you use different
      encodings, so a collector that normalizes the data would end up
      with invalid signatures.
   2. You might need different encodings ids for CBOR with/without
      SIDs because you will end up with different signatures.
   3. Wasn't clear whether the normalization is only for the signature
      or whether the data was also expects to be normalized as well.

   Per Andersson: Need to consider only sending sparse data

   Mahesh Jethanandani: Support Rob and Per's comment on normalization
   of data. Question about YANG Lint errors - is that a tooling issue
   or a modelling issue?
   Ana Mendez: Will check and get back to you.
   Joe Clarke: Referring to slide 5: Elephant in the Room: You
   mentioned last call, but unsure how stable, i.e., are you still
   working on implementation.
   Ana Mendez: Intend to move this to another draft, think it is out
   of scope for this one, so this one can progress.
   Diego Lopez: YANG normalization is a problem that has appeared
   regarding the datastores rather then the exchange of data. We think
   that we can address this elsewhere.
   Joe Clarke: So you don’t plan any substantive changes.
   Diego Lopez: No, we don’t.

   From the chat：
   @Rob and @Per please post those comments on Provenance to the list.
   And thanks for the review!

   Mahesh:On the YANG provenance draft, I notice the datatracker
   mentions 4 errors at
   https://datatracker.ietf.org/doc/draft-ietf-opsawg-yang-provenance/#.
   I normally do not pay heed to the errors, but in this case, it is
   worth checking whether the errors being reported are true errors or
   just false positives.
   AI: Chairs to close on the YANG normalization question

6. YANG deVELpment PrOCEss & maintenance (VELOCE) (15 min)

   Presenter: Mahesh Jethanandani
   Reading Material: draft-mahesh-opsawg-veloce-yang

   Comments on Q1.
   Qin Wu: I prefer Github.
   Italo Busi: Timing matters, start with Option A. Archival also
   Diego Lopez: Would prefer to see the data within the IETF
   environment, so option B. Depends on what the goal is.
   Mahesh Jethanandani: Github implies not control of the data, but we
   do have control over the data.
   Rob Wilton: Need to understand scope of Veloce, is it just
   experimental, in case do whatever you want. Longer term need to
   understand the archival of the data and hence may need more control.
   IANA should be used when published when known reviewed versions of
   the modules that have achieved some level of consensus.
   Mahesh Jethanandani: I agree about IANA about publish docs.
   Dhruv Dhody: Not sure whether IANA is in scope for this question.
   Make sure you have a repo with given properties, allow different WGs
   to decide.
   Mahesh Jethanandani:
   Jeff Haas: 3 choices: 1 choosing Github. We need a path to recover
   our data for future. (2) Gitlab is good for storing files, but
   really bad for files, Github is better. (3) Need to a long term way
   of storing/find our data.
   Warren: Github will eventually go away. Must have a plan to be able
   to migrate the data over time.
   Balazs Varga: Users prefer git (so A or B). 3GPP decided to Gitlab.

   Italo Busi: Need to be able to do a diff. I.e., we need to be able
   to force them to just review the changes. At the moment the problem
   is that everything ends up being open for review rather than only
   the parts of what has changed.
   ... Ran out of time, will take the rest of the list.

   From the chat:
   And @Mahesh too for the (tooling?) error you were referring to.
   Dan Voyer
   20:47
   option A, when easy and known, people just follow
   James Cumming
   20:47
   This feels like you need a poll on this
   Thomas Graf
   20:48
   @Mahesh, regarding draft-ietf-opsawg-ipfix-gpon-gema. The comments
   from Paul will be addressed in the next document revision.
   Joe Clarke
   20:48
   @James, thought about that, but it's hard to do a four-way poll
   with the show of hands tool.
   James Cumming
   20:48
   IETF retaining ownership to the data is important - So I would vote
   for B
   James Cumming
   20:50
   Joe Clarke said:
   @James, thought about that, but it's hard to do a four-way poll
   with the show of hands tool.
   That's a shame - Sounds like a feature request
   Benoît Claise
   20:51
   "That's a shame - Sounds like a feature request" Meetecho is
   monitoring this channel :-)
   Joe Clarke
   20:51
   Would be nice to be able to create a custom poll with flexible
   number of options...
   Dhruv Dhody
   20:55
   Does the IETF tools team does some backup for WG GitHub’s?
   Joe Clarke
   20:55
   Good question. I don't know. I can check with Robert.

   Joe Clarke: As a contributor, VELOCE is an experiment. I'm of the
   thinking we use GitHub for now, prove the experiment, and then look
   to see if we need to choose something else for the future.
   Ultimately, it could be work is done in GH and artifacts live
   elsewhere in the long-run.

   Ebben Aries: VELOCE: +1 on James and others' comment on data
   ownership being a main objective but also we want to consider git
   scm today, something else tomorrow, front-ends and review tooling
   can change so being as agnostic as possible concentrating on modern
   revision control, history, data retention. GitHub imo is perfectly
   fine for quick-and-dirty immediate but +1 for
   self-hosted/full-control.

7. Security Operations Fundamentals and Guidance (10 min)

   Presenter: Michael P
   Reading Material: draft-parsons-opsawg-security-operations

   Joe: Chongfeng and I reached out to our colleagues to get feedback,
   and we wanted to hear opinion or this, so we were going to do a
   poll:

   Poll:
   Are you interested in seeing this work progress in OPSAWG?
   total participants: 88
   yes: 20
   no: 1
   no opinion: 23

   Joe Clarke: There seems to be some interest, but also quite a lot
   who have no opinion, perhaps because they have not read it.
   Benoit Claise: Maybe not enough folks here have the necessary
   expertise.
   Jeff Haas: Security folks live in their own special world. If you
   go to SAAG, but you get the reverse expertise, understand SEC but
   not OPS. Might try to do it across to WGs. Could do a Design Team
   across both working list and last-call in both places.
   Chongfeng Xie: Not sure if we have enough security background, so
   not sure our reviews can be appropriate or helpful.
   Joe Clarke: Reach out to some of the SAAG folks.
   Michael P: Thanks, we will do that.
   AI: chairs to do a CfA, after the TODO is addressed in the next
   version

8. QUIC Transport for Network Telemetry (5 min)

   Presenter: Benoit Claise
   Reading Material: draft-netana-opsawg-telemetry-over-quic

   James Cumming: Why this draft restricts the scope to dial-out
   (router-initiated) connections?
   Benoit Claise: Because there are a lot of something-over-QUIC
   drafts already and in there we wanted to just focus on the telemetry
   part. It's just a question of scope. Dial-in is technically
   possible..
   James: Dial-in telemetry is common as well.
   Benoit Claise: I Don't disagree. We didn't want to be the
   management-foo-over-quic document, covering NETCONF, BMP, IPFIX,
   etc. because there are already a lot of documents.
   Jeff Haas: It's a fair warning we've been given is the token
   management for the individual streams, you have to be very careful
   exactly how you're pushing stuff based on what the receivers are
   capable of doing. Many your use cases here are no potentially high
   speed like IPFIX. So if you start putting everything over the same
   connection, I think you're gonna run into some interesting flow
   control issues. This is something that the QUIC WG will have
   opinions about. Please reach out to QUIC WG.
   Per Andersson: UDPNotif, is it underspecified in this draft for
   YANG-Push, because you need to be able to put where the receiver is
   in terms of streams? In here or other work?
   Benoit Claise: we will need to have that, not sure yet where it's
   going to be
   Rob Wilton: Good work. Keep going. I Will send comments to the
   list.
   Qin Wu: Defining a new telemetry header extension might require
   reviews from the Web and Transport (WIT) area.
   Benoit: Of course, there is a session from Per in the OPS area. And
   it's also discussing in the WIT area, not especially this draft, but
   management of QUIC.

   From the chat:
   Chongfeng: One of the motivations of approach is to make the data
   communication more secure by using QUIC, however, in the network of
   big operators, the telemetry data is transfered by a specific VPN
   network, not on public Internet, in this case, data transfer with
   plan-text is not big secure risk, so I doubt the real value of
   moving Telemetry to QUIC transport with great upgrade cost.
   Ebben Aries
   @chongfeng - agree alot of env. handle the security considerations
   by various other means today but there are growing needs and
   mandates for transport level encryption and common/consolidated
   transports - in today's non-IETF defined protocols, TLS is heavily
   in used even in those "internal-only" networks
   Ebben Aries re: "great upgrade cost" is real - I'd envision this as
   an evolution adopted over a long time, nowhere near immediate.
   Reshad Rahman: Adding to what @Ebben said, people who don't
   want/need to migrate to XoverQUIC, don't have to.
   Holger Keller: @ebben if you already have the protocol activated,
   yes on migration. we have strong security requirements for
   transport, the collector and the message-broker (well, only auth
   there, no encryption). If there is no auth or security, we have to
   provide mechanisms inside the collector to come around that, which
   means a lot of effort - QUIC solves that immediately.

   Reshad Rahman: OOC was the document presented in QUIC?
   Joe Clarke
   21:49
   @Reshad while I don't know offhand, we would cross-post the CfA to
   QUIC for feedback.
   Joe Clarke
   21:49
   @Reshad while I don't know offhand, we would cross-post the CfA to
   QUIC for feedback.

9. Export of BIER Information in IP Flow Information Export (IPFIX) (5
   min)

   Presenter: Yisong Liu
   Reading Material: draft-ll-opsawg-ipfix-bier

   Benoit Claise: Did you get feedback from BIER?
   Yisong Liu: Yes, we have presented it at BIER WG.
   Benoit Claise: If the feedback in the BIER WG was highly positive,
   it might be better (to get more feedback) to take this to the BIER
   WG. Otherwise, concern is that we will get lots of technology
   specific IPFIX in this WG.
   AI: Chairs to coordinate this with the BIER chairs.

10. Export of BGP Prefix Origin Validation in IP Flow Information Export
    (IPFIX) (5 min)

    Presenter: Yisong Liu
    Reading Material: draft-liu-opsawg-ipfix-bgp-pov

    Benoit Claise: Any opinions?
    Paul Aitken: Would prefer if the IPFIX all remained in this WG so
    that there is one place to track them.
    Benoit Claise: You speak from a pure interest POV, or as an IPFIX
    expert?
    Paul Aitken: Easier to track in one place.
    Benoit Claise: In this case, I suggest to take this to GROW. So
    we'll discuss with the AD on what to do on all these. What's the
    purpose of this draft?
    Yisong: Yes.
    Benoit Claise: So your point on this is that maybe a draft is not
    needed. Is this your point?
    Paul Aitken: No.
    Rob Wilton: Too much IPFIX in OPSAWG, move it out, or to separate
    IPFIX maintenance WG, or split meeting planning to two sessions.
    Jeff Haas: Not sure that IDR has the right expertise because this is
    about forwarding rather than routing.
    Mahesh: To address the issue whether Paul is being flagged on every
    IPFIX draft for an IPFIX expert review, the answer should be yes.
    IANA flags IPFIX IE review as an Expert Review which sends. it to
    Paul.
    Benoit Claise: We will discuss with ADs and take it off line.
    Reshad: Makes sense that this is done in the expert WGs and then we
    just involved in the review.
    AI: Chairs to discuss CfA (in OPSAWG or GROW)

11. Ordered Information Element Export in IP Flow Information Export
    (IPFIX) (5 min)

    Presenter: Benoit Claise
    Reading Material: draft-claise-opsawg-ipfix-ordered-ie

    Benoit Claise: Any feedback?
    None heard.

12. Export of L4S ECN in IP Flow Information Export (IPFIX) (5 min)

    Presenter: Xueyan Song
    Reading Material: draft-song-opsawg-ipfix-ecn

    Benoit Claise: Any feedback?
    None heard.

13. Export of Segment Routing Policy Attributes in IP Flow Information
    Export (IPFIX) (5 min)

    Presenter: Changwang Lin
    Reading Material: draft-lin-opsawg-ipfix-sr-policy

    Changwang Lin: Any questions?
    None heard.

14. Export of QUIC Information in IP Flow Information Export (IPFIX) (5
    min)

    Presenter: Changwang Lin
    Reading Material: draft-lin-opsawg-ipfix-quic-header

    Benoit Claise: You are defining 7 elements. Do you use these in all
    the use cases?
    Changwang: Yes.
    Benoit Claise: What to check if there is interest to adopt this?
    Poll:
    yes: 13, no: 0, no_opinion: 9 (total: 91)
    Joe: The WG will initiate a formal WG adoption call on the mailing
    list.
    AI: Chairs to do a CfA

    Mahesh Jethanandani: @Joe, I was one of the person with a "No
    Opinion" opinion. It was not particular to the draft at hand, but
    generally applied to 4 IPFIX drafts. The question was more like: Is
    the IANA IPFIX IE expert-review registry — which doesn't require a
    full RFC for many new elements — being underused in favor of writing
    individual RFCs for things that don't need one? I know we agreed to
    take the issue offline, but wanted it to go on record to say we are
    seeing a explosion of drafts in this space. Can anyone guess what
    the cost/page is for every RFC that we have to produce?

15. Export of Source Address Validation (SAV) Information in IPFIX (5
    min)

    Presenter: Qian Cao
    Reading Material: draft-cao-opsawg-ipfix-sav

    Joe Clarke: Out of time for questions. Jeff Haas, please take the
    question to the list.

16. Export of BGP VPN Information in IPFIX (5 min)

    Presenter: Yao Liu
    Reading Material: draft-liu-opsawg-ipfix-bgp-vpn

    Joe Clarke: I will discuss where that adoption should occur. So we
    will handle the asks for adoption calls.
    AI: Chairs and ADs to discuss CfA

17. Problem Statement for Network Resilience (5 min)

    Presenter: Jing Zhao
    Reading Material: draft-zhao-opsawg-network-resilience-ps

    Joe Clarke: Out of time, will send comments to the list.

    Mahesh's comments, not specific to any presentation,
    Mahesh: @Joe, I was one of the person with a "No Opinion" opinion.
    It was not particular to the draft at hand, but generally applied to
    4 IPFIX drafts. The question was more like: Is the IANA IPFIX IE
    expert-review registry — which doesn't require a full RFC for many
    new elements — being underused in favor of writing individual RFCs
    for things that don't need one? I know we agreed to take the issue
    offline, but wanted it to go on record to say we are seeing a
    explision of drafts in this space. Can anyone guess what the
    cost/page is for every RFC that we have to produce?: