Internet Engineering Task Force Interim Meetings, 7 Jun 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CORE-20230607-1400

Description

CORE meeting session at IETF
2023/06/07 1400

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

A

A

Because they were proposed after the meeting started and at least I cannot see any more the battle for refreshing on the data tracker.

B

ah This is so stupid. You cannot unmute. Why would you have a model? Dialogue I see them in the data tracker meeting materials yeah. So if I import them, they are in the decks ready to be shared. No, they are yeah. You actually have to click them from the data tracker meeting materials to the uh decks ready to be shared.

A

Yeah there I cannot see any button to force the import again. I used to see it well.

B

There are two circular arrows. You need to press that to refresh remember.

A

That button I cannot see it anymore now strange wow, okay,.

B

So the same browser yeah I was in another meeting I think it was Ace where somebody didn't have the permissions. You should have had yeah.

A

I was about to drag and drop the PDF uh on the upload tab, but.

B

A

B

Okay, um so can you do a screenshot of the slide manager, so we can send them to, of course,.

A

B

Thanks Christian.

A

B

Haven't select.

A

B

So I'll quickly get some coffee.

A

So we're starting a couple of minutes.

A

A

Just say when you think we can start.

B

I think we can start sorry.

C

B

A

And hi everyone uh welcome everyone to the interim meeting of the co-working group, I'm Martha taylorman.

A

And, as usual, a reminder- this is an officiality of meetings, so not well applies, uh get familiar with that. If you're not already, it's not just about APR, it's also an especially about our code of conduct. So please be nice and professional. We want another. uh The link to the notes uh is in the chat. uh I'll try to take notes. Any help is appreciated. Thanks very much Christian and there's I. Guess a request for agenda bashing that we were also discussing before starting uh Uranus to leave at a half past.

A

uh So if it works especially for Marco, uh we may want to swap the the agenda items and start with Oscar capable proxies. uh Does it work for you, Marco yeah,.

D

Yeah! That's all okay! For me,.

A

Thank you that say, then uh it's Richard Stern, yes,.

E

And I will start.

E

E

Thank you, hello, everyone so I'd like to present some recent updates to this draft I was called capable proxies and let's take it away yeah. So he has to recap what this is about. It's about the fact that um you can have a core proxy between a client and server, which sounds straightforward. However, you may want a security association between the client and proxy, for instance, for identifying the client and knowing that it's authorized to use this proxy and a good use case.

E

There can be to utilize oscore between the client and proxy, and this can be used also like. Basically, you can have end-to-end or score between the client and server, and in addition to that, you can have o score between the client and proxy or you can simplable score between the client and proxy and maybe displaying code between the client and server.

E

But the problem is that having um using old score to water proxy is not defined and admitted in all score, because um you know score in the RFC. Only C and S are considered to be the OS core endpoints and, in addition to this, it's also forbidden to double protect a message.

E

So if you would like to have Oscar between client and server and client and proxy meaning, two layers of optical protection between the client and proxy, that is simply not allowed in the Oscar rxc and the work in this draft actually started as an appendix in the Groupon proxy document. And it was agreed during the itf-110 meeting and also during the core interim that took place in June 2021, that it makes sense to split the work from the appendix where it was into this new separate Standalone draft.

E

And okay, what about use cases- and these are a number of use cases- we're also covering the draft- he has to go over them a bit quick. The first one is that you may want to have a code group communication with proxies.

E

So basically, um you have a core group and you're communicating there to a proxy, and what can be important is that the proxy will want to identify the client using a secure Association. So, as the unicast request comes in from the client that- or it can be also protected.

E

Meanwhile, the entire exchange end-to-end from client to servers is predicted with Grupo score. Another example is from the um multicast notifications draft, um where you may want to have a group score different security, and then you use um the client provides the proximities ticket request, which is it has obtained from the server and this provisioning, and you may want to protect using oscore to other use cases.

E

One is regarding lightweight M2M, and it's stated in the light return to M transport, binding specification that you can use our score between the lightweight temtem endpoint and a non lightweight time endpoint via the light to 10 times server. As you can see, they're in the figure.

E

The idea is that the client can interact using all score with the electric term server, but it may also want to connect to an external application server using the proxy and also in this case, it's good to have always score both end term between client and server and between the client and the lightweight MTN server and such because then the lightweight content server can identify the client and it's also normal procedure within light to 10. If you're using all score that decline, then the lighter term server will have on those score security Association.

E

The last use case is one that came from David Navarro, where the it's also based on lightweight M2M, where you use the um you, have the slide to attempt them Gateway and practically in this case, the right to attempting Gateway is acting as a reverse proxy and again. In this case, you may want to have a scoreboard between client and the Gateway acne as a proxy and.

C

E

