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

When: Wed, March 18th 2026 14:00 to 16:00
Co-Chairs: Joe Clarke & Benoît Claise
Secretary: Chongfeng Xie

Compact Agenda

Slot	Topic	Presenters
14:00 - 14:10	Introduction & Document Status & Agenda Bashing	Chairs (On site)
14:10 - 14:20	Applying COSE Signatures for YANG Data Provenance	Ana Mendez (On site)
14:20 - 14:40	Guidelines for Considering Operations and Management in IETF Specifications	Benoit Claise (On site）
14:40 - 14:50	Export of Source Address Validation (SAV) Information in IPFIX	Qian Cao (On site)
14:50 - 14:55	Requirements and Information Elements for Application Layer Information Export in IP Flow Information Export (IPFIX)	Xing Gao (On site)
14:55 - 15:05	Export of L4S ECN in IP Flow Information Export (IPFIX)	Xueyan Song (On site)
15:05 - 15:15	Export of Encapsulation Layer Information in IPFIX	Yao Liu (On site)
15:15 - 15:20	Export of BGP VPN Information in IPFIX	Yao Liu (On site)
15:20 - 15:25	Export of IGP Flexible Algorithm Information in IPFIX	Yao Liu (On site)
15:25 - 15:40	Security Operations Fundamentals and Guidance	Michael P (Remotely)
15:40 - 16:00	YANG deVELpment PrOCEss & maintenance (VELOCE)	Mahesh Jethanandani (On site)

Detailed Agenda

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

Presenter: Joe Clarke & Benoît Claise

Joe went through the chairs slides.

Benoît Claise: The WG doesn’t get a lot of document reviews. That’s a problem. There are not lots of discussion at the mailing list for some documents. Authors need to also promote and trigger discussion for their documents.

Qin Wu: For OAM test scheduling, I just post the new update and makes summary. We received the comments from Daniel King and also Joe Clark from you. And so we also get together to address these comments. I think fundamental issue is related to, for example, a conflict reporting, and how do you provide a fine granularity reporting，so we come up with a proposal and also we discuss about sequence semantics. And with this issue we come on the proposal to address this, feel free to review.

Kent Watsen: There are connection problems in this room, because lots of people have hot spots running on their cell phones.

Joe Clarke: Yes, we strongly encourage try out the wifi here, please turn off the hotspots.

Mohamed Boucadair (Chat): The discard revision was already published early this week. The token is with the Chairs (not on the authors as listed in the slide ;-))

Mohamed Boucadair (Chat): @Chairs, for the alt-mark draft, please consider informing IPPM when the WGLC is issued.

Benoît Claise: @Med: yes of course, as there are dependencies on the YANG module and the deployment drafts. This was my point: those 3 documents should be treated together from a data modeling point of view. The reverse is also true: IPPM should stress the WGLC of its two drafts to OPSAWG

Joe Clarke: Lots of IPFIX related documents, maybe Benoit can say something.

Benoît Claise: We see lots of IPFIX-related documents. And actually, If you look in IANA, the registration procedure is "Expert Review", which means that you could go directly to IANA to request your IPFIX information elements (IEs), so we're wondering why do we have so many drafts? If a draft addresses only IPFIX IEs, it may not be necessary to write a draft. In the past, it was understood that a draft was needed only if it included more than just IPFIX IEs — such as use case explanations, key or non-key field definitions, or links to document modules (like Alternate Marking one).

Thomas: When I was drafting RFC 9160, I went first directly to IANA and requested those code points. And the answer was we can do that, but we would like to see a document. And ideally, an IETF document will be best.

Jeffrey Haas(Chat): In GROW, for BMP statistics, there is a desire to get WG review of the semantics. You can't do that if you just get a (First Come First Serve) FCFS code point and give it a name.

Joe Clarke(Chat): Fair point, Jeff. And ideally in that case, the experts can suggest, as Thomas said, an I-D is needed. What we are suggesting is to consider if the semantics need that kind of review in all cases.

Jeffrey Haas(Chat): It's one part review and one part documentation. when your documentation is 10 sentences, it probably doesn't belong in the registry as only place.

