Minutes IETF124: opsawg
minutes-124-opsawg-00

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

When: Mon, November 3, 2025 17:00 to 19:00
Co-Chairs: Joe Clarke \& Benoît Claise
Secretary: Chongfeng Xie

Compact Agenda

Slot Topic Presenters
17:00 - 17:10 Introduction \& Document Status \& Agenda Bashing Chairs (On site)
17:10 - 17:20 Applying COSE Signatures for YANG Data Provenance Diego Lopez (On site)
17:20 - 17:30 A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests Qin Wu (On site)
17:30 - 17:35 Export of Path Segment Identifier Information in IPFIX Yao Liu
17:35 - 17:45 Export of Encapsulation Layer Information in IPFIX Yao Liu
17:45 - 17:55 IPFIX Protocol over QUIC Yisong Liu (Remote)
17:55 - 18:00 Export of QUIC Information in IP Flow Information Export (IPFIX) Changwang Lin (Remote)
18:00 - 18:10 Export of Source Address Validation (SAV) Information in IPFIX Qian Cao (Remote)
18:10 - 18:15 CATS Metrics Exposure Using ALTO Jordi/Luis(On site)
18:15 - 18:25 Secure Hybrid Network Monitoring Yumi Sakemi (On site)
18:25 - 18:35 RFC5706-bis Update Benoît Claise (On site)
18:35 - 18:55 YANG deVELpment PrOCEss \& maintenance (VELOCE) Med and Mahesh (On site)
18:55 - 19:00 Open Discussion All

Detailed Agenda

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

Presenter: Joe Clarke \& Benoît Claise

Joe: Now let's get into the fun stuff. We have 5 new RFCs,

RFC 9870 - Export of UDP Options Information in IP Flow Information Export (IPFIX)
RFC 9833 - A Common YANG Data Model for Attachment Circuits
RFC 9834 - YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS)
RFC 9835 - A Network YANG Data Model for Attachment Circuits
RFC 9836 - A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits

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

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

Rob： In the YANG Push header your provenance leaf is before the data, but I think that it should probably be after the data. That potentially allows implementations to write a signature after the data has been processed rather than caching the structure in memory first.

Diego: We try to follow the convention that we're discussing with the people implementing YANG Push messages. They told us that it should be just before the other data. Regarding signature stream processing, that is challenging, as signature is extremely dependent on message context, including closing tags.

Rob： You have chosen to do the normalization over the instance data but still represented as a JSON or XML document. I was wondering whether there should be an abstract normalization of YANG instance data and an algorithm to generate a COSE signature based on that abstract structure rather than tying it to the encoding.

Diego: Because the point is that what you sign is the document and not the general instance model. You sign what you're sending on the wire or what you are storing on the file. So even a change in a carriage return changes totally the signature.

Rob: Why not just canonicalization either or why not just sign the byte stream?

Diego: If it is the byte stream, as before being directly sent, that could be, that's something that we could consider as some kind of optimization. I am not totally sure that would be applicable. I’d like to talk with some people that are using what they call semantic canonicalization and exploring what that means. But I fear that I have seen some examples, I don't know if they're applicable here. Optimizing signature processings probably one of the things that we will consider once we have the base mechanisms settled.

Thomas：Just following up on the conversation we had at NETCONF. We got feedback from the YANG doctors that, in an envelope, basically the metadata should come at the end of the header. And we got feedback that basically there is no way in YANG where you can define how data is being serialized and in which order. Therefore, looking now in your document, I see also the provenance leaf is inserted before the contents leaf, so I think you have to remove that sentence as well as we did on the notification side, because YANG doesn't allow you the order of how it's being serialized.

Diego: Ana, who's making the implementation, has been talking with Alex and some others in your team about this issue. Yes, we are aware of that, and this is something that we keep looking.

Benoit: There are four mechanisms,

1. Including a Provenance Leaf in a YANG Element
2. Including a Provenance Signature in YANG-Push
3. Including Provenance as Metadata in YANG Instance Data
4. Including Provenance in YANG Annotations

What should I do? And which is the priority. Being too flexible is not always the right approach

Diego: We have found that, in fact, we have two methods: either you use augment or you use an annotation. So this is something that we have to discuss. And probably we will change the structure of the draft to say you have these two methods, YANG Push or instance metadata would then become particular cases of the augment method.

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

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