Between client and server, so what is the contribution of this document? uh It's a twofold update to the oscore RC and the first update being defining the use of all score in a communication like where you have a proxy, and these can be both between An Origin, client or server and the proxy, and also between two proxies. If you have multiple proxies between a client and server, and basically this means that not only Origin, client and servers can be also endpoints, but also intermediate devices.

E

The second update, then, is to explicitly allow this nested oscore protection with return all screen or score. So essentially, the client will first protect using all score end-to-end, client and server, and then it will again protect using all score and this time between the client and proxy and normally you would have at most dual score layers and one end to end and one between each hook in the communication chain. However, it's possible to apply multiple more than two layers of all score, and this is also something we explore in appendix B.

E

Talking about this oscore protected, onion forwarding and the focus on the document is about oscore, but the same information and rules still applies, as is to Google score.

E

So what have we done recently? We presented version 4 and according to him in September last year, and we also submitted version five and six around itf116 another one update we did. There was two explicitly mentioned that the proxy should check whether forwarding a decrypted request is okay, which also, of course, the intent, because the intent is that the proxy should decrypt the oscore request and then use that to identify which client sent it and then understand.

E

If this is acceptable, the forward or not, it was yes, not explicitly stated, but thanks to Christian as input. We have now clarified that, and we've also clarified one corner case where the proxy should not forward a valid request, which can, for instance, happen if, if the request is using this system to multicast Notifications option- and you can see more details in the draft I regarding that so now we have this figure here. So this is basically a flow shot of how?

E

What steps do you take when processing an incoming request, and this is of course we also have in a textual form in the document.

E

um Yes, that's a high level overview and you can see that you enter in this blue box and you start by checking if there are any proxy related options um and you may end up there in the bottom left, acting as a reverse proxy and you, you may also end up acting as a forward proxy and yeah I. Don't think I need to go into like tell you each step in each box. But one thing to note here is this new purple arrow and that's the is forwarding this requests and authorized operation.

E

So that's the explicit check we added based on the feedback from Christian, um and you can see you may end up in a 401 or you may end up in the proxy, consuming the proxy related options and forwarding.

E

um You may also end up. Even if there are no proxy related options at all, um then basically it can either have an Oscar option, uh in which case you decrypt or well. If it doesn't have any Oscar option, you deliberate the application, and the important thing is that this is like an iterative process. So if you have come I guess you can't really see my mouse, unfortunately, but if you have come to the right hand, side and you have decrypted a request.

E

You see this blue line going back to the beginning again, so this is basically like for each old score layer. You go through these steps and if you decrypt one layer when you come back to the blue box again and start over and eventually you will end up either giving this request to the application or it's some kind of error or if you're approxy you forward. It.

E

So other recent updates we did, uh we did some clarifications regarding um protection of Co-op options and because we have this rule set in the document describing how you should protect, um how you should protect options, and we weren't too explicit previously about class, I or class, especially as I options.

E

um So we clarify that a bit and improve those rules on when a option should be protected or not so.

D

Basically, the idea.

E

Is that okay, you have a of course, if toppings Class E, yes, you should protect it, but what? If the opinions class U or I? Well, then we have this defined rule set. That will help you determine if you should protect this option um regardless, if it's class, U or I, the intent is to protect the options as many options as possible.

E

So now we're covering Vector the class I options and some Corner cases and one good Shake. There was the request hash option because that's actually the process as a class I in responses, although it's expected to not be included in the responses and but you can send it on the wire.

E

So, yes, we basically talked about a number of options and and went through the rules to see that the rules are consistent with our intentions and the current rule formulation, you can see in section three one covering three main cases and um we have multiple examples for each case and again, the rationale is to encrypt as many options as possible, and then we can go to this figure that actually shows the rules in a graphical way and again I.

E

Don't have to go each box for you, but basically the overall idea here is that okay I have an outgoing message: it has a co-op option.

E

What how should I process this core option should I protect it or should I not protect it, and then you can follow these flow short to understand whether you should or should not protect the option and again the idea is to protect it if possible, but of course sometimes you can protect it.

E

For instance, if it's I mean if it's needed to actually perform the decryption, such as like the endoc option or the um the oscore option itself, you cannot really protect that for the for the origin server, although I mean the intermediate proxies, may be able to protect anal score option. That is actually not intended for them, and this is the graphical representation. We also have this in text in the draft and.

E

Continuing on some other recent updates, we have a section five now giving guidelines on establishing old school security contexts, so I mean normally this procedure or what we're describing. The draft is agnostic of how you established the your score security context you're using, um but we have some guidelines still in this section, so, for instance, if we're using old score, you may want to run edoc and.

A

E

Advantage of edoc and first execute adequate, the proxy and then with origin server. So you can actually dynamically build your own score context to use with the proxy and server, and we also refer to the optimize workflow and that's detailed in a separate draft where you combine Android message: 3 and the first oscore protected request for group or score you're expected User, Group manager and and that's the clients and servers are expected to already have the score security context present.

E