I don't argue this may be situational.

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

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

Carsten Bormann: Interesting work. Section 3.2 on canonicalizaiton has a normative reference to RFC 8785. This would be a downref. Is there anyone in the room who cares about this?

Joe Clarke: Please send the message to the list.

Thomas: Well done on the hackathon activity. I was reviewing https://datatracker.ietf.org/meeting/125/materials/slides-125-hackathon-sessd-applying-yang-provenance-signatures-in-cbor-objects-00 and I was wondering wherever there is open-source code publicly available.

Regarding draft-ietf-opsawg-yang-provenance-04 I noticed in https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-yang-provenance-04#section-3.2 the following normative text:

and verification SHOULD take place in advance of any processing by the consuming application. The actions to be taken if the verification fails are specific to the consuming application, but it is RECOMMENDED to at least issue an error warning.

To help implementors, I suggest to refer https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-11#section-4.7 and describe that this could be after the message deserialization and before the schema validation. I will put some text at the ML.

AI for chairs: kick off DIR reviews for SEC and YANG Doctors as well as IANA validation

3. Guidelines for Considering Operations and Management in IETF Specifications (20 min)

Presenter: Benoit Claise
Reading Material: draft-ietf-opsawg-rfc5706bis

Benoît went through the slides, reminded the rationale and approach, status, and received directorate reviews in particular.

Received directorate reviews were supportive, generally. There is one comment about the compulsory aspect of the OPS considerations section.
Benoît shared that this document has already positive effect on documents (almost all areas, various tracks (PS/INFO/EXP)).

On the comment about not having the mandatory section, Benoît explained the rationale as to help think about OPS matters early in the process. The recommendation from the authors is to maintain that section. He then asked whether there is any objection from the WG.

Mahesh Jethanandani: Other sections such as Security Considerations and IANA Considerations just say N/A when there is nothing to considered. No justification required. Can the Operational Considerations section follow suit and not require a justification?

Adrian: Similarly with security, the section is also a signal that authors thought about it.

Jeff Haas (Chat): Restating things, throw the 5706bis over the wall and start listening for screams.

Dan York: This is a great step and fully support this. As someone who spent a good number of years working to get IETF protocols deployed in the operator community, having “operational considerations” would be hugely beneficial in helping operators understand what they need to do. At a higher level, requiring the section may cause draft authors to think about how their will be actually deployed.

Boris Khasanov: (chat): +1 Dan, very correct!

There is no objection from the WG about the current approach. No change will be made on this aspect of the draft at this stage.

Feedback will continue be solicited beyond OPS (including as part the IETF LC).

4. Export of Source Address Validation (SAV) Information in IPFIX (10 min)

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

Thomas Graf: My point is related to RFC5706-bis, I looked at the document references, there is a SAV document where basically the capabilities are being described. There is an IPFIX document, there is a YANG document. I would love to see in this SAV document, an operation consideration section describing how the configuration is done, in YANG document how basically your documenting IPFIX is being used to actually monitor that.

Qian Cao: This draft is written complying with a YANG document. I didn't show here. We have some statements in the draft. We also are going to implement the end-to-end flow, using to connect with the YANG document, with our IPFIX.

Thomas Graf: I just want to mention your document, you have a reference to the capabilities to comment. So maybe you can reach out to these authors and mention about operational consideration, and maybe even propose a text in their document how your IPIX document could be applied there.

Chongfeng Xie: This work is interesting. This provides a means of transmitting and observing SAV events by IPFix，but the effectiveness is determined by SAV itself. If the SAV itself is not configured correctly, what you may see is only a part of SAV event, how to deal with this situation？

Joe Clarke: Do you want to Call for Adoption?

Qian Cao: I will give more use cases before the Call for Adoption.

...（Chat）:SAV enforcement is unlikely to be universally implemented as the SAV capability draft covers. That's one part of the issue of the IPFIX draft being premature. SAV enforcement when implemented as a drop discipline will simply be a different kind of drop and should be accounted for that way. When manifested in IPFIX, such discards will get covered in the appropriate augmented IE.

