Internet Engineering Task Force Interim Meetings, 2 Mar 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CORE-20220302-1500

Description

CORE meeting session at IETF
2022/03/02 1500

https://datatracker.ietf.org/meeting//proceedings/

A

You know that, but you know.

B

Yeah, I would love to find a good shepherd for young sibo.

C

Yang sibor, that's me right.

B

Oh, maybe I'm talking about the wrong one right now.

C

And and see this hymen so on the other two corcoran documents uh in the queue to take at some point: it's it's! You.

B

Yeah, so I I was actually talking about it uh because that's where the action is at the moment- and we will do some- some weird uh turns there but uh yeah. Let's talk about that in five minutes. Sure.

C

It's 4pm right now, at least here in stockholm, but let's wait few minutes more before starting.

C

Thank you christian for helping take a minute.

C

C

C

Okay, it's two minutes past. So, uh let's start the meeting. Welcome everyone to this interim uh meeting of the co-working group. uh I am mark tiloka. My co-chairs are I'm humanity and carsten berman welcome back, and since this is an official ikea meeting, the not well applies. Please be familiar with that become familiar with that, if you're not already it's not about ipr, only it's also about our conduct, especially so very nice and professional uh with one another.

C

uh The agenda for today is uh pretty slim, so I believe we're going to have relatively short meeting, but we start with the usual round of updates on the uh cork of documents and href and coral, and then we have a presentation from giuseppe about an update submitted for the core performance measurement option they are proposing.

C

Does anyone want to add anything more or bash this agenda for today.

C

There's none then carsten. I think you can take the car count. Part.

B

Yeah, so this is uh going to be very short part because uh actually there was zero time between the last. I remember and at the time uh now so my report from from the the last time still stand, and so the the objective is to actually get the the new ideas from the discussion we had on last thursday um into the sid document. I haven't actually managed to do that yet, but that's very high on my list now and um maybe to get yang zebo liberated.

B

So we can push this through while we are still discussing some of the details of sid going through a second itf last call getting another telechat date um and so on, but rob wilton still has to agree to to this uh procedure. So I don't know if we will be able to go forward with that.

B

So a prerequisite to to actually doing that would be that I now go to the isg comments on young sibo and put them into the document and get a version submitted before the internet draft deadline. So if you can follow that repo, while I'm doing that, that might be very helpful.

C

Thanks francesca.

A

um So do you please let me know I wasn't um at the meeting last time.

B

All right right.

A

Looked over at notes, but I just wanted to know if you need me to um talk to rob or or yeah. Let me know when it's time to to get this feedback and if I can do anything anything to speed the process.

B

Yeah, I think we we might need a little nudge to actually liberate yang sibo of that normative reference, um so that might be a place where, where we actually could use help- and I'm not sure sure how um informed uh rob is about the the various places where we really could use an rfc now for uh gang sibo, so that that might be a little nudge uh that he might be able to use.

B

um But yeah, apart from that, we we have to do this negotiation.

A

Yes- and I saw this uh email um yeah that that that is linked from the uh from the minutes- I I will go and look at what the last exchanges are and see if I need to ping him, but otherwise, when, when we have a an update on the document, that might be the best yeah.

A

C

All right sounds like a plan.

C

So, if that's all for the corkov part, we can just continue with href and coral. I think especially on href actually.

B

Yeah on hf, I can report that we almost have agreement on the test. Vectors apparently, are stumbling over some some good problem at the moment, but I hope we we can have that um done very very soon, so there will be stable test vectors available for other people uh to play with within a matter of days,.

C

Okay, any chance to have a selection of those already in the next submitted version of the document very much.

B

So, yes, oh that's great.

C

All right and yeah, I know you're very much focused especially on that right now for href.

C

Okay uh thanks, I guess no particular update or things to mention on coral christian. Instead right.

D