And one note there is that if you have proxies in the chain, the proxies should not be in the same group as the origin, endpoints for security reasons and further updates, and we will write some of the notation, because when we have this nested protection and multiple layers of oscore, it can be a bit tricky to express that in a in a clear and good way. But we are now improved that so it's easy to see what's actually encrypted and which, of course, security context is used.

E

We also have a an example now with the message flow between um when we're actually taking advantage of the adult, plus Oscar request to optimize request, comparing that to use case, you can see this in appendix A5 and where we're using adock both between the client and proxy and between client and server, of course, through the proxy, and so we wanted to compare here. How many messages does it take if you just use vanilla.

B

E

Many messages does it take if you use the Ado Plus or score optimized workflow and it's actually quite a large Improvement larger than you may expect. So without optimization. It takes 16 messages and if you take advantage of the optimization, you come down to only 10 messages and that's because you can efficiently combine a documentary and the first Osco request and you also get kind of a added benefit.

B

E

This becomes nested.

E

So, to come to some open points, this open Point number one. uh We currently have this appendix B talking about those score protected on your forwarding, uh where the ordering client will first protect the request for the audience server, and then you protect for the last proxy in the chain, then the second from last proxy in the chain Etc until you come to the first proxy. So here we really, you can really Nest uh a number of layers of Oscar protection which could become something similar to Thor, but using old score.

E

So in a high level, the draft itself allows for this use case. um So if you follow these rules for method processing and the rules for how you should protect options, it all works out. Even if you have multiple more than two layers of Oscar protection Christian, you want to do jumping with something.

C

um From my point of view, it would make sense to remove that if we managed to put it into another document that might be, you know, an informative forward reference to work in progress that could use it otherwise yeah having it. There just encourages that it would be implemented based on that without being properly thought through.

E

Yeah and that's exactly the concrete question here is the foundation looks promising but of course, there's more details and, let's say work needed to actually enable like an actual um similar functionality to Tor.

E

um So what we propose is then to Simply, remove appendix B uh from the current draft and instead use that content for a separate experimental draft building on the current one. So we start with appendix people. We have to expand that yes, Kirsten.

B

So, when you say some work is needed, does that means some work is needed on appendix b or some work is needed on the main document to make sure appendix B Works, no.

E

I mean on appendix B, so the main document should allow for this Nest x amount of Oscar layers. So what is needed is work on appendix B to enable this store equivalent, but using all the codes. Yes,.

B

So I think that that uh I mean if people are interested in running an experiment based on appendix B, then I think we could uh do an interesting experimental protocol uh here so that that would be one way to to process appendix um B. But of course that requires people who actually want to participate in in that um experiment. But I think it's really good idea to work a little bit on this appendix B uh to really make sure that we are not missing anything in the main document. That would enable that.

E

Yep that may make sense when we, if we split this out into an experimental draft of course, we can also rethink just to make 100 sure that nothing in the main document is lacking, which we haven't found so far and, like you said, then it would be great if people are interested. Of course we ourselves are interested in and implementing and testing this. But, of course it's interesting if we have more people involved.

E

Great yeah I saw some comments in the chat also there from my schools, yeah uh Aquarion, so open Point number two, and this is about.

E

um While we were working on this revision of the rules for protecting options, it put some light on the RFC 8798, so for the Hope limit option, currently no oscore, processing or class is defined, and so that made us think what that means in practice.

E

And actually, if you check those score of C in section 4.1, it says clearly that options that are unknown or for which Oscar processing is not defined shall be processed as Class E, um meaning that the Hope limit option, since it doesn't have any class defined, should be treated as Class E pioscore, which means that if An Origin client adds such an option to request um yeah, it would have to be encrypted as things or today.

E

But that is not really desirable, because then none of the intermediate proxies would be able to read or take advantage of that option, and you may actually end up having an inner and outer option, because the the inner one is client to server and then the proxy start. Adding outer ones yeah Crystal.

C

Given that the Hop limit is um exposing, the Hop limit would have previous implications, especially because the proxy would otherwise hide the clients. I think it does make sense to treat it as Class E, because it will be Class. E like it will be Class E for for reverse proxy. So for whomever this message is encrypted to it could also be X, so um it could also be added on the outside, but that would probably happen by by proxies that are adding it. So um I.

B

Think that the clients.

C

Setting the option would be a rather rare situation like if they want to trace route through their through their proxies. Otherwise, the first proxy longer path will add that, and that probably makes sense on the when the proxy does this on, whichever layer it can so on like most protected layer, it can so if it's, if the proxy is participating in. If, if there is Nest at all score, then the proxy would add that to its forward proxy um and if the proxy is unprotected, then it adds it out and protected anyway.

C

Of course, it means that that you can that that that the the total limit would be different than the than the set number, but it would still be in the in the right order of magnitude, so something something some of some help limit options would decrease passing through each property, whether that's an inner or another option.

