Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Minutes IETF124: opsawg
minutes-124-opsawg-06

Versions:

Meeting Minutes		Operations and Management Area Working Group (opsawg) WG
Date and time		2025-11-03 22:00 Meeting Local UTC
Title		Minutes IETF124: opsawg
State		Active
Other versions		markdown
Last updated		2025-11-19

minutes-124-opsawg-06

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

Detailed Agenda

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

Presenter: Co-Chairs

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.

Benoît: There are four mechanisms,

Including a Provenance Leaf in a YANG Element
Including a Provenance Signature in YANG-Push
Including Provenance as Metadata in YANG Instance Data
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 the chair, need more feedback on the list

Joe: As the 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?

Benoît: 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?

Benoît: 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.

Benoît: 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.

Benoît: 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.

-End-

Minutes IETF124: opsawg minutes-124-opsawg-06

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

Compact Agenda

Detailed Agenda

Minutes IETF124: opsawg
minutes-124-opsawg-06