I've I'm I'm already in a back and forth with uh in emails with peter o'kil, about the topic of how do we declare the directions in tibor, but I think that's a relatively minor thing that no updates, but if anyone is interested in all the fun details that internationalization has, I have lots of links. I could send you if you're interested.

C

Thank you, okay. Then we get into an actual presentation. Now it was a resubmission for this document a few weeks ago and fit nicely in this meeting. So um hi giuseppe uh as you wish, you can share the slides yourself using the share, preloaded, slides tool of me. Taco.

E

Hello, can you hear me.

C

E

So I have to ask to share the live.

C

Correct and it should be loading now.

C

And now we can see them.

E

Okay yeah, uh thank you, marco, for the opportunity to present today. So this is an update about this graph that we present as a zero zero version during the the latest iitf meeting in november, so yeah in this okay. Just to recap about the motivation for whom you do not read this document, so this is to find the mechanism to measure the performance in code.

E

It should be, of course, a simple mechanism because we have to meet the constraint requirement for the nodes involved in the measurement, so this kind of measurement need to require just a minimal amount of collaboration from the endpoints.

E

We all know that it is resource consuming to read id sequence, number and store timestamps for constrained nodes, so the let's say the traditional mechanism to make this kind of measurement is not so applicable in this environment.

E

So we need a straightforward methodology: the change the from the zero zero version to zero one. um Let me thank the for the comments christian and thomas that we had some emails exchanged after the last atf, and this also helped to improve uh the document. We had new consideration to introduction and to the description of the option, um but most important. We had a new site, we added a new section on application scenarios to explain how to do end-to-end or segmented measurement, and then we also try to work on the security section.

E

In particular, we mentioned that oscar can apply to ensure end-to-end integrity, protection.

B

E

Just a few words about what is the technology background uh behind this proposal, so in ippm working group, we are working on an explicit flow measurement techniques that the main scope is to employ. A few marking leads inside the adder of each packet for loss and delay measurement in a client server protocol. So a typical example is quick or tcp, not mainly in quit.

E

The draft has been adopted in ippm, and the first application, of course, is pin beat that the spin bit idea is to create a square wave signal uh using a bit, and the length of this signal is equal to rtt, so each on pat observant can easily measurement measure the round trip time without taking time stamp just to measure the length of the square period.

E

This is optional in quick. You can see in the related rfc related standard track and also in the quick manageability document. You can see all the details about the application of stimulate the other beat is called square beat.

E

It is different because it times to create square waves of well-known length, uh for example, uh square waves of 64 packets.

E

In this way, uh if you are an op up, top server can uh easily measure the packet loss, because if you don't see 64 packets for each for each period, you can easily measure the losses.

E

Another additional feature is also to use this square wave to measure both packet loss and delay. But if we already use pin bit for delay, we don't need to use the square bit for delay as well, but is an additional feature.

E

How we apply so the the idea is to apply this really straightforward methodologies to copper environment, to co protocol. By defining the new option.

E

In this option we can. We can define two patterns, for example, if we want to use one bit or two bits. So, for example, I this is just a proposal for discussion right, so I said to the first bit uh to identify which kind of pattern for the option. The first part that can be with this just a single bit for performance. um Otherwise, you can use two beats, that is, the square beat and spin beat since we have defined one byte. I also added other event beats. For example, you can.

E

You can imagine uh another kind of uh scenario when the event beats can be divided into two parts, loss event and delay event and, for example, an endpoint that can be the server, for example, can define different levels of thresholds for loss and delay, and in this way an onpart observer can read these event bits and may know the network condition by by looking at this threshold information. This is just to use these additional bits, but it's just an example.

E

Now, in this slide, um I try to explain the different scenarios.

E

uh As I said, the first, uh the main usage is to do end-to-end measurement between client server, but the additional feature is to do split measurement, because if you are going to set this spin lead and square bit, of course, for free, you get also measurement from the onpath server.

E