E

C

E

Think what you're saying you need? It probably would be a rare case that it's a client adding the option. uh It's just that it's a bit of a it becomes in a sense not useful, because it will only be yeah between client and server.

E

Yes, let me continue on a bit, because what we actually want to the situation we desire here is that if, uh as we propose, we Define this as class uh the Hope limit options class U um in this draft I'm talking about, um then what would actually happen is for the protection rules that workflow was showing earlier. It would end up such that the option is unprotected end-to-end, but it will be protected for the next proxy.

E

So even if it's class U, if you apply this um the rule set for how to hand the class you and I options, you would actually end up protecting it between the let's say, the the hopes not end-to-end, but between each individual, so I think that would actually might end up in a way like you were Desiring it to end up pretty soon.

E

C

It might make sense to to think through that with examples and.

A

Yeah we're looking at this. We thought you didn't really change much in terms of counting the the hopes still allowed it's more about avoiding having an inner option that doesn't really help or contribute. But it's just uh introducing overhead.

E

Yeah that was intent right and and um if you don't apply the the rule set for option protection, you would end up protecting the option for the next proxy in the chain and the proxies can protect option between each other. But.

B

We can think about.

E

That a bit more and also produce some kind of um examples considering the situation today.

C

E

Considering the situation, if we, if we perform this change,.

E

Yeah I continue the next slide. So summary next steps. uh Just to summarize, this document means an update to those core RFC to define the use of all score in a communication like including a proxy, and we also explicit that meet nasty, logical protection, Oscar and all score, which is explicitly not allowed in the current text of those currency.

E

So what are next steps? Well, we want to submit version 7 before the cutoff. We want to add some of the newly identified use cases, um including the escl score, and this Co-op pm.

E

We also want to cover a bit a high level use of the sheet cat decompression, which is also related to documents RFC 8824 and now this Chic 8824 update document, and this will basically describe like well in a high level. How should you apply the Chic header compression if you're actually doing the nestadoscope protection?

E

uh We want to have some better figures to show this flow of what steps should you take on your process, an incoming request, and we would also like to address the two raised open points.

E

Well, of course, considering the feedback from today and also do some minor editorial fixes and yeah, and we believe that version 7 should be ready for a working group. Adoption call and the core mechanics are stables and and of course, yeah. Any feedback or comments are very much welcome.

E

Yeah, that was it so thank you. Map, Crystal,.

E

I'm not hearing anything if someone's speaking.

A

Your radio is all for Christian, sorry.

C

I hit the wrong view button um you you mentioned. uh You mentioned that there is an added should when it comes to the group, the proxy being part of the group communication, yeah.

E

C

There any worse implications than the obvious of yep that proxy would be in the group without needing to I mean. If, if there is no need to at the proxy area, it will be added, but isn't there any harm that comes of it? If the proxy is part of the group.

E

Yeah to re rethink what we were discussing about that I think the the issue identified was that if the proxy is part of the group, it will have access to the security material uh that actually the server and client are using. So you kind of get a reduced security level due to that yeah.

C

That's the main issue: okay, but it sounded to me like there would be an inverse effect because, of course you only let members into the group that are necessary, but if it so happens that the proxy has a relevant role there.

C

That would be forward.

A

Christian, based also what you wrote in the not I, think you're right. You then be worse than that, and that may be acceptable in a group where I don't know some group members are assumed to work even as proxies.

A

So maybe we can change that should to be just a factual statement and if proxies happen, to be members of that same group, well, they'll be just other group members and enabled down to the same security model using the group.

C

Maybe along the lines of um from just for the purpose of this document, there is no reason to add the proxy to the group.

A

E

Yeah I don't see the these comment, you're talking about I! Guess it's in the minutes, but maybe it's too strictly as to say that the proxy must not be in the same group. We can sign, maybe say what what would they? Okay, like you, said, Christian for this draft. There's no we're not requiring that, uh and maybe we can mention the the security implications of uh if the proxy is a member of the assembly.

A

A

Thank you, yeah.

E

A

Good any more comments or questions on this document.

A

And nothing more in the chat, so I think we're done with this thanks. Richard yep, thank you and next is Marco with Faisal.

D

Okay, uh are you sharing the slides for me or should I you.

A

Can request sharing with.

D

A

A

Okay, this is taking a while.

A

Okay, you're in control.

D

Okay, all right, so uh this is the fossil real transition, timeout and contest on control, uh which has currently the uh the cro2 that was submitted in in March this this year and maybe I give a quick recap of the fossil, because it's it's been a long time before this has been discussed in the in the core working group. So uh the phosphorus is a retransmission timeout and consistent control uh mechanisms for for Co-Op and it tries to find a good middle crown when we are operating in an environment there.

D

There are random losses and of course, congestion may happen. So so it tries to improve the the recovery efficiency in case of random loss, but still handles Consciousness safely, in particular, including the unnecessary re-transmits and.