Joe Clarke(Chat): I was going to ask about that, Jeff. It seems to me that a SAV drop would be a "discard" and it would be accounted using the dicard model (of which there is an individual I-D on IPFIX).

Jeffrey Haas(Chat): Depending on your SAV-E implementation, the forwarding pipeline may account for things any number of ways, including the sav-capability model. But that model won't be universal. Many things might be a subset of it though.
For non-drop enforcement (example, redirect), other fields may be relevant, but it'll depend on how a permit action is accounted for in the implementation.

Mingqing(Michael) Huang (Chat): Yes, native-source based SAV and capabilities is quite new, and the implementation to all the SAV modes and capabilities will take time, given the draft of general sav capabilities just adopt about one year ago.

Thomas Graf(Chat): @Joe and @Jeff, my understanding is that discard-class is in terms of meta data not as granular as SAV. There appears to be an overlap in some areas with discard class.

Jeffrey Haas(Chat): Exactly.

Joe Clarke(Chat): Yes, correct. One of my questions was, would discard model account for SAV drops? And the other is how.

Jeffrey Haas(Chat): The short form is "however your forwarding pipeline can do so". it might be that enforcement is indistinguishable from other drops. however, when it can be distinguished, it should be accounted that way. There is (triumphant music) an operational consideration that SAV-E drops should be easy to distinguish from other drops.

Mingqing Huang (Chat): The motivation for IPFIX for SAV may not only about the discard-type, but by what rules, and additional IP header info export for further analysis. so basically, this draft what do more specifically.

Joe Clarke(Chat): Thanks, Jeff. That's what I was getting at.
Yes, the motivation is clear. I was more curious how SAV would interact with more general drop accounting.

Jeffrey Haas(Chat): Mingqing- I agree with the use case. We will likely find that accounting for "pass" cases to be difficult to distinguish.

Mingqing Huang(Chat): Agree, 'pass' cases not covered here. these cases might belong to other more general IPFIX model?

5. Requirements and Information Elements for Application Layer Information Export in IP Flow Information Export (IPFIX)

Presenter: Xing Gao
Reading Material: draft-gao-opsawg-ipfix-term-and-app

Alex: Please check whether the proposals are already existing in the IANA registratry.
Xing: I will check.

6. Export of L4S ECN in IP Flow Information Export (IPFIX) (10 min)

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

Benoît Claise: ECN field is also used for traffic class? You use unsigned8 data type but use only 2 bits?

Xueyan Song: Yes, we use unsigned8 type and exports bits 6-7 field for ECN.

Benoît Claise: There is an existing information element ipClassOfService (ID: 5) which exports the 8 bits of of IPv4 TOS or IPv6 Traffic Class field. You could be exporting the 8 bits directly and extract the bit 6 and bit 7 in collector for ECN evaluation.

Xueyan Song: OK, will have further offline discussion.

7. Export of Encapsulation Layer Information in IPFIX （10 min）

Presenter: Yao Liu
Reading Material: draft-liu-opsawg-ipfix-multi-layer

Thomas: I prefer option 1 and 3. Option 1 should be the case if not all the data from all the layers are being exported. Option 3 for exporting the information of all layers. For option 3, there are many implementations following that "SHOULD", it should be a "MUST".

Benoît Claise: Last time I suggested option 2, but even you use this, you can not guarantee the order, because there's the order of the exporting and the order of the metering. I will go back to the list.

8. Export of BGP VPN Information in IPFIX （5 min）

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

Thomas: I was just checking like from vendor implementation and I see currently, it's being abused. They're using the VPNv4, VPNv6 next top. They're actually using the IPFIX entity for IPv4 and IPv6. So what you're proposing makes sense and I am looking very forward for the adoption of the document.

9. Export of IGP Flexible Algorithm Information in IPFIX （5 min）

Presenter: Yao Liu
Reading Material: draft-liu-opsawg-ipfix-igp-algo

Thomas Graf: The references of IGP Flex-Algo should be clearly pointed to in the draft.

10. Security Operations Fundamentals and Guidance （15 min）

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

Ming Shuang: I think it may be useful to give a specific example to illustrate when the incident should be handles only by SOC, or it should be handled by SOC and NOC both.