What are the intermediary of pattern server, so they can be network functions, probes or they can be gateway proxy and that are tasks to perform requests for call. So if the on bottom servers are network functions or probes, of course, the co-op option can be applied end-to-end. So we we can imagine a scenario where we have an end-to-end connection between our client and the server and in the middle. We have those uh on pattern servers in this way.

E

The onpad observation path, probes can read the qubit and spin bit and can measure the losses and also the round trip delay.

E

Otherwise, if they they, if it is applied, also the event beats uh algorithm. The the umptop server can always read. Also the event leads in this case. The other case is where the ompatop servers are cop proxies.

E

In this case the we cannot talk about an end-to-end connection and the option can be applied for the separate connections between client and server. So in this case we can do. The measure will be segmented between the proxies between proxy and the client or between a proxy and the server, because we have separate connections in this case.

E

We maybe we have to add more details in the next version, because you can always think to bundle different clients if they are mixed or you can think to use the option for a single client at once, and also the communication may happen with different servers. So in this case you have to to check other additional fields to understand the server and to make the measurement according to the specific server that you you are considering.

E

uh Okay, yeah just the in addition of the light about what are the key points and benefits so, first of all, no id sequence number for packet clause um and also there is a flexible fence time handling this. This is to meet the requirement of constrained nodes.

E

Then there is also a proposal to improve the square bit mechanism with the same synergy with spin leak, but this is just an additional feature and we can also think to possible advanced usage of this option, because if the umptop server that can be the proxy or gateway can interconnect different networks through these additional bids can use this information also to adjust protocol parameters, for example, or it could also be possible to decide based on the network, condition to if it's the case, to use reliable or unreliable transmission. So this is just for brainstorming.

E

I think that's pretty much all so yeah as next steps. Of course, we just apply well-known methodologies.

E

To this protocol, we think that it can be used because it can be useful, because this methodology meets the limited resources of constrained environment and, of course, we always welcome quests and comments and inputs to improve the document. Thanks.

C

Thank you very much. Isabel justin.

B

I have two questions. One is um twipe, of course, is often used over dtls and then at least random probes. In the network, you will not be able to see what's going on. Of course, the endpoints will be, but you cannot make information available to to um transparent uh systems on on the ways. Is there any uh attempt to get something like this added to dtls.

E

uh Not yet but yeah, this is something that uh we can consider yeah. uh It's it's a good point. Yeah yeah.

B

E

B

We can put it into the outer header, but if we are using dtls, we don't really have control over what's in in those headers. So maybe that's worth having a look at the the other question. um Maybe it's not so much about this draft, but but more about the the ecosystem that will spring up to make use of this.

B

What is going to be the the way that the peers actually agree on the the kind of configuration they will be using here? So how do they know? The number 64 in in your example is: is there a really.

E

Fun way, this is something that the yeah it can be, for example, configured for now the control protocol- let's go like that, is not yet under definition for this for this mechanism, because we are really, we are still defining in ippm the methodologies.

E

So one of these methodologies is already optional in quick protocol, but for the control protocol. So for now we assume that it is static.

E

This is a static configuration on the node uh yeah, but in the in the future we have to think about the control protocol, for example for ipv6. We already have uh for the alternate marking methodology that is quite related to this method. We are working on control protocol, uh but this is uh in a second stage. Let me now let me because for for now we want. The first thing is to to define the methodologies to to find an agreement about what are the parameters.

B

What I and then we can define.

E

The control part.

B

Yeah, probably the control part needs to be extremely extensible, because there will be very many ways to to use this. So um it's probably a good idea not to tie the the actual bits on the wire uh to the way the the configuration is exchanged. On the other hand, to to start experimenting with things I mean. Even if you do static configuration, you probably want to interchange configurations between the experimenters. So you are.

B

You essentially need to have something there from day, one, at least if you want to have cross-domain experimentation.

E

Yeah, it's correct, yeah, it's correct for.

B

E