Joe, as chair: need more feedback on the list

Joe, as contributor:

• Why do you define the identity but in the example it's called t-wamp tests?
• You underspecify your error conditions, you only have one error type and it's enum, suggest for more specified error conditions beyond a single enum type, to give more context why (ex: is it resources contention)

Qin: Yeah. we will clarify in the next version about your suggestion.

4. Export of Path Segment Identifier Information in IPFIX (5 min)

Presenter: Yao Liu
Reading Material: draft-ietf-opsawg-ipfix-path-segment

Benoît: The title is export of PSID, can you add a little bit of segment routing in there.
Yao: Will update it.

5. Export of Encapsulation Layer Information in IPFIX (10 min)

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

Chongfeng: Can you give me a use case of muti-layer encapsulation?

Yao: A use case is that when the IPv6 packets sent by the CE arrives at the ingress PE, which is also the headend of an SR Policy, then at least there would be packets with 2 IPv6 headers in the network.

Joe: RFC5706-bits hat on, what is the interoperability risks of these new IEs if a collector doesn't understand them, would there be a risk that it would interprete the data completely incorrectly?

Yao: No, it would not be worse, the collector would process the data following existing procedure if it didn't recognize the new IEs.

Joe: That's probably worth mentioning in the operational considerations.

Thomas: The problem describe in this doc is real and it needs to be addressed. Because you have several networking layers in your network, it doesn't mean that IPFIX would export all the layers. From a collector point of view, you don't know which layer is actually exported. The question is you solve the problem on the device itself, but if we look at end-to-end at the network, there may be a device covering 4 layers and another device covering 3 layers, have you thought about how to resolve that problem? On one device, it could be the top layer, while on another device, it might not be the top layer.

Yao: Yes, in this document we only provide the solution to report the encapsulation layers from the perspective of the device itself. The device doesn't know which layer it is from the context of the end-to-end network; it will export from its own understanding.

Thomas: exactly, it only knows on that device which layer it is, and it doesn't know in the context of the network.

Benoît: In your proposal, the semantic of one IE(e.g, the destIPv6address) relies on the content of another IE(e.g, encapLayerTop), we've been trying to avoid this in IPFIX. Maybe use the export structured data in RFC6313.

Yao: Will think about how to define the IEs in a more clean way.

Daniel Voyer: Can you also notify the srv6ops WG with your work, about your objective and use case.

Yao: Sure.

6. IPFIX Protocol over QUIC (10 min)

Presenter: Yisong Liu
Reading Material: draft-llg-opsawg-ipfix-over-quic

Joe: It won't solve the problem that Thomas brought up, the multi-stream approach could solve the encapsulation thing, if you could configure a stream per encapsulation layer but wouldn't necessarily equate two different devices.

Per: In the zero-round trip initialization of the connection is that it has worse security than the one-round trip? In a NETCONF over QUIC, zero-round trip initialization is not allowed. Is zero-round trip initialization allowed or not allowed?

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

Presenter: Yao Liu
Reading Material: draft-lin-opsawg-ipfix-quic-header

The authors would like to request for adoption.

(from the chat) Mohamed Boucadair: I’m not sure the definition of the flow would work as multiple CIDs
can be used for the same connection, CIDs can be withdrawn, connection migration may happen, etc.

Polls (Do you think this should be adopted?) Yes(9) No(0) No opinion(14)

Joe: We could do an adoption call on list. But it would be good to get more people to review and on it. Chongfeng and I will spend some time reading it.

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

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

(from the mailing list)
Chongfeng: There is a YANG model document about SAV general capabilities. Is there a connection between the IPFIX for SAV-related IEs and the YANG model definition?

Benoit: The mappings between the SAV YANG data model and IPFIX IEs are considered based on the common foundation of the general SAV capabilities document [I-D.ietf-savnet-general-sav-capabilities]. The operational correlation is demonstrated in Table 1, which defines the values for the designed IEs mapped from the corresponding [I-D.li-savnet-sav-yang] SAV Management YANG Module.

9. CATS Metrics Exposure Using ALTO (5 min)

Presenter: Jordi/Luis
Reading Material: draft-ymg-opsawg-service-deployment-with-alto-cats