Micheal: That's good advice to kind of distinguish when they're separate and joined and try and identify that. I'll look to include that in the next version.

Dan York (chat): Very useful draft to help explain this!

Joe Clarke(chat): @Michael as a teaser, I wonder if the scope of your draft is perhaps to enterprise-focused? What would one do differently for a provider vs. an enterprise network?

Benoît Claise (chat): @Michael, thank you for leading this work. I like the fact that your SECOPS document has Security and Operational Considerations sections :-). I would like you to get appropriate reviews for your document. Is there a SECOPS community out there? Sorry, a little far from my daily job.

Michael P (chat): Thanks for the comments.
Joe - that's a fair comment. I want this to be broadly applicable, so appreciate that feedback.
Benoit - At IETF, there isn't really a SecOps community, but I have shared with the SEC Area too for review. Externally to the standards world, there is a big community and we've started to reach out to get input.

Adrian Farrel (chat): @MichaelP. Agreed not a SecOps community in IETF. I think the point is: is there a wider community that can be called upon to provide input?

Michael (chat): There's a lot of experience in the broader "cyber security" community, but that's not a formal group/organization. We're certainly looking for places to get eyes on it and input, and very open to suggestions too.

11. YANG deVELpment PrOCEss & maintenance (VELOCE) （20 min）

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

Jeffrey Hass: So the question you should be asking here, does the split that we're talking about help with participation? I think, in some extent, it does, but that's not necessarily given.

Mahesh Jethanandani: Good observation. I wouldn't agree that things would move faster if we got review comments. I would agree that the criteria that I set 2 years may not apply equally for new YANG modules versus -bis versions of the modules. So I will admit that new YANG modules to take a little longer than this version to churn. Maybe there is this criteria that we say make -bis version should be faster, maybe a year, but new YANG modules should be churned out within a 2 years period.

Joe Clarke: As a contributor, I don't necessarily disagree. I guess Git lab versus GitHub, both do CICD really well. GitHub seems to be the canonical thing. Question five which was on. I strongly agree should be a must Michael Richardson suggestion of the hash is nice. I haven't really thought much about it, but on six I wonder what the magic is here like your experiment is around time. But if it's a module to easily agree upon module, did the VELOCE help that? Or was it just because just like some of these IPFIX things, they move quickly because there's not a lot of contention there. So I wonder why is GitHub in and of itself? Why is this approach going to be generally quicker to produce some of these modules? Because it it's better for participation. These are the things I would like to capture as part of the experiment. What was the overall experience with module development because of this?

Mohamed Boucadair: We need to agree on the goals of this effort—whether we're aiming for speed, quality, or enabling others to contribute. There are different perspectives from those who draft and those who code, so we should consider a range of criteria. The experiment may not be about doing things faster, but differently; we need to find the right balance and frame these goals clearly. I’d also like two documents, as the timeline depends on whether we focus on running the experiment or its outcomes—this is something we should discuss. I don’t expect to resolve everything today; we just need to start, bring people together, and iterate. That will give us something useful to present to the committee, whether we call it success or failure. Finally, Mahesh is contributing to this effort; I’ll be shepherding it, having started earlier, while he brings the energy. Just to clarify.

Italo Busi: The pain point is the -bis, especially with the types YANG. The need to republish a 100 page document just to add one attribute or one typedef and getting review comments on the 99 pages which have not been changed is making the process unnecessarily too slow.

For the first version of the model, I am not sure whether VELOCE would make the process faster. The speed of the first module development depends by the market pressure and efforts being spent by the contributors. If we wish to keep the same level of consensus and quality, this would anyway takes time.

Mohamed Boucadair: I will just clarify is that this work is anchored on the requirement we are having in the NMOP working group, there is a requirement which is do it quick and well. But I think that are the two products. We need really to find the balance not to be perfect. But we need to have to provide something that they've said answers. The main, I would say, function that we are targeting and then built on that one. But you are right about the -bis. This is something that we need to cover in the description of the experiment and the one that we are targeting. As soon as we are clarifying the target, I think the more we will get, other authors of the draft to join us. We need also to reach out with other working groups.

-End-