Part yeah we need to to think about on everything is defined for the protocol. Yeah we can discuss.

E

The cross domain is an important thing that we have to consider for indeed, for some application. We we limit this to control a domain since.

B

E

Solve the cross domain and security problems, privacy issues so to to easily overcome this kind of objections we are limiting to control a domain. This is for the control part is something that you have to consider.

B

Yeah, of course, that also depends on um whether you actually think about the configuration part as a control part. So you, you command the other side to do this or that or something that that where essentially the two sides exchange, what what they are uh willing to do and and uh then agree on something. So it's not that um you don't really have to have them in the same domain, so both sides are are kind of free to do what they want.

B

They just explain what what they are doing, so they know the 64 or whatever. These parameters are.

B

So, what's what's your intended status for this work, so when this becomes an rfc, what should it be.

E

Do you mean in co-op or in ippn.

B

I don't know, I don't know even that.

E

Okay, because yeah in rppm we are defining the let's say: the document is just informational. It means that we are.

E

There is telecom italia, orange other some operators, but also akamai that already have early deployments of these demonstrations um for the application on quick in particular. So that's why in ippm we.

E

Proposed just an informational document that they find the methodology uh in a let's say, transport agnostic way, so it can be applicable to quick to tcp to co-op without any any problems right. So you, you know you can apply in a client server environment uh in a class for a client server protocol.

E

So in quick, it was already discussed. Spin bit has been accepted as an optional usage, but for the other lost bit that I also had idea, it is still under discussion because in quick you know that it is driven by over the top. So it is quite difficult to uh to propose things to propose new things right. So that's why we also had the idea to introduce this to co-op, because it is also a similar environment and the the fact that on constrained nodes you have those limitations also um can easily.

E

Can leverage right the the the way how this methodology works so yeah? So in ippm we are defining the informational documents and then we want to propose a.

B

E

um uh Two different client server protocols for now quick code are two candidates, the let's say the standard track proposal now.

B

Okay, so you didn't mention experimental as a potential outcome.

E

Yeah, um let's say the experiment is the is the activity that is mainly done in ippm, because.

E

We there is also a hackathon table on these methodologies, so I don't know if you had the opportunity to join. In the past, we had some discussion to the hackathon about this kind of methodology, so here there are several extreme experiments and demonstrations that were presented.

E

Maybe I can also provide some reference to these. Of course,.

B

Okay, thank you.

C

D

um I have two kinds of questions. The one is um whose constraint are you considering here? You mentioned that message, ids and stuff might be troublesome for constrained devices, but at least the client and the servers already deal in those.

D

So I'm wondering whether you're also having constrained pro or whether you're having um core style constraints on the probes and the proxies that that you're, employing.

E

Yeah, let's say the since yeah the the principle. The idea is that, since we are in a constrained environment, so you also, uh if you have to take time, stamps, for example, for each packet is resource consuming. So also in this.

B

E

I have in mind also this operation, while in this way uh it is much more easy because you all, you only have to measure the length of of uh the square. This quest period.

B

E

Just the same motivation, why also quick uh found this proposal quite straightforward and in the end they accepted to to define as a optional. So, of course, there are some advantages to use this.

E

This kind of methodology and.

E

That is, this is one one of the main reasons, because the alternative is that it's much more resource consuming for the nodes, at least for the timestamp handling. If we don't mind about the id, but at least for the time time time.

D

Okay, then I'll continue with another question that is: um could you outline the kind of questions that you expect to answer in the in the end points with this, because I think I'm slowly getting a grasp on on what the what the intermediaries might do, but you're also mentioning that this is useful for the end points and there I'm.

D

Not quite understanding yet which which answers would, for example, a client be able to answer with this, that it is not able to answer without or a server for that matter.

E

Yeah for from on a client side, of course, you can measure the the same thing that you can measure now, but with less resources, because, for example, if you are going to measure the rounded time you can just raise.