D

It is uh optional to implement in Co-op it replaces or and if implemented, and then it replaces the default retransmission timeout and consistent control algorithms specified in 7252. uh The father has two ways to calculate RTO, so we call the first one fast RTO, so that is a normal RTO. So it's basically the same as TCP uses so what's specified in RFC 6298.

D

The the round trip time computation and RTO composition. There is a slight modification for the unity Ally session, but that's that's not the big difference, but then we have, you know alternative way to calculate free transmission, timer that that we call slow RTO.

D

So it's measured as a Time elapsed from the original transmission all the way, including all pre-transmissions until the acknowledgment arise. So the picture shows that the original retransmission, if we don't get the acknowledgment, then the retransition timeout expires, and if we still don't have the acknowledgment, then the RTO is packed off. So there is a binary exponential back off, Arthur expires again and we retransmit and so on. Until in this figure we retransmit three times and then finally acknowledgment the rise and the app we measure all these, this time from the original transmission.

D

And then we multiply this by factor of 1.5. So it's a exponential in that sense as well all right and the uh then.

D

We have also a three-state archaeologic each of these three states having their own back-off C area, so the fast State, the first law state and and then the slow state so for the first state, is the normal state that we we are operating.

D

But if there is a no acknowledgment arriving and- and we need to re-transmit then because it's just like the TCP, the the fast RTO and and re-transmit- and we have the normal binary exponential backup, just like TCP does and then for the next message. We move on then to the fast slow state. So this yellow state, because there was free transmission. If there are no retransmissions, then we stay there in the fast uh state and uh in this far slow state.

D

We in order to make the artium mechanism mechanism efficient in in case of random loss or Wireless losses, that this is the typical environment. We first apply the the fast RTO, but if that's not successful, then we apply the slow, RT, also the much longer RTO, and that is to ensure that any unnecessary Transmissions that that are ongoing there. They will kind of go away and then we continue, if still not successful, with this fast RTO.

D

But following the normal binary exponential pack of logic and I said this first law state it is a a single shot state.

D

So if we enter there, the next V, if there are, if the, uh if there are no retransmissions need, let me go back to the first state, but if free Transmissions are needed there in the fast laws there, then it's quite like that there is congestion, and then we move on to the slow state where we always first apply this slow, RT, Auto, so very long RTO to ensure that the the any conscious, Stone and unnecessary Transmissions have time enough to kind of up to leave the network and then, after that, we kind of follow this uh same logic as the DCP, with the binary the the art was calculated in TCP and and with the binary exponential back off okay.

D

So this is the basic, the logic that that how it operates and let's move on then do the uh the currents tattoos. So first of all, the uh the the Professor was first, the trot.

D

As a working group document, it was happening in March, 2000. and 20, and it addressed the uh the feedback from crystal recording the retransmission count option and then in in October 2020, we submitted the tr1. It clarified further. Some of the issues, including the retracement, account current value how it is used.

D

uh We did some editorial changes and the orders considered at that time that we could be pretty close to the uh of uh pretty ready for the uh working request, call and.

E

D

Are for for more reviews, including from the transport area, and we got a Toro review by calls and and and also the dsvr early review by Yoshi and but then the document went to dormant for a long period of time, for due to many reasons, kovit being the one one of those there are no cycles for the the photos to work on it, but we revived it it. This.

D

Spring and unsubmitted in in March the version zero two and the others think that it now address is the points raised by the uh the reviews. So the the the deposited cars race. They were mainly kind of asking for clarification and and use better use of the terminology and and so on, and the dsvr early review also asked us to clarify some points. I I have uh replied to to Yoshi and I. Think yours yeah.

D

We agree with you that that the uh that everything that he commented this is okay, but what he or she wanted us to do is to add more explanation and justification for the um the virtual backup, serious logic. So how?

D

What is the the kind of a logic behind there and and what is the trusted case on why it can be a little slightly more uh aggressive than the TCP RTO mechanisms, and the idea is that we we will submit the the zero three I kind of promise when, but hopefully by the next ITF meeting and we'll we'll add this what what Yoshi asked.

D

But at the same time, of course, we would like to have even more reviews and and feedback, if only possible and- and we hope that the uh that once we are have submitted the the next version, then then we maybe are ready for the working group last call: okay, I guess: that's all I have.

B

So I have two questions. One quick question: I: try to understand the pseudocode in appendix a and I kind of failed, because this is not a uh notation that I'm very familiar with. uh Can you uh write in the document uh what what this is related to this notation that you're using there.

D

For a long time, I have taken a look at the appendix.

D

uh Now, I, don't recall: I should yeah. This is wrote this and uh now I'm. Sorry, I, don't have the answer. Direct answer for you: okay,.

B

D

Good uh elaborate a bit what what was the problem with the circle? Well,.

B