Adrian (in chat): Chairs/ADs I am, of course, going to be asking where ALTO work lives in the IETF
As of today, CATS does not do protocol work

Med (in chat): I used to be the chair of ALTO and I don't remember there was a default "maintenance" for the protocol for ALTO. Maybe reach out WIT?

Joe (in chat): I've recorded this in the minutes as I think recording a possible alternate home for this work is useful.

Adrian (in chat): The ALTO WG closed with the following note: The ALTO working group has completed its deliverables and is closing. Thanks to everyone for their hard work! The mailing list will remain open to help the ALTO community coordinate on deployments and to improve the maturity of potential future work.
No comments to mic, and we were tight on time.

Luis Contreras (in chat): @Joe. We have not socialized this in the ALTO mailing list. Of course, we can make it. From the times of ALTO closure there were indications of OPSAWG as potential home for ALTO maintenance, I can do archeology to find public discussions on that. In fact that is why draft-rcr-opsawg-operational-compute-metrics was presented in OPSAWG. Being said that, maybe there are other potential home ft it, of course.

Joe Clarke: Our charter allows for small, operational work that doesn't have a better home. What I want to make sure as chair is we have the interest present to move the work forward.

Adrian Farrel: There are other ALTO I-Ds too? E.g. in TVR. What is happening with them?

10. Secure Hybrid Network Monitoring (10 min)

    Presenter: Yutaka Oiwa
    Reading Material: draft-oiwa-secure-hybrid-network
    draft-oiwa-path-characteristics-service
    None.

11. RFC5706-bis Update (10 min)

    Presenter：Benoît Claise
    Reading Material: draft-opsarea-rfc5706bis

    Michael: I am writing more detail on security considerations in a seperete draft, if you like to contribute, please get in touch.

    Rob: This is good work. Have you checked that other ADs are happy with us adding this into all documents?
    Benoit: Yes. It has been discussed in multiple IESG meetings.

    Rob: I just want to check we’re not going to start doing a document and then find later on the process it gets blocked.

    Benoit: At the last IETF meeting in Madrid we presented in the routing area specifically for this, routing area a first customer for this, hopefully all folks in OPS are convinced.