D

E

Wait that your packets go back and measure the length of the of the period and the same for packet loss, so you don't need to check each packet.

E

You can just raise a bit weight, for example, 64 packet sieve and just raise the counter handbag. So it's it's quite it's quite.

E

Simpler but another advantage, the main advantage is not only on client side but because you are enabling.

E

On path measurement, that in specific environment in operation, environment, for example, if we think about service provider, it can be useful because uh maybe.

B

You don't manage.

E

The client, if you are a service provider, you cannot manage the client itself, but you manage your network, you have an opt-observer, you may have an a probe, a proxy or where else, and in this way you can check the network conditions.

D

E

D

So we're focusing on on those intermediaries and not the and not the client and not the end points because kind of for them it's just bycatch.

D

What can be measured more easily is: would that be an adequate way of phrasing? It.

E

Yeah, you you the of course, if, if the methodology allow only end-to-end measurement, it's not so so let me pass the term revolutionary right because you are just you are defining something that is already possible, but yeah. The the the added value is that you are enabling on bottoms on path measurement as well. So you are not only simplifying the endpoint measurement, but you are also enabling compat observer.

B

E

For a specific application, if we think about service provider network, uh as this.

B

Is the example that I mentioned before.

E

Or other example, you are, or interconnection also between different networks. You want to segment right, so you can do that with by using these methodologies.

D

I'm not sure I'm I'm fully following the the improvements on the client and server side, but if it's okay for you, let's focus here on the on the on path, part.

E

Yeah the the improvement, the improvement is not so it may be. Maybe we should make some, let's say test to to demonstrate a real improvement, maybe is not so high. I would say I would say that a little improvement there will be because you are now making not measurement for each package, but you can do measurement by by using block of pockets. So if you are taking, I assume that if you are using block of pockets instead of taking time stamp, for example, for each packet, you.

E

We have to demonstrate that maybe some experimentation on the comparison can be can be good in this way, but for core, of course, yeah. You are adding the impact measurement, as you know, as a the main at the value.

D

See seeing concrete improvements, there would definitely help sell the the point for the for the for the end points. um But let's look briefly at the um at the on path case, so I understood from your comments on on clients being mixed and multiple servers being there that you envision that scenarios would be possible where, um where there is a passive probe, listening in on a connection between two proxies and and still get useful information out of that, did I understand that correctly.

E

um Do you mean on between two proxies right.

D

Yeah so yeah kind of generally, you can, if, if you don't contr, the your assumption is or the as long as the assumption is that the clients are not under your control. The best you can hope is that the clients and servers of the endpoints are not under your control. The best you can hope is that the end points implement this in the first place, which will probably be because you're under contract with them that they need to do that, because why would they otherwise.

E

Yeah, correct yeah: you can.

D

E

Do the measurement on proxies as well yeah.

D

E

D

When for proxies, it would boil down to the same questions as before like I, I would expect that yeah.

E

Yeah because yeah yeah yeah yeah, okay,.

D

The proxy kind of the proxy sees the full game and might profit.

E

D

Improvements but nothing more yeah.

E

D

Assume there is this on path probe between an upstream and a downstream proxy. Is that a situation which you expect to support.

E

Yeah, I think I think that, as I said, there is something that we can consider, because you have a bundle of client a bundle, maybe of servers so yeah. You have to check other fields to to do the measurement, but.

D

Which something.

E

D

Which, which fields would you check.

E

For example, you have you have to check the address of the. If you are talking about um a an on path, ob server that can you can check other additional fields to understand, for example, the the flow id to to identify in some way the.

E

The the destination, the source and destination.

D

Okay, so you're expecting that the proxies cooperate by setting a flow id consistently across the uh kind of by by taking the clock.

E

No, I'm not I'm not saying that I'm not I'm just uh think about to. If you we can identify the address of the server or the others of the client or another proposal that I also mentioned is about to measure, uh for example, on the proxy um on two proxy can in some way cooperate to um to uh use the bit for one client at once or for one one server at once.