There there is some use of variables uh which suddenly are written in Brackets and so on that I really couldn't quite get from this. Maybe if I haven't spent more time, I would have got this, but maybe just just pointing what what uh ecosystem, what what uh role models were used for writing this story called, alternatively, maybe making it a little bit more python-like or something that that people are used uh to use, might really help.

C

B

Not sure that this is even mentioned in the document, so maybe.

D

B

A little bit of text in the main document that points to this would be useful and maybe a little bit of explanation. Yeah.

D

Yeah yeah: that's that's a good point. Why I haven't thought about that? This was something we added then in in zero one at some late interfaces. If I recall it correctly so uh yeah, but.

B

D

I, don't remember what was the what was the the um for this, but we.

B

D

Course, of course, we have some explanation: there, yeah I.

B

Think the pseudocode is really useful, uh so we don't get the same kind of confusion we had in Cocoa about uh which run of of the mechanism is something going into, uh and so on so having some pseudocode that people can follow, uh it would be really useful. My other question is um given that we have had a two and a half year whole year, um who of the authors, are actually still active on this draft.

D

uh Could you repeat this, who are the uh there.

B

Are four authors on the right.

D

B

And I'm just wondering uh who's going to bring the energy energy to to follow this through to completion.

D

I believe it's pretty much me myself and and you'll pop this Pro, hopefully able to help help a bit so so the uh so we do I expect it to work.

B

On it, so maybe you can discuss with the um other people who are currently listed as uh authors, whether they want to be listed as uh contributors.

B

um So it's clear who actually are the people that we we want to talk to and who should rightly be acknowledged, but are not current authors.

D

uh Right well there. There are, of course, the all the orders have been involved in in the work. Yes back at the time when, when when, when this was developed, so so maybe they they deserve to be, as as the authors, even though they probably are not able to put the Cycles to to finish this up, but the uh unless there is something that I'm missing.

B

Yeah we have this this tension in the IHF, between the concept of, and also that we economics are used to and the concept of an author that that is used in the working group organization according to RFC 2418 um and uh I'm, always having a hard time to position myself on this tension.

B

I just want to point out that after two and a half years, maybe it's time to revisit this, and if your conclusion is no change, that start I'm totally fine with that, but maybe have a look at that who's still around and who should be mentioned as a contributor yeah.

D

Yeah, of course we will. We will be in contact and the great we'll discuss that yeah thanks.

A

C

uh Yeah I have a question that is not directly related to I, don't know whether it's related to the document, um so this is changing things about the retransmission as I understand from the document. It doesn't change, anything about end starts or the number of requests that can be open at the same time.

C

um Is this something that there might be further work on, or is this something that is completely out of that is completely orthogonal through this topic?.

D

uh I think we haven't considered or I think it's it's out of scope of this this uh document, because this this purely touches, the the RTO mechanics, also the the default RTO mechanism in Coop, doesn't have any RTO uh measurement and and rtt and RTO computation.

D

uh And- and it only has has this, uh the uh the the back of logic and this kind of a the password back of logic is indented to kind of a replace if implement it, and it replaces the back of logic and, of course, adds the uh the RTO calculation as specified in this document.

C

A

Thanks any more comments or questions, yeah I have a question suggestion and there's a recently adopted uh documenting core uh Co-op DM.

A

It's basically defining an option for doing performance measurement, including measurement of router time, so I was wondering if uh the use of that method can complement yours to have a more accurate run through time estimation, uh in addition to what you're doing already or if, in your case it hasn't, add anything but still I'd like to understand better and to document, possibly uh even how you can benefit of that, how it relates to phasor.

D

Okay, yeah I, haven't I, haven't been followed. Unfortunately, I haven't been able to follow a core uh for for a while. So so I need to take a look at that and and in order to be able to answer the question so.

A

Yeah and I don't know the answer myself just saying it's something clearly related uh so I think you should say if well, that option is not really helping you, because you have your own way and it's fine and stable for what you want to do or if it helps you as a compliment and then and then well how you can integrate it into your uh your big machine, yeah.

D

Yeah I think I need to take a look at that and and then then see what's what is the if it's something that that possibly could be even integrated or used as a alternative for for all kind of some kind of a modified way way compared to what to document currently specified.

A

It's for sure a possible additional source of information in terms of run through time, yeah.

D

A

Don't know how well it fits is useful for you, but uh I think we should understand uh what the case is here.

D

Yeah, that's a good point, so I I'll take a look at that. Then.

A

B

Yeah I think that that's a good point and it may be interesting to look at the uh the specific configurations and traffic profiles and so on, where this PM document actually adds something to your mechanisms and- and there may be other configurations like like very infrequent uh traffic where, where maybe it doesn't add, very much. So it's maybe useful to think about the the main area of application of of that document.

D

A

I just mentioned the document in the minutes and but for convenience. I can paste it in the chat as well, but hear me percocpm.

A