12. YANG deVELpment PrOCEss \& maintenance (VELOCE) (20 min)

    Presenter: Med and Mahesh
    Reading Material: draft-boucadair-veloce-yang

    Kent: You made the comment about it needs to be faster if it takes 2 years. Faster with what? Faster with the first release? Or faster with maintenance releases thereafter? The first release you really want running code. So how do you make that faster?

    Mahesh: Certainly, maintenance release, but even the initial I’m wondering, should it really take 2 years, or more？

    Kent: Do we require running code still?

    Mahesh: Running code I think you mean an implementation of the YANG module. I think even idr removed that requirement that it needs to have an implementation.

    Jeff Haas: The 2 year thing would be obstacle to that is the penalty that is currently there to get this wrong. You get your structure wrong, anything else wrong you have all this giant corpus of rules that most IETF isn’t falling from NetBod, you can’t do that, fix that problem and things happen faster.

    Rob: I think we need to split this in terms of whether the latest and greatest leaves. We allow the YANG module to iterate and evolve. And some of might be small iterations in terms of fixing description statements and things like, other ones might be adding why regardless of minor enhancements or a few leaves here and there. We don’t have to produce a new RFC, just to add a few things，in that case you can’t put the full tree diagram in the document because that becomes out of date straight away，you could put in a snippet of the tree diagram and a reference to where the full one will exist or some tooling to generate the full one automatically if you need it. I think that works fine.

    Mahesh: Okay.

    Balazs: I thought it would be to consider the tree diagram in the RFC, but only as informative not normative, if we deviate from it, it’s not catastrophic. I very much agree with the previous points, but how easy or difficult will it be to describe the functionality if we don’t even have diagram in RFC? So I would consider any informative tree diagrams in the RFC.

    Mahesh: That’s a good point. I like the idea of keeping the idea simply to be able to describe the module. And usually you do description of the module using the tree diagram in lots of cases. So I feel that there is some argument to have at least some information in the ID.

    Joe: Why do we need an ID? What you want is to make sure that the YANG module itself is fully documented so that I look at this artifact as an implementer or as a consumer. What really should matter is the artifact of the YANG module.

    Benoit: We discussed that the last time, I recall there was a proposal to have the ID inside the young module, so if you want to disrupt I would say: do this right.

    Kent: I’d like the bold idea of moving that Joe refers to, but going to Rob’s comment about the not having the tree diagram in the ID. I agree with that I’m sympathetic with that statement. But as soon that if you know a little bit outside this conversation with YANG packages, if you’re if the package locks down to a simple version of the module, all the modules that is referring to, then a tree diagram could be generated for the package, it would statically correct?

    Jeff Haas： Why would you have an ID? Because that’s the thing that IETF as a whole looks for, so the problem is how do you trade everybody to look elsewhere well, you have an ID that points over here, but more to the point having the ability to sort of refer back and forth to each other is certainly a ease of convenience that tools could do. The second point here is what do you want out of something that is a YANG module in an ID that you want the IETF as a whole to look at? Most of the time, it’s the structure, the keys, and that will for about 90% of people be too much but enough. The one thing that you have to figure out what to do that’s outside of those two easy things is YANG modules have sometimes too much magic happening in the descriptions for the individual objects. You would want to figure out how do you flag something important has happened that doesn’t change either the structure or the keys.

    Rob: I think sort of following up to Jeff’s point sort of basically agree in the way that I was envisioned this is that the draft and the RFC would cover the core concepts like the overall design of the module at a high level but not going to too many details, and so as long as your model is evolving in minor ways you can do that entirely outside the RFC process. Needs of consensus check in terms of what the changes are. That needs to decided but only if you make major changes to the module and major changes to the structure, then you need to update the RFC. So to Joe’s point, I’d love to be able to say you could document this all in YANG, I think you’d end up getting the same problem we have today, but just in the other way around, it’s not great to put YANG into documents because YANG is code and it’s not documents but I also think it’s probably not great to put documentation in code because again that doesn’t work too well, it makes the YANG module very long in various places if you have to put lots of this other sort of in there so I still think that having some documentation RFC to go along with the YANG module is good. It’s not clear to me your process that when you come along to Bis this this young module, update it, what’s the process there? Is there a new ID tracking that? I was discussing this with the … but their suggestion was effectively is that you create an ID that contains the diff. And that’s all it contains and you ship that through the process and when you get to IESG approval then that’s it’s done, you publish the new version of the young module on IANA or something similar, so you don’t go through and generate new RFCs, but I still worry about going through the whole of the IETF process for these things. I’m not convinced whether we need IETF consensus on the YANG modules, the differences.

    Mahesh: I think that worth considering. To summarize, we do agree that we do need to keep an ID asset and we need to have the module, I need to describe and have some description for the module, but keep all the code in the GitHub. Is that fair? A Bis should not be a new draft, it should be just a revision of the YANG module. I think that last point is going to be also critical.

    Rob: If we can do a bug fix, we’ll a leaf and that can be done in a matter of like a month rather than like a couple of years, then I think we’re doing well and I’m not too hard about the two-year timeline in terms of a new year module. I think that … in some senses and I’m not sure whether IETF YANG could get a lot quicker, but anything that improves this process and makes it easier to maintain I think will be helpful.

    Mahesh: I put two years as a marker and I guess the experiment will prove us either right or wrong.

    Balazs: We should aim for two months, do we need the ID? Currently, in most of the RFC, the text is 70%，70% can go into the YANG model or can be thrown away.

    Mahesh: We never create an RFC out of that ID, because once you create an RFC that means you have to do Bis.

    Rob: You create a RFC for the first version that covers the high level structure and it says, that obviously has pointers to find the latest version here, point here to either find the latest tree here or this is this is how you can click on this link or generate the latest tree for you. If the structure hasn’t changed, your keys haven’t changed you haven’t added things and moved things around, the RFC doesn’t change. You just add Bis in. But if you add some new functionality, you add something significant into it, you need to Bis the document.

    Mahesh: The point is there’s a stable reference that we point to from the ID, what will that point to?

    Rob: This is different what you’re proposing. I think that you need to have versions of this where you’ve got like the latest and greatest that you’re iterating it and you need to have more stable versions of that, so once your YANG model has been stable for six months and you’re happy you’ve done some sort of check and some magical way, might be another ID, you then probably ask IANA to keep a reference of that updated version. So you store it somewhere else and that’s your stable reference. And then what’s on GitHub can be your iterating version. So the example that Italo was describing, and it says they’ve got some types modules can’t make CCAMP working group, and they want to sort of publish the version they’ve got but the same time they will immediately want to Bis it and start adding more things into it, so he wants to have a split between a stable version and the latest version this evolving. And it’s the same sort of thing that OpenConfig is doing is every six months or once a year or something they’ll then update their cut across the current YANG watch and this is the next release and then they’ll do some changes in iterations, and then a year later they’ll cut along and say okay this is now ...... version 4 or 5, so there’s some sort of balance between those two.

    Reshad: When you mentioned the two years at the beginning and others asked questions, wasn’t clear to me if the two years was just for the YANG. Let’s see you do an initial YANG, not the two years for the RFC?

    Mahesh: For the RFC.

    Reshad: So I agree with Rob, if you do a Bis, if you take the example of the BFD chain, you me and Jeff were involved in, that should be two months but I think the first RFC, what you’re doing something like, L2VPN, BGP, two years might be a bit too aggressive, I think you have to distinguish between Bis and non-Bis.

    Mahesh: Okay, I think I’m coming from a position that I think if you’re taking that long, we are making ourselves irrelevant.

    Balazs: If it takes more than two years, OpenConfig or someone else will do it instead of us.

    Mahesh: If I’m not getting something that I need to deliver sooner, am I going to wait for forever for it to happen?

    Reshad: Yes, but I mean, that’s also dependent on it’s not just where you put the model and whether there’s links from the ID to the model, it’s also linked to how much effort people are putting into it and whether it’s the authors or the working group, so it is the assumption that once it’s in Git that you’ll get more easier to work on?

    Mahesh: It‘s definitely be easier and part of the argument is that it should make it faster to be able to publish that RFC.

    Reshad: As you said, it’s an experiment, I hope you’re right.

    Balazs: I think the two years for a first ID is also dependent on how aggressively the chairs go for compromise for agreement.

    Adrian Farrel: The fact that work takes a long time to produce means nobody cares. If you care about it, you do it. The fact that you can produce stuff faster if you don’t document, it is definitely true and it’s a total waste of everybody’s time, so we document stuff in RFCs to explain what the YANG model is for. And there was another point, use GitHub to develop stuff, that’s just writing code, get on with the code but then suck it back into documentation, it is true that there has never been a case where the RFC editor has looked at the text in a YANG model and improved it.

    Mahesh: So maybe I’m have given the impression that just because the module sits outside the ID, the RFC editor doesn’t have access or can’t provide comments. There is a stable reference to the document, to the GitHub location. So if there are comments that need to be incorporated, my suggestion would be they could as well be done in GitHub itself.

    James: I agree with a number of points for initial modules. I don’t think the time is a concern necessarily, some of the benefit is that the modules have been well thought out over a period of time. And so that’s beneficial. We can make use of something like the semantic versioning work to look at things like automatically missing things if you make a change and a it's a you consider X.Y.Z if it's a Z change, then nothing happens. It stays in Github. But if you cut a new release of a major module, we could automatically write an ID Bis without anyone actually writing it and automatically submit it. Maybe we look at whether it's the working group or whether it's the AD or someone has to sign it off so that could speed up that process. I also wonder if don’t know the answer, may be met does if there’s any kind of legal requirement for the IETF to hold some particular asset that currently is an RFC and shouldn’t be something on GitHub as a YANG module, I don’t know if there’s any constraints in that.

    Kent: I came to make the same comment that James just made, which is if we bind this to Semver, and the Semver of the module, the diff in GitHub is patch or minor than node rev of the draft is needed But if it’s major, then revising the draft seems to be needed.

    Mahesh: I’m just going to try to conclude this comment，I’m not going to show on other slides is folks seem to be uncomfortable with the two-year suggestion that I made as well. Further suggestion is to see how well we do, if not, then what is it marker? We want to set for ourselves how do we decide that the experiment was successful or not. Continue the discussion on the mailing list.

    Joe: Yes, clearly there is some passion around this topic.