E

In this way, these simplify a lot the work for the server, so you can in some way, for example, uh move from one client to another, activate one client for measure, so so.

D

Okay, so so, if, if the proxies cooperate in this, is there much difference remaining in um doing the measurements on the proxy kind of? If, if the on network pro relies, and I think it will have to rely on the I don't see so the thing is um because I was asking what fields do you look into?

D

You might be tempted to look into the into the um uri host option, but depending on how that proxy works that may or may not give you accurate information about the upstream server information might be in the uri scheme and answer in the your in the proxy uri option, or it might even be somewhere in the path, because that's really up to the up to the proxy and on the other direction you there is no field that has it now, if you are relying on the proxy to cooperate, for example, by picking out a distinctive client and ratting it out to the server telling that this is a particular client, then yes, this all becomes feasible again, but then I don't quite see.

D

Where is the difference between doing the measurement on the probe, supported by a proxy and doing the measurement on the proxy right away, which has the full information and doesn't have to serialize it over the network?.

E

Yeah, of course, the proxies need to in any in any kind of measurement you uh you need at the end point in some way you need to cooperate, so I assume that the proxy will at least support the options and the the the setting of the of those beats and so on. So that is the uh that is the assumption, and the the value again is um is related to, of course, to the uh to the more easy way to do measurement.

E

So for this I'm quite sure, because I have the let's say the the the statistic from other environment like quick, like tcp. So this is let's say.

E

Let's say something that is feasible and it is also demonstrated in some production network like orange telecom italia. So it is something that it is already but not for co-op. I'm not talking about.

D

I trust that the methodology in general works, but I'm just very doubtful as to whether it makes any sense to do it across proxies at all. I can whether that can be made to work without doing so much work at the proxy that you could just as well. Do the can place the whole probe at the proxy, because.

E

No, I I don't think we you can, you can put the probe at the proxy. Maybe you have your probe in the middle or it is not. This is just a specific example that you are doing, because you can. You can have your probe in indian in the network, so you don't need to put the probe together with proxy yeah.

A

But you can have the proxy.

E

In the middle or between the client and proxy, you can also have another pro bar between the the proxy and the server. You can also have another probe. So it's not it's not mandatory to put together with proxy. So you can no.

D

But it thinks it's not mandatory to put together with proxies, but if it is supposed to work across prop kind of it should be described in which way it is supposed to work across proxies. If the statement is that it works only in absence of proxies, that might that that would be a statement. If the statement is it works with proxies, provided they collaborate in this. In that way, that's another statement, and if the statement is it's, it works with proxies that are just proxies, but do not otherwise collaborate.

D

um That would be a third statement, but yeah either.

E

Of these three I would like to see, and if it's the.

D

Third, then, I think that um it would be tricky to show that it really has these properties.

E

Yeah yeah, I see, I see your pa, maybe we have to in the next version. We have to specify better the. What is the kind of measurement you have. You can do based on situation. So, for example, if you don't have proxies, you have right to end connection and the bottom server can measure round with time loss.

E

If you have proxies yeah. Something like that. I am. I see your point. Okay,.

D

As much as I'm a big fan of ensuring that everything around co-op works through proxies, um it might also be a good time at this, then to evaluate whether you really need it, because getting this to work across proxies um is something where that I expect is, will be relatively tricky, doable but tricky.

D

If you have use cases for it all, please go for it and I'm happy to review it. If you do not, you might just um stick with these options as hop by hop and kind of limit it to that. If you don't have the use cases for it, just so that yeah you don't.

E

D

Work that you don't actually need just because I'm saying here that it needs to work across proxies.

E

Now I'm just saying that since we are proposing the option, so let's discuss how to apply.

B

E

Only so how to see how it can work in all the situations, because since the option is related to co-op protocol, so you will be happy to apply in all the situation and see in each situation how you can apply and how you can use this option.