Okay, thank you. Marco.

A

If there's no more comments or question on fazer I think we came along to the last part of the meeting, be another business and there were two points added by Esco.

B

Gene takes that's.

D

B

um Can I quickly ask Mark you, you said there will be a dash 03 and that maybe will not be next week. But but what's your timeline, you have in mind for that.

D

uh We haven't haven't the the exact timeline, yet it depends on the on the so for sure, not within one one or two weeks, but the but but but maybe in early early July.

B

Oh, that would be great yeah. Thank you.

D

Yeah, hopefully, no no promises, but hopefully.

B

A

Dave, that's for escanal just going to release the slides.

F

Yeah, actually I don't have any slides there. I did put up a link uh to the mail question that came in basically so I thought it was an interesting question to discuss in a meeting to see if we can do anything.

A

F

I, don't know Marco, do we have that mail or that link that you can show it on screen or should I do uh sharing.

A

If you send it for you, please go ahead. Otherwise, I can share.

F

Okay, well maybe you do it because more.

A

F

With it, I always keep looking for the right buttons here. No.

A

F

Goes quicker, interesting question that was posted work in group, so formal request of an informational draft on conditional attributes to be an official IDF standards.

F

um Yeah and then it says: okay, it's used and the lightweight end-to-end protocol.

F

um Yeah for me, first of all, it's maybe not that clear. Maybe the question could be okay. Why would it need to be an official IDF standard if it's informational, you can actually use it also in other standards.

F

So what what would be the benefits um yeah of making it standards track documents, for example, versus an informational document and the other part well Suppose? There is a benefit in that then. Maybe the question is how how would something like that happen so uh yeah if it needs to be kind of re resubmitted and re-reviewed to make it standards track, then there is a chance that uh even the the standard document itself might change because of review Etc, and that also serves no purpose to NF, at least for a standard. That's already using it.

F

I don't want to use that version and I'm, not some different version from the original standard.

F

So I just wondered if anyone had some thoughts about that.

A

So I cannot see miteko right now, I, don't I, don't know. If Carson you want me to say something. First,.

B

Yeah, so we have been delivering backwards and forwards on this. For a while and I think that in the end we said, uh we don't necessarily need it as a standard strike document.

B

We are just documenting one way of doing things so for for us, as the governing robots good enough to have this as an informational document, um but I think the the feedback we get from from Oma here is uh that they are considering this as as a normative reference and for them it would be easier to do that if we process this as a standard strike document. So the main difference is that we are getting uh much more detailed uh and and all right so uh tedious review by the isg.

B

If we go for that and then of course there's a reason for that, so if if we, if we don't want.

C

B

That real user, we go for information if we think it's uh centers, that's Justified and um yeah with the Oma request. I think it is my view would be that we can go for standards track here. But of course that's something that the working group should should decide to do.

F

Yeah, okay, that's clear! Yeah! If you look at the documents, uh it could certainly be a standards track document, so it can just Reserve these particular attributes that he used for the conditional expressions and there's also lots of requirements written there like must and shoot and may Etc, so it could be suitable for that stands. Tracks yeah. If the office of course are willing to put up with this extra review.

A

So we started to open for this at IDF 116. um Also following a comment from the iotd review. I was wondering: why isn't this Thunderstruck and the authors put themselves in a position such that they are agnostic of that they just want to know what to do, and there was someone in the in the room, I think Matthias um for sure they were saying already it'd be better if this is Thunderstruck, but let's check, if there's more support and and more support game, uh for example from MoMA.

A

um So it it's consistent and it makes sense, and the authors are fine with that by the way they just wanted to have a clear, Direction. Okay, so we can reconfirm at the next meeting uh but seems to me we won't do it.

F

Yeah: okay yeah to me that makes sense.

A

Yeah- and there is already an in fact, normative reference to this document in the light to 10 from standard.

D

A

But thanks for bringing this up again, this is the kinds of discussions we wanted to have. In fact,.

C

A

On the next question, no.

F

Actually somebody um shoots somebody from the chairs and provide an answer to this email or or something it could be very short like okay, we will consider it or or a summary of what we have just discussed I don't mind, but it would be good to get at least one response to it.

A

Yes, we can thank first of all and point to the notes of this mean of this meeting. Yeah. Okay, does it work for you, Kirsten.

B

Sorry, I I dropped out for for a second. What is okay for.

A

B

A

We reply to Homa thinking their feedback and pointing to the notes of this meeting and they are ready. Yes, okay,.

B

A

A

Okay, then there was one more point.

F

Yep yep, that's also one that I added there so and it was this- was only group comb base drafts so now has been waiting for a while. um So just wondering: okay, what is now the next step? What what do we need to do, or do we have an uh an idea of when this is going to move forward?.

F

Or maybe something should be updated first and because some some time already passed, so you can also uh apply updates where needed, but but so far I didn't hear anything.