E

Maybe in some situation it is easy in other situation. It cannot be so feasible, so yeah. Of course I see your point, but.

E

Yeah, I will try to improve in the next revision. I don't know if I I have time to do by monday, but of course, in the next revision I will be.

C

Thank you. That was a great discussion really, and I have also a couple of comments that somehow relate to both comments from uh carsten and christian.

C

um So I just had a quick look at the draft honestly um in the section when you discussed different uh setups, basically section five you're, considering a lot of possible different setups that you kind of mentioned uh in the previous discussion, so with or without proxy, with or without probe, uh using or not using all score, and it can be pretty difficult to follow and understand for each possible setup and combination what that means in terms of limitation, to a certain party interested in doing that performance measurement.

C

So what that part is still going to be able to learn and what not so maybe helps if you categorize, somehow in a relatively straight way, uh the different setups that you can come up with, combining the different variations and discuss the limitations that the different setups result in, I suppose also depending on using one bit or the other or both combined as another dimension.

C

It may help to to support this also with uh examples through scr diagrams. I know it's going to be tricky, but you may start with the most important ones you you believe to be the most important ones. um As a start, this should be partly related with what you discussed at christian. Also.

E

Yeah sure is is uh yeah is what what I remind and what I I also understood from the discussion with chris and yes, we have to define the application scenarios, maybe with subsection, with different setup, precise.

C

E

C

Of setups yeah yeah yeah, the limitations you have for each and.

E

Either a reader can see easily because I I also assume that one is familiar with those techniques. But of course, in this case, since there are different setups, it's better to have in the application scenarios section different subsection. Each one can specify a specific setup and yeah, and this.

B

E

The things are more clear.

E

C

Okay, another comment is more specific on the option you propose. Actually, I was wondering if you can elaborate more on on the fact that um it is defined as part of the cache key could. Could you elaborate on that choice?

C

um I wasn't expecting that. I thought it was going to be not part of the cash key.

C

E

C

Type or non-intentional anyway, yeah.

E

We can I yeah, I don't have an answer, so I mean um we just. We didn't consider that for now. Okay, oh yeah, I understand.

C

um Yeah, you may all- and you may also want to clarify better about how the option is processed uh bioscore, uh because now back to something carlton raised at some point before uh when I was reading the definition of the option and imagining what was going to come, I suspected okay. This option is supposed to be used in an alter, but but then there's no such explicit discussion later on, and that's probably what you want actually uh to be able to make this work uh when you use all score just something to think about.

B

C

Discuss how oscar works with this option.

E

Okay, now this is something yeah I will see. I will also have a look careful to the definition document to the related documents yeah to try all the information.

C

C

Okay, any more comments, questions. What is that I am you mentioned before. You may provide references to resources and possible uh implementation, hackathon activities. uh If so, please feel free to share those references to the main list. It'll be very helpful.

E

Yeah sure sure I am I I have to check with the other people if they are going to have an hackathon to this coming iatf. I will let you know. Of course I will share the information great.

C

Thank you mark, and everyone of course feel free to continue the discussion and provide more comments on the mailing list.

C

Okay, which brings us to the aub part yeah just to mention this- is the last interim meeting before itf 113., where we are going to meet on friday, 25 25 at 10 o'clock vienna time in the morning.

C

So of course we're going to resume a new series of uh interim meetings. uh I was thinking about end of april and, of course, keeping the same cadence to not interfere with the same cadence intended for for sieber.

C

uh So a good day for resuming, I think, would be wednesday uh april 27 and then every other wednesday uh same local time as today, and that would give room for six interim meetings before itf1 14..

C

Would it work for you or would this create any major issue to anyone.

C

No then I'll book, the next series uh I'll be in vienna in presence, so I'm looking forward to meeting uh those of you there otherwise see you online.

C

Thank you for today see you soon.