A

As far as I can remember, we are waiting for a follow-up from Kirsten on the way we answer. This working group plus call review and we should be receiving also additional editorial comments from John yeah.

B

Yeah yeah, so this is something that the shepherd who happens to be me uh needs to do, and- and thank you for nagging the school. This is where he's after me and it needs to go forward.

A

An additional related thing I can point to um in his recent follow-up comments to a group of score. um Christian pointed out that uh the the sort of non-traditional responses that we are specifically using um in group score in a sense can can be seen and they are as an example of the non-traditional responses defined in the core responses document and it's good to give a reference to that.

A

uh Yes, um after some discussion and discussion also with the group of scoroters, it may be even better to put that reference in group comb this actually because those uh sort of non-traditional responses are in fact, defining group comb base group of score is just defining how to protect those.

B

Yeah, that's an interesting question. So I I wrote this non-traditional responses document just to make sure that we have a place where we collect what we have discussed about non-traditional responses. Now. Is this useful as a document on its own, or is it just something that that served its purpose by by getting in traditional responses into various documents? So if it's the former uh yeah, let's, let's finish it.

A

I I think it's useful. It's defining a generic concept of which we have different incarnations in different situations.

A

um My point about this was just Christians, suggesting to to give a pointer to the documenting group of score um yeah. We just talked that pointer is more useful to be included in Groupon, because that's where uh that incarnation of non-traditional responses is defined yeah. So that may be one little thing we may want to add.

B

In Google, this.

A

In fact, just an informational reference to corresponses.

F

A

Good to know yeah, it should be somewhere in the section that says that multiple responses from the same server can come to the same group request.

F

Okay, yeah that sounds useful to uh reference that as well then.

A

A

What do you think Christian by the way, because the suggestion came from you? First of all,.

C

Yeah so I'm I'm, I'm, I'm I'm at this, so I I made the suggestion talking to this, but at the same time um the the core responses probably needs a bit work and might also still get changes in the terminology. So it's a bit hard to use from from documents like this um at the moment.

A

uh We we don't even need, we don't even have to mention the the words non-traditional responses.

C

A

We can just say that.

C

A

Right we are introducing. This is just an example of what is more broadly defined in corresponses. That's it with no names at.

C

Least, at least we we needed for for the processing of group requests. Yes, um so yeah.

B

Maybe that's a good indication to.

C

Put a bit more effort into getting getting core responses, um progressed.

B

So can, can you send me a little to-do list of things that need to be fixed.

A

Well, uh group on this was mostly for the authors, uh for you, Carson I think it was mostly following up on the revision that addressed your working group plus called comments.

B

Yeah, that was a pretty extensive uh set of comments. So it's a.

A

B

Extensive set to check no I was specifically asking about Reviving, non-traditional responses and and putting in the information we have gathered since we we wrote this I, don't know how. Many years ago,.

A

C

Non-Traditional responses is doing a bit of two things at the same time, it's both introducing ways of, or it's describing ways of doing them, but it's also describing the the concept in general, um I think I'm, so I'm I'm not completely sure we have a rough working group consensus yet on this concept being really the same thing, whether it's group, whether it's observation responses, whether it's multicast response, Etc I, would very much like to to get gather a bit more feedback from the working group, whether that's really the direction to go to do this unification I'm very much convinced that it is the right way, but I'm I'm a bit in the void here.

B

Okay, that's interesting.

B

A

The problem of.

B

Course was to to Simply uh point out that there is a similarity here and, of course we can. Our perceptions can differ about the degree of that similarity. uh So maybe this document doesn't have to to present the conclusion that they are similar but just needs to contain the the tonology and discussion I.

C

Think that the tricky part is that of core processing of non-traditional responses um will not be will will cannot work from just description of similarities, because then we wind up in the situation where we still have to normatively specify the handling each time, but also the first time the Osco processing of some non-traditional response that is not observed is described.

C

At that time we will need complete something more concrete than just observing similarities, but then we will need to say that any case where there, where the client processes, multiple responses, can be handled like this or that or there are these in those distinctions and criteria, but still it needs something solid.

B

Okay, I'm not sure whether I'm hearing you say that this should be a normative document.

B

C

B

Oh okay, that's very different from what I had in mind for it.

B

Okay, I think that that's an interesting point we can pick up on on the mailing list. I haven't looked at this document for for half a decade, so um let's see what we find.

A

So, irrespective of this, an action for group comb, this is to add an informative reference to corresponses.

A

Right as the document where the general concept comes from, of which we are producing an instance in group on this.

A

And that should be about a comment that came from Christian recently.

A

I'm also typing in the notes.

A

A

Thanks a lot: let's go for raising these.

F

A

Thanks any more any other business to discuss today,.

A

If not thanks a lot for your time, that was a good meeting. Talk to you in two weeks, yeah see.

F

A

Time, thank you. Thank.

B

A