**Session Date/Time:** 24 Jul 2026 07:00

[00:00:08] **Brian Trammell**: We wanted the second one, I think. I think it should have supersede we'll figure it out. Like, go go go to the one that doesn't say scone when he wants to present. Wow. This mic is super hot. Good morning, everyone. It's nine o something on idea Friday. Hope you all have had an excellent week. We are this is Scone, secure communication on network elements. Standard. Oh, yeah. Right. Yeah. I know. We the s does not stand for security. So yeah. Are we on can you go on do I have the do I actually have the slide? Okay. Yes. So if you have made it to Friday, if you are on a one day pass and this is your first day your first IETF, Please read this slide very quickly. Scan the QR code to understand more. This is an IETF working group meeting. There is a code of conduct. There are IPR policies for contributions at the microphone on the list in the chat, etcetera, etcetera. Make sure you sign in using the Meet Echo tool and use Meet Echo to join the mic queue. If you don't know what that is, the microphones have QR codes on them. For remote participants, please make sure audio and video are off unless you're for sharing or presenting during a session. Do we have any remote chairs today? No. We're both here. Excellent. So MeetEcker q control, chat, and Java available for use. Note taking, could we get somebody to do notes in so major points only in the in the hedge doc? For what it's worth, Ecker has an excellent tool that will take the audio transcript of this and turn it into a into a set of minutes. It's quite good, but as a previous session that I chaired, it was very useful to have sort of a second set of notes for for verification and for minor corrections. Let's see. Who is not presenting today that is looking very intently at their laptop, Mark Marcus? Thanks. So since Shenzhen, we had we scheduled two well, we scheduled one, and we have scheduled a second one. And we did not do the second one because we were having sort of, like, good asynchronous communication about the draft interims. And we've got some continuing experimentation and preinterop. Actually, now that I've, like, picked on you once, Marcus, do you wanna talk about what, if anything, happened at the interop this time at a microphone? I mean, you can also just sort of, like, shake your head and say nothing interesting. We had a smaller table because the hackathon was in a smaller room relative to the number of people. So

[00:03:28] **Marcus Ihlar**: Yeah. We did we did some stuff. Been playing with some interop with some applications in myself, which I cannot exactly disclose right now. But, also, we did some experimentation with, SCONE advice over, emulated satellite links, prompting some of the concerns that Gorry have been expressing recently about interesting relations between strangely impaired links and and throughput advice and such. Looking into various ways of, yeah, trying to enable, yeah, open source ABR clients to to to use SCONE advice as well. So there are some researchers from from Aberdeen, etcetera, that are doing this. So no new exciting interop results to announce, but some interesting work going on.

[00:04:19] **Brian Trammell**: Excellent. So those things that you can't talk about, are those things that you would be able to talk about on the list once you can talk about them?

[00:04:25] **Marcus Ihlar**: Yeah. Sure.

[00:04:25] **Brian Trammell**: Okay. Cool. So please bring that to the list when that is something that you can talk about. Thank you very much. So document status. So this should be since January. Right? Like, so no major changes. We've got the SCONE protocol, which thank you to the authors, editors of that for resurrecting that. If you recall, we did a working group last call on it and decided to park it. And then in Shenzhen, I think we decided to unpark it and go ahead and click the button on it if there are no objections at this meeting. There has been significant progress on the application applicability and manageability draft, which we would very much like to get to the point where we can also do the working group last call beginning at this meeting and get that done as well. We got good yeah. So good ops to your input. So, like, we'll be going over that. Part of the the rest of the agenda today will be discussing the future of the working group. Right? Like, so we had our two big deliverables. It looks like we're basically done with them. There are a few other potentially interesting or adjacent things that might be useful to do in this working group or in other working groups. We will have a discussion about where to send those. There was also from Wes, and there were two were two messages to the list about, hey. There's other interesting work that we might want to do here since we have the people assembled, and we will also represent those. I don't think I don't know that they're remote or not, but we'll, you know, look at those emails from the chair and bring those from and bring those into the discussion as well. And then the the you know, everything will be followed up on the list afterward. I think some people, including me, are disappearing off into holidays for a little while. We'll pick that back up after summer holidays and sort of figure out what we wanna do, whether we wanna go Gorry to, recharter us or shut us down. So with that, I think I have talked enough. So interop scone protocol completion discussion. I don't think we have slides for this. Is there anything to say beyond what I've said? And I'm looking at Martin.

[00:06:50] **Martin Thomson**: Thankfully, I think we don't have anything to to really add.

[00:06:53] **Brian Trammell**: The Yeah.

[00:06:54] **Martin Thomson**: There has been a a few small editorial things that have come out through the the work that Sanjay and Zahid and others have been doing, but the document is substantially the same as

[00:07:06] **Brian Trammell**: Okay.

[00:07:06] **Martin Thomson**: What it was last time. Yep. Implementations have moved on, and we're getting a little bit more experience with using it. So I I think we're ready.

[00:07:15] **Brian Trammell**: You yeah. As as an editor in representing the editors, would you have any objection to me just clicking the button?

[00:07:22] **Martin Thomson**: I would like you to. Yeah. Okay. Great. Cool. That's that's I

[00:07:25] **Zahid Sarker**: don't know

[00:07:25] **Martin Thomson**: if others disagree, but I Are are there any number?

[00:07:29] **Brian Trammell**: I mean, we've already had the working group last call. Right? Like, so if there's anyone if there's anyone in the room who, like, thinks that that's premature I'm looking at my AD too because he's the one who asked to do it. No. You you can just say, no. Don't worry about it. It's fine.

[00:07:46] **Sanjay Mishra**: I don't wanna make you get up.

[00:07:48] **Gorry Fairhurst**: Look around, but look on the list. Look around, but look on the list. Yeah. Find out if they think it's ready.

[00:07:54] **Brian Trammell**: Yep. Okay. Cool. Good. I will send that email now and click the button afterward. Okay. With that, I think we're well ahead of time, and we can go ahead. I'll put it on the list and wait a couple of days. It's fine. Like, I'm still I'm I'm still around for a couple more days. So cool. Then we can go directly to applicability and manageability. So, Sanjay, we we have, like, two sets of slides. You want the latest ones that you sent in yeah. In yeah. So that PPTX to PDF seems to have worked. Well, you know you know, I looked at a few of them, and they're not completely

[00:08:49] **Zahid Sarker**: It's

[00:08:54] **Brian Trammell**: the it's

[00:08:55] **Sanjay Mishra**: I just sent him the slides. So let him use that one the ones I sent. But they're

[00:08:59] **Brian Trammell**: in So I have some from you, and I have some just now from him. That. Yeah. There's yeah. Okay.

[00:09:03] **Sanjay Mishra**: Yeah. Just use the one. Okay. Just use the one I sent.

[00:09:06] **Brian Trammell**: Okay. Good. Alright.

[00:09:10] **Sanjay Mishra**: Good morning, everybody. Happy Friday. My name is Sanjay Mishra, and just wanna give you an update on the applicability and manageability draft. My coauthors are listed here. Okay. A lot of text on all my slides, so I'm I'll try to say a few words. So from the last meeting from version one to version two, which is now published, There are just like significant amount of changes. We had 22 issues, but actually those 22 were really very qualitative issues that were raised by a lot of you in this room. So thank you for that, and you really helped shape the document. So I think if you look at the key changes before I touch the rest of the bullets there, it's in one word, if I can say, it's it's a dramatic rewrite of the entire document is what it is in in two. One was so just to call out a few things out of the document. One one was there was a lot of conversation about that the document should also have something as operational considerations and that was also raised as an issue. So and there was debate about where that should go. Should that be a standalone section at the bottom? But the challenge was that if you do that, then the rest of the document actually prior to the bottom part talks everything about operational details. So I think that the compromise that at least the editors ended up with was that why don't we place it at the top of the main body and in the title as well, and then introduce a short section on operational considerations so that the rest of the document then is actually dealing with that. So that's kind of where we ended up shaping the document, and that's where the operational considerations is now. The and then other changes, the introduction was restructured and actually there were a couple of other things that came out of the introduction section and we moved those as new sections of their own. The per flow signaling was moved into section three and then the two other sections added. There was also a issue on determining throughput constraints and how you determine that. That was an issue that was raised, so we added up added a new section there. And there were several comments on the ECN and L4S interworking, and there still are comments on ECN and L4S which I'll touch later on. But in the current version, the section was rewritten with distinction of proactive versus reactive. And that the SCONE signal is is the limit before the enforcement, whereas ECN and L4S are enforcers at the limit. And not to go into the details, we can have open table open discussions on open discussion on that as we move forward. Then the dynamic updates, it was a very small section, but I got some really, really good feedback over several weeks before we agreed on the the final text. And it's it's mostly scoped to the network element side behavior. And it's it's clearly anchored to section 9.2 of the protocol stack. It kinda goes well, think, hand in hand with the section 9.2. And then there's a lot of clarifications throughout all these different sections. So the the zero two is really a a new defined pretty much a new document from zero one. So once we publish zero two, the chairs actually sent it out for an OpsDir review and Joe Clark came back with some issues. He reviewed it, basically minor, but really good good comments. So there are three comments that we got from him and there are two words. So we have submit one PR and one is the editors themselves did some fixing on the cross reference. So one of Joe's PR and one by the editor, so we submitted those already merged because they were just fixing some typos and things like that and references. And then there are two PR that that are open, ready to merge from comments from Joe. And outside of that, in version two, so taking two of OpsDir comment and one Mirja's mask PR, and then one from Christian on the network load. So we have those four issues that are still open. And then we got a couple more issues from Goril overnight. So we've got maybe about six issues or so that are still now open against version two. So this slide is just kinda recapping just to keep it clean what review and feedback we we got from ops there. So slide four actually is just the editors fixing the things that they broke in previous section. So we didn't have the the the the cross references that can be that you can link and use as cross reference, so we fixed those. The slide five and six is combined. Slide five just lists the issue. Slide five actually is is just missing references on two places where where we reference to sixty seven seconds and there was no context clear to the reader as to where the sixty seven second comes from and why, so we added the reference back to the protocol document. So that one is actually merged already and also the broken references. So those two four and fives. What I have in slides four and five are done. The the issue six and seven is really one issue. Slide six just calls the issue and slide seven shows the proposed text and then slide eight that I have shows both the issue and and the proposed text in in a single slide. So I'll go through that and then I'll cover other open CRs. Open PRs issues. So this one is the first one that we fixed. This basically made sure that we moved this section inside the reference so that it's clickable. And there were several instances of that, so we fixed in all of those sections. And this is the first of the three issues from Joe. And his first one was just a simple one that said section 3.4 and section 3.10, we should give a reference back to the six sec sixty seven second window. So as you see here in the text, have added that. And this was simple enough so we didn't really needed to do anything more than merging it. And then this one is very good comment, and the the gist of it is that he wanted Joe was asking a question that how how does an operator determine that the the endpoint is not taking the advice? Is it because they never received it or there was a failure? So that's a very good comment. And so that that's sort of verbatim what he wrote. And this is the response that we have added in p r 55. And the the text that you see in red were a couple of comments that Martin Thompson added on top of that. So this this is the whole text. I won't read it to you, but have a look at it. And if you feel if you have any other comments to make to it, please go ahead and make those comments or edits directly into the PR. And the next issue, fifth forty nine, he wanted to Joe had said that once you have something that way, there should be a reference to check whether or not the before you before you before the operator take an action that basically says, okay, this client for whatever reason is not SCON compliant, so I can enforce other methods that the operator may have to for that particular flow to maintain within the within the norms of what they would consider an acceptable rate. So the text that we added in between that before you apply penalties, operator can use diagnostic approach that is described in the previous section that I just displayed to confirm that a sustained violation reflects application noncompliance rather than a delivery failure and so on. So that is what you see in in the new courier is the text that we added into the existing section there. So this one is open, and we have someone, Lars, on the queue.

[00:18:30] **Lars Eggert**: Hey, Lars. Got Mozilla. So I'm a bit unhappy about this adversarial language here talking about noncompliance and penalties. And I I thought, like, Scone was supposed to, like, be help the the applications helping the network, like, do the best thing. And and this now very much looks again like, you know, we're gonna, you know, box you in the application. And if you don't do what we told you to do, we're gonna, like, penalize you, maybe more so than we would have otherwise just done for best effort. And I'm really sort of not happy with that sort of language. Thank you.

[00:19:04] **Sanjay Mishra**: Okay. Good point. So we can revisit this and try to, you know, soften the language and in in a way that is appropriate as well to the context and have you review it.

[00:19:22] **Brian Trammell**: Can can you file an issue? Or would you like me to file an issue based on that?

[00:19:26] **Lars Eggert**: I can

[00:19:27] **Martin Thomson**: put a

[00:19:27] **Marcus Ihlar**: comment on

[00:19:27] **Lars Eggert**: that, Marcus.

[00:19:28] **Brian Trammell**: Okay. Please do. Yes.

[00:19:30] **Sanjay Mishra**: Thank you. That's great.

[00:19:32] **Zahid Sarker**: So Sanjay, for this ops Doctor review and you already submitted the PR, I want to know whether you get this confirmation from Joe, whether he's happy with this kind of

[00:19:45] **Sanjay Mishra**: Yes. Yes. In fact, Joe did send an email and he he was happy with the changes. And the previous one, this one was also reviewed. Let me go back. So Martin reviewed this also and he had a couple of corrections as as I am showing here. So but, you know, this is approved but certainly it's not merged so if anyone wants to review it, that would be wonderful. But Joe was okay with that. Zahid?

[00:20:22] **Zahid Sarker**: Yeah. So I I'm just going to respond to Lars about it. Yeah. I actually also I I agree with you. It's a bit more like but this is a result. We didn't have this kind of sentences before. But this is a result of people asking, like, okay, if detection doesn't happen, what what can operators can do and all this thing? So if you if you really like to say something, then this kind of sentences come up. So one option is to completely remove them. Just write that like a operators who just deploy purely advisory. That's it. So because there are some like some comments we got is like what the operators can do, should do. And there, basically, these kind of sentences came up.

[00:21:07] **Stuart Cheshire**: I I don't know.

[00:21:09] **Lars Eggert**: Lars, I got Mazzella. I mean, just because you got a review doesn't mean you need to follow it. Like like you know? So and and one option here is to do, like, nothing or at least nothing different than what you do for other traffic that isn't Scone. Right? Because I think the the other danger here is if you are treating SCONE traffic, like, non like, traffic that has indicated that it's capable of speaking SCONE, then for whatever reason doesn't. If you treat that differently from best effort traffic, I think you might just open yourself up to some hazards in terms of regulatory things, right, where you're segregating the traffic and you're penalizing it more than best effort. I don't think that works in all regulations equally equally well. Yeah.

[00:21:57] **Zahid Sarker**: I I yeah. That's true. But for for for example, from my point of view, SCONE traffic is different. And we will need don't need to perhaps tell it like it's different, but the network operators will have to look into SCONE packet, have to do something, put signals. So it's actually not the best effort treatment that we do. But it's a bit it's a it's a class of best effort perhaps. So we don't need to write all those things here. I agree with that. But this is not true. Like, I can just at the upper upper network, I can just treat SCONE traffic as the best effort because best effort, I might not touch even any flow. I don't even maintain parts of flow state. But for Scone, we need to do something. But I'm just saying, like, we cannot do this, but I don't I agree with, like, we don't need to be so detailed in this in in in the in the document about it.

[00:22:48] **Gorry Fairhurst**: Yeah. Yeah. Keep going.

[00:22:49] **Lars Eggert**: I was just gonna get a follow-up. So, I mean, there's already gonna be a whole lot of traffic that isn't Scone. Yep. Right? And so you already need to do something for that. And I think what I'm saying is if you detect that that there's there's a flow that signals SCONE but somehow isn't doing, you just treat it like it didn't ask for SCONE. I think that's the simplest thing because doing anything different, I think, is a slippery slope.

[00:23:13] **Zahid Sarker**: No. That's fine. So that's that's fine. And this is what's gonna happen. And if you put it more worse, this this is how it

[00:23:21] **Christian Huitema**: looks like.

[00:23:22] **Gorry Fairhurst**: This is

[00:23:23] **Martin Duke**: this is what is done to the to the.

[00:23:30] **Gorry Fairhurst**: Gory Fairhurst individual. That was good. I like that discussion, but I have a different take. So have a think about what are my different takes. I read this text and I thought, yeah, that is actually really helpful in the case I'm looking up. Then Lars said what he said, which made me feel that what I didn't see was the thing I now see very clearly, which is I don't like many of the words here. I do like the paragraph. I do like the idea of providing some advice because I'm thinking about using Scone in allocated capacity, which is allocated for a particular user where the headroom is small and, you know, fitting in the Scone advice is actually something that is going to be monitored. So I I think monitoring's okay. I don't like violation. I don't like conformance. I don't because it's advice, and I think you can monitor this and you can see the effect, and you might want to react to protect the network. But these words, I now find very scary suddenly. Although, I really love the paragraph, and I love this section, actually. So I I really hate the words.

[00:24:46] **Brian Trammell**: So so for the shorter for the notes, same paragraph, different words. Okay. Cool.

[00:24:52] **Marcus Ihlar**: Yeah. That that that probably makes sense. I kind of agree with all that's been said here. One important thing that you might do differently when you when you see a scone package is that you might actually, for this flow, try to not do other enforcements. So that is a different you're doing. Right? And and you might switch back to doing the enforcements you do for everything else. And this is what we need to capture here. Not that we're, like, you know, trying to create a new policy and you're brief, you know, some so I agree fully with Lars. We just need to wordsmith too. And also, maybe

[00:25:24] **Brian Trammell**: we should take a look

[00:25:25] **Marcus Ihlar**: at this because if you see the review here, somebody comes from from the outside. They read this, and they talk a lot about words like misbehaving applications, etcetera, etcetera. Maybe that's an indication that we need to be more clear in our text what this whole thing does.

[00:25:41] **Mirja Kühlewind**: I only agree to this last point. I think the issue is wrong. The only issue we need to address here is that somebody misunderstood the document and came up this issue. Because, like, the question if you want to enforce a certain rate limit is independent from providing the advice. And you really don't need to understand if, like, the advice is not adhered, why. It doesn't matter. Either your network, you know, wants to enforce a limit and you do it. If it's not there, it doesn't really matter if they understand SCONE or if, like, the SCONE packet got lost or if they decided to not adhere to the signal. If your network needs the enforcement, you have to do it. If it doesn't need the enforcement, you just don't do it.

[00:26:28] **Gorry Fairhurst**: Responding to Mirja, just because it seems like two people discussing here. But no, because when I do this, I don't do that enforcement. I turn on an SLA enforcer off, and I set an envelope over sixty seven seconds, and I don't do any enforcement. And then this kind of reverse this.

[00:26:44] **Mirja Kühlewind**: There's three options here. One is you send a scone signal and never enforce. Right? That's the easy one. The other one is you send a scone signal and you anyway enforce, which means, like, if the endpoint stays below the enforcement, nothing will happen. And the third one is an optimization. It's like I detect scone and I disable my enforcement because I want to save some resources. And then if I, at some point, find that I need to enable it again, I do that. But it's actually independent of scone, kind of.

[00:27:12] **Gorry Fairhurst**: Except that that was the whole reason I wanted to do Skone in the first place. The third one the third one was the one I wanted. I

[00:27:23] **Mirja Kühlewind**: I hope that operators will do that because it hopefully, you know, makes their life better, but, you know, it's an operator decision to do it one or the other way.

[00:27:32] **Brian Trammell**: Can everyone who is a part of that please jump into Hedgehog and correct Marcus's and my notes on it? And then go and throw some comments on the issue. Where are we in so you were in Christian's time. Christian. Good. Go. I'll manage the queue.

[00:27:51] **Christian Huitema**: Good night, everybody. I think that the way the way we I would summarize that is that Scone is not RSVP. As in, it's not about reserving resource or anything like that. And and it should be I think that in the app man, we should be very clear that what it is about is not about giving privilege to any particular flow. And that the the point we're making was our flow signal or something signals calls or not shall not change the way that flow is managing the network, period.

[00:28:33] **Zahid Sarker**: That's it. Oh,

[00:28:37] **Brian Trammell**: so me. I was listening to the conversation about words that we don't like, and I came up with words that we might like a little bit better in terms of, like, you know, compliant or noncompliant. What you're really talking about is is the SCONE flow reactive or nonreactive to the Scone signal? Right? Like,

[00:28:54] **Christian Huitema**: No. No. Yes. No. No. No. And no. The the fact that it reacts is its own choice. I mean, the the the basic idea that scone shall not change the state of the network.

[00:29:08] **Brian Trammell**: Right. Well, I'm talking about the endpoint behavior. Right? Like, if you get a scone signal, do you react to it or not? Like, that's the that's

[00:29:15] **Christian Huitema**: how you matter for the network. So so on the app, it should be very clear.

[00:29:19] **Brian Trammell**: Okay. Yep. Nope. Okay. Yep. Got it. Yep.

[00:29:22] **Christian Huitema**: If if you don't follow the advice, your application's gonna suck. Fine. That's your choice.

[00:29:29] **Mirja Kühlewind**: And if you don't follow the advice, it actually doesn't matter if you didn't follow it because you got this go on advice and didn't like it, or for some other reason, it really doesn't matter.

[00:29:41] **Martin Thomson**: I know that you all like arguing about these things, but I put some suggestions on the pull request while you're all arguing, and I suggest that we move on.

[00:29:50] **Brian Trammell**: Yes.

[00:29:51] **Martin Thomson**: Because we are just violently agreeing, I think. No. Oh, come on.

[00:29:58] **Martin Duke**: I'm I'm out.

[00:30:01] **Gorry Fairhurst**: What's We're very nearly violently agreeing. But I think there is still a discussion about whether the network changes its behavior because it's Dundscon. Mira, I like, let's check. Mira, I think, says you you can have an envelope and you still build the network with that envelope. And scone just simply tells you how you built your network. Is that right? You you're not going to disable functionality in the network because you're enabling scone. You may or you may not. So there are two options here, and I think that's where we kind of define it a little bit. And maybe the text just really caused us to argue. But I think we probably have two, at least, flavors, maybe three. And, Mira, come talk to me. I'd like to get

[00:30:51] **Sanjay Mishra**: this finished.

[00:30:52] **Brian Trammell**: So I would I would I would like to capture this discussion on the PR, please.

[00:30:57] **Christian Huitema**: Yeah. Yeah.

[00:30:59] **Mirja Kühlewind**: Or it might be a separate issue. And I thought we had one, like actually describing these three options, I think that's very, very helpful for the document. And I thought we provide a text, maybe we didn't.

[00:31:10] **Brian Trammell**: Okay. Go go check. Yes.

[00:31:15] **Participant**: I just wanted to point out that applications, for example, browsers, would signal that they support SCONE, but at the point I mean, when they open a new connection, they might they could signal that they support SCONE, but they don't actually know if their flow is capable of adopting SCONE. So I think we should capture that reality and stated say that upfront so that people would understand that the clients would behave that way. Because that's the background for all these discussions. Thank you.

[00:31:49] **Brian Trammell**: Okay. Cool. Tim? Do we have a Tim?

[00:31:56] **Mirja Kühlewind**: One quick comment. I'm not sure any of this text is needed, but maybe we can wordsmith it or not, whatever. But what might be needed is to look at the rest of the document to understand why an issue like this was raised. And if we are saying something wrong in the rest of the document, that gives the wrong impression.

[00:32:12] **Brian Trammell**: What's wrong with the mic? Oh. Do we so queue management, Tim was before you. I don't see Tim, though. So alright. Going once, going twice. Tim, if you would like to speak, please reenter the queue. Queue is cleared. So we're gonna discuss this on the PR. Good. Moving on.

[00:32:42] **Sanjay Mishra**: Alright. Let's see. Open issues. So so the the ones that we were just looking at were from Joe and other issues that are outside of the ops door. This issue was raised by Christian, network elements dealing with overload. And so I've just put a a bit of a summary of what the points he raised. And, yeah, I'm not gonna read all of this, but please see the issue. And the proposed text is here, and Christian approved it. Marcus also reviewed it, and his review is reflected here with his review and his approval. But I invite, you know, folks here that are interested to have a look at at this section as well and see if there's any other additional comments. I'm just going to move on to the next one unless there's anyone has anything.

[00:33:52] **Martin Thomson**: Yeah.

[00:33:56] **Brian Trammell**: Okay. This one is This is issue number 20 p r 37 for those of you who are not capable of passing the eye test. So 20 p r 37.

[00:34:08] **Sanjay Mishra**: This is we didn't convert to the PDF, and this PowerPoint is is not showing up nicely on the screen here. So so Standards. This this issue has been out there for a while, and there's we had see if I can move on to the next one here. This is trying to capture the discussion on the same topic back at ITF one twenty five. A number of folks had commented on this one. So there's some agreement. There's some disagreement essentially. A lot of folks have, you know, said the things that, you know, is captured here. Mask proxies are standard SCORN network elements. So there was some strong agreement within the working group that that you know, including Lucas that SCONE architecture does support mask, so that's probably fine to include this. And there was some pushback on the MASQUE capsule, but not on this particular issue. Then had some comments as well that adding of you gotta keep in mind to avoid burden on the clients of having to deal with different ways for doing the not doing the same thing, mass capsule versus cone packet. So the the conclusion is that it is still open, and there's I'm gonna show you the text that is that's out there right now. This is probably not reflecting the the additional changes that I see that Anoop has made suggested, but more or less, this is where the text is. And not to put Miriam's spot, but, you know, if you have any additional comments and thoughts, you know, that people may have shared with you during this week on this particular topic because I'd like to see if we can come to some kind of conclusion on where we would need to go with this one.

[00:36:14] **Mirja Kühlewind**: Yeah. My question really is so I think the text a couple of people reviewed it and I made some edits and maybe there's still something outstanding, but the text in itself is, like, you know, reasonably fine. I also wanna say that, like, the issue was about MASQUE, but the text is supposed to be really more about tunnels in general, where, like, MASQUE is the one tunnel that we have that operate on quick. So it's, like, the most interesting case here. But I still don't like, people said, they people reviewed the text, they seem to be fine with the text, but then they also comment on the issue that, you know, maybe that's not needed or whatever. So I'm not sure if we want to merge the text at all, if we want to merge, like, half of the text or whatever. That's kind of the main question I have rather than any wordsmithing.

[00:37:00] **Brian Trammell**: Merge every other word. Yeah. Alright. Does anyone wanna discuss that? Does anyone have a opinion that they would like to raise?

[00:37:12] **Marcus Ihlar**: Quick comment. I mean, I think either we we drop this or we put some very simple general considerations for tunneling. Otherwise, I don't think we need to call out MASQUE specifically.

[00:37:24] **Lars Eggert**: Lars, think there's an int area tunnels document. I think Joe Touch wrote it. I don't know what the status is. I don't know where it's going, but it says some of these things like, how do you, like, tunnel things into the tunnel and out of the tunnel, especially in terms of signaling, I think, generally, and maybe we can just steal that and point to it instead of doing it again.

[00:37:48] **Brian Trammell**: I'm in AD.

[00:37:53] **Gorry Fairhurst**: AD advice is I don't really wish to see a dependency on that document. Although it's a good source of text if you want to read lots of about tunnels and find something useful.

[00:38:06] **Zahid Sarker**: Yeah. I I think I'm one of the person who said, like, we don't need to say too much things here. Because, I mean, if, anyway, if any Scone client gets, like, multiple of, like, SCONE rate, they will just keep the minimum. Right? They can do whatever. And it's really written on the on the Scone draft. So I don't know. Like, we need to do all these things. This this this doesn't harm, but I don't know if we need that. We can just say, like, hey, be aware of, like, okay, the tunnels and and the outer and inner tunnels both can have just some some scone. And the client decides what to do. I think it will just, anyway, take the minimum.

[00:38:51] **Mirja Kühlewind**: To last point, so this is not generic about tunnels. Really, just like what a tunnel should do with a scone document that's not in Joe's document and whatever. The so it sounds like people want less text, which I'm totally fine. It's just like when I started writing, I came up with all of these things, so I wrote them down. But if you want less text or completely different text, they just, like, really need to tell me what should be removed or what you wanna write instead. I'm happy to close the PR. No problem. But this is a little bit generic.

[00:39:26] **Martin Thomson**: Seems like the queue management in in echo is completely bung. So I made a suggestion because I noticed there's a mistake here. It says the client should take the minimum of two values, which is not correct because each piece of advice applies to the flow on which it was received. That's really the only statement that you need to make in this entire thing, And maybe that's what you can you can do. So in the event that there is tunneling with Quick inside Quick, you may receive two pieces of advice. Each piece of advice applies to the flow in which it was received. Done. I think that's really the the essence of what you're getting to here, and maybe that is a is a better way to to approach this. It what you have is fine. It's just a very large expansion on that very basic statement.

[00:40:28] **Sanjay Mishra**: Okay. So I think I would say that if there are still comments on the text, you know, I encourage everybody to go out on the PR and and just, you know, comment there so that'll be helpful. Okay. So moving on. Oh, okay. Yeah. This is the this came out of I'll try to capture just in few words. Stuart's review of both the protocol document and also the AppMan. And in the summary, I might not be doing the the best of the job as to what you had raised, but I think, essentially, the point was that's going in l four s occupy the same design space. And you raised some points as to why we need Scone. And I I I just captured a couple of comments that, you know, came from Christian and from Matt, as you can see here. But I wanted to recognize that, you know, you raised a valid point and that we need to give the airtime that it needs for discussions, especially in this room and from folks that have been following the work to see, you know, where how and what we wanna get out of this particular issue and and whether Scone is adequately addressing this or, you know, what what people think. So, Stuart, you wanna say something? At this point.

[00:42:09] **Stuart Cheshire**: I'll I'll be brief, because I wrote my comments on the mailing list. But since you asked, I will try to clarify a little bit. I remain unconvinced by this, I think and I'm really struggling to understand the motivation. I I have an idea what I think it is, but I'm it might be completely wrong, and that's part of why I'm struggling with this. One of the use cases of this seems to me that in The US, I know there are mobile phone carriers that offers special marketing deals, like get our service for twenty four months and get free Netflix streaming. But they don't want you watching four k Netflix. They want you watching really crappy Netflix for free because they don't wanna use too much bandwidth. So they'll give you a multi gigabit five g connection, but then they'll do this secret handshake with the Netflix client saying, yeah, but don't don't use it. Right? Limit your quality to the lowest tier, which is, I guess, an okay business decision if that's what the marketing department has decided to advertise. If I was the engineer responsible for delivering this, I would deliver it today using a traffic shaper or a policer that uses drop or ECN marking to manage the rate of flows, and then you're done. Ship it today. You have what you want. This proposal is gonna take a long time. I RFCs can take two, three years to get published, and then it takes longer to get deployed. And if I was the engineer tasked with doing this, I would do something that works today, not something that's gonna work five years from now. So I'm a little bit baffled, but clearly, there's people in the room. There's a lot of enthusiasm for this. I think I've expressed my concerns about it, and I I don't want to belabor it anymore. Sometimes we just disagree, and that's okay.

[00:44:17] **Brian Trammell**: Martin?

[00:44:23] **Martin Thomson**: Yeah. Thanks, Stuart. I I think that's that's a very pragmatic position to take, both in terms of what the network operator in in in your hypothetical is is is doing and and and in terms of how we deal with this process. I think there is value to having some sort of transparency about those practices. And so that that's one of the things that I see from an from an endpoint perspective being useful about this is that, okay. So we're getting the the 512 kilobits per second Netflix flow. Now we know it.

[00:45:05] **Marcus Ihlar**: Also, think most operators built these shapers, like, ten years ago and didn't touch them since. And the type of videos has also moved on, so there's Christian.

[00:45:22] **Christian Huitema**: Well, if I was an operator, I'll probably do something like what Stuart said, but with a little caveat. I would make sure that I recognize when you have a traffic that is testing the speed of the network, like, net speed or something like that, and make sure that they find that you have in fact a kilobits. And when you try to use Netflix, you'd have, like, 500 meg kilobits. And that's

[00:45:55] **Stuart Cheshire**: Christian, sorry to interrupt you, but you are perfectly describing the Volkswagen approach to emissions testing?

[00:46:02] **Christian Huitema**: Oh, yeah. Oh, yeah. And and and I'm I'm convinced that that kind of shenanigans are gonna do how happen. So what Martin said about transparency is kind of nice.

[00:46:23] **Sanjay Mishra**: Okay.

[00:46:29] **Brian Trammell**: So one I I'm going to interject one bit of there's something wrong with the QR codes somewhere. This is why we had Tim Jones chiming in. He was actually in queue for v six ops. So be careful with the QR codes and make sure in MeetEcho that you're actually in Scone. Thank you. Mirja.

[00:46:56] **Mirja Kühlewind**: I I just had a quick very quick read through the whole document. And we give a lot of advice for operators, which is good, and little advice for endpoints. And that was kind of my memory or my model of how we did split manageability and applicability in QUIC. It's one for the operators, the other is for the endpoints. I think that's totally fine. I think we should actually focus the document only on operator's advice and maybe just call it manageability and remove anything that's left about, for example I mean, I think, like, if you do that, for example, the section on congestion control could be rewritten in a way that it actually explains to operators that there is an expectation that congestion control is still always used and they don't have to be worried about it, rather than just saying you have to use it.

[00:47:49] **Brian Trammell**: So if I recall correctly, we do have that in the protocol draft, or was it yeah. So is there value in essentially just sort of, like, bringing that that section up and expanding it in AppMan, perhaps? Like, I mean, it's duplicative text. Right? But if you're saying, hey. We wanna put it in front of you. I mean, this is it's the same thing we had with with quick applicability manageability.

[00:48:09] **Mirja Kühlewind**: Is text in both documents, which is very similar. That's the point. Right? So what I'm saying is having less text in this document and really kind of rephrase it in order to address the operators rather than the protocol implementers.

[00:48:22] **Brian Trammell**: Can you send a PR?

[00:48:25] **Mirja Kühlewind**: For this part, yes. Yes. I'm just saying generally the question I have to this group is should we focus on manageability only? That might also remove a few other words here and there. I think it's actually not much that we remove because it's very focused on operator advice only, but should we actually decide to do that?

[00:48:41] **Brian Trammell**: Yeah. Cool. Thanks.

[00:48:47] **Sanjay Mishra**: So I think what I would say is that the the doc document from the editor's point of view look very clean in terms of the focus. But, you know, if there are things that we still need to focus on then, you know, that now is the time to raise it because I think the document is looking like that it can probably move on to the next stage. We have, like, maybe five or six issues of which the two are new ones that came last night. But other than that, the the ones that we have, there's an existing PR that sort of addresses it. So we don't really have a lot of unknowns at this point. There are more knowns, I guess. So maybe the question for the chairs would be that we probably wanna make decision sooner if there are things that we wanna change.

[00:49:36] **Brian Trammell**: Yeah. So I would say, again, lot of people are probably disappearing for holidays for a couple of weeks. I would say we put a no doubt to the list that, like, the, you know, speak now or forever hold your peace on getting at least PRs in on the draft, and then we will drive the number of those down to zero between now and San Francisco. I I think what we've seen is we've gotten actually pretty good asynchronous sort of communication over GitHub. I think that's working pretty well. I don't think we need an interim on this. I'm happy for other people to have other opinions and tell me I'm wrong. But I think that, like so the hey. Let's set a cutoff date. Get your p r your PRs in by that date, and then drive them down before before San Francisco would be the way that I would approach this.

[00:50:34] **Zahid Sarker**: Zaid? Yeah. As one of the document author, I I do think, like, this document is pretty ready Yeah. Solid. And I don't think, like, we need to wait for San Francisco to do have it Yeah.

[00:50:44] **Brian Trammell**: Yeah. Yeah. Okay. So let me see. You have to buy San Francisco. Right?

[00:50:47] **Zahid Sarker**: Yeah. Yeah. So I think that if you just resolve those peers, I think we're good to go.

[00:50:50] **Brian Trammell**: And and

[00:50:51] **Zahid Sarker**: my theory here is, like, I I don't think that we can ever get a perfect manageable capability document. So we just push it out and see. One of the obstacles that we wanted to cover is the ops tier. I think we got a very, very good feedback, and we should be fine sending it out.

[00:51:07] **Brian Trammell**: So No. I I'm Don't wait on it. Saying we've had discussion in this room right now about, like, hey, maybe there could be a PR about that, and I don't necessarily wanna force those people to do that in the next fourteen minutes. Right? So, like, not wait. And, like, at least for me, I don't know what your travel plans are. I I turn into a pumpkin soon, and I reappear in the middle of August. I would So be cut up by then and then like say, hey, you know, this is the cutoff for PRs. Yep. And then we'll drive it to zero. Okay. Sounds good. I think we're in agreement there. Gory, take it a long way.

[00:51:48] **Gorry Fairhurst**: Sorry. With a nice big yellow hat as AD. Yeah. Okay. ADs also have holidays, so you're you're pushed to get the proposed scone protocol to me in, like, two days. We'll actually wait for at least two weeks for me to actually do anything with it. So, there is time for the working group to read the scone protocol document and get this right

[00:52:11] **Brian Trammell**: Yes.

[00:52:11] **Gorry Fairhurst**: Before The second one is Okay. No, no, there's three points. The second one is, Mira's comment was the only one I saw which was potentially disruptive on whether we include the application applicability bit with the manageability. I think we need to settle that pretty quickly because we have had reviews of the whole thing. If we start doing that, then we need to figure out what that is very quickly, and that will determine my feeling about whether it's ready because otherwise, I think it is practically ready. Right. So So that's two. I'll come to three in a second,

[00:52:45] **Brian Trammell**: but carry on. I I I'll say from the chair, I interpret Mary's comment. Maybe, Mary, you can correct me here as like, hey. We've got a document that's 90% manageability and 10% applicability. Do we just wanna call it a manageability draft? Was that the that was how I interpret your comment. Is that correct? Right. Yeah. So that would be that would be, like, actually, like, just cutting some text and changing a title in a way that it's just literally editorial. Right? Like, I don't see that as a big cut.

[00:53:15] **Gorry Fairhurst**: Changing title, absolutely okay. Cutting sections of text may be less okay. I'd like to see the working group just agree that the correct most many people are just gonna read that applicability and manageability document, and if it's not disruptive, then I'm not too fussed. But let's be clear that we all agree on what we're doing.

[00:53:39] **Zahid Sarker**: Yeah. I think I think even though, like, maybe Miriam is speaking the truth, like, has more kind of, like, focus on the operator part and all this thing. But at the very late of this doc stage of the doc, I don't see the need for it. I mean, having those applicability whatsoever doesn't hurt. Is it is it breaking anything? Is it doing anything anything wrong? What's or saying it that we need to change it later in this case? But that's my opinion. But the working group can decide what to do, and I'm fine either way.

[00:54:15] **Mirja Kühlewind**: Yeah. Kulebenignan. So I didn't make the full assessment, but I think it's even less than 10%. And it's not like cutting full sections or whatever. It's actually rewriting sections a little bit for operator view and maybe cutting a few sentences here and there. And I think it's not like it's not like that this advice is, whatever unnecessary. I think it would actually make the document better to focus on operator advice and change the text a little bit in that direction.

[00:54:42] **Brian Trammell**: I think we'll have a more productive discussion about this with a concrete PR than sort of, like, talking about, like, constituencies in the abstract. So And it sounds like you have a very clear idea of what that PR should do, so I am I am volunteering you to

[00:54:57] **Mirja Kühlewind**: Yeah. I roughly have to what I want to understand is if people are kind of receptive of this idea or or if people think this is a bad idea.

[00:55:04] **Brian Trammell**: That's Okay. So okay. I think you got I think you have a sense of that now. So cool. Thanks.

[00:55:09] **Gorry Fairhurst**: Number three. Final AD comment with my. What do you expect me to do when I get the scone protocol document for processing? Because I can send that immediately to the IESG for publication, in which case you're going to get all the operations and manageability questions heading back on that document, or I compare it with the applicability and manageability if that is really just following in half an ITF cycle. I could put these two documents together, and they will go, ah, I see everything's in the second document. I've just read the first. That's fine. So it's a question of what does the working group wish to do. I will happily push one document through at a time, or I'll happily push them both through. But if the working group can get them both through at the same time, I anticipate that many of the issues we'll have with this GOLD protocol document are actually handled in the second document? That's a question to the working group on timing, because if scone protocol should be published urgently, I really think we should just do it. I'm happy to put that on the on the ballot.

[00:56:13] **Brian Trammell**: There is a reason that Marcus' hand is the one that we Yeah.

[00:56:16] **Marcus Ihlar**: I of course, it would be nice to to to handle them together, but, I think we have some urgency for the protocol spec. I think we need to publish it ASAP because we have concrete dependencies in 3GPP specs and so on.

[00:56:32] **Gorry Fairhurst**: Do other people have the same urgency or see it as being really valuable to go ahead? Because that's also useful input to me because I can tell this to people when we put that document on the ballot.

[00:56:44] **Matt Joras**: I agree with Marcus. And while it'd be nice to put them to the through together, I think we should do what we can to push the protocol document.

[00:56:55] **Zahid Sarker**: So on the on the what Marcus said, yeah. I I think there's dependency, but I don't know. Like, it's a daily like, the sky is falling there in the three g p side. So if it is, like, half a cycle, like, we're talking one month to put them all together, I'll I can wait on that then. If you are thinking about, like, changing the admin document for lots of places, I know I need two more ITF meeting cycle, then I think we should not couple them. So it's about, like, how fast we can move on the admin document. So if it is one more month, we have been waiting there. One more month is fine from the three GB point of view. There is no problem. But if it is, like, next November, next December, or January to couple them, then I think we should just ship Scone.

[00:57:39] **Sanjay Mishra**: So I'm gonna insert myself in the queue here. I think what I would say is that the the document is pretty tight in its language and I think it's focused. So unless there's something very specific that that suggestions we have via PR, we're just sort of, you know, dabbling with things and, you know, adding unknowns and then adding times which we have no control over.

[00:58:05] **Mirja Kühlewind**: Would Miya Kulevind, I would really like that we toss this the protocol document over to the to our AD, so we take it out of the working group. That's a clear signal that we are basically done here. The AD has to do a review and, like, direct reviews or whatever, so it takes a little bit of time. And so maybe the AD can, like, you know, wait a little bit, but not too long and then maybe take two the two documents together or not, but I definitely wanna toss it out of the working group as soon as possible.

[00:58:39] **Anoop Prasad**: Anoop from Meta. So I agree with Marcus and Matt. So we see real urgency for protocol doc to move forward. So we should not make it depend on AppMan. And from both from three g p point of view and from real deployment point of view, I think it is important that protocol dock move to next stage. So I see real real urgency on that.

[00:58:59] **Brian Trammell**: Yeah. So so what I'll okay. Marcus, come up, and then I'll say what I've heard from the chair, and then Corey can

[00:59:07] **Marcus Ihlar**: Yeah. I just wanna say one thing. I think that the protocol doc does a very good job of being self contained. There is a lot of applicability in there, and I I don't I don't see why we would need to wait for admin for any

[00:59:21] **Gorry Fairhurst**: So, Gory, can the notes record this discussion?

[00:59:24] **Sanjay Mishra**: That's

[00:59:24] **Gorry Fairhurst**: very helpful to me. Discussion. Yes. It would also be helpful if the working group could get to a position of doing a last call on this document Yeah. Before I have to table it in front of the IESG, which gives you quite a while. Right. The the protocol document. No. No. No. No. No. I said the wrong document. Yeah. On the applicability and manageability, we can do a second working group last call, but if we can see good consensus that this document is already been through a working group last call, that would be also super good. If it happens to work out, that's good. The most important thing for me is please note this on the working group as a whole. Please note that discussion we just had and comment on the list if you have any concerns. Otherwise, we shall be processing these as two separate documents at your request.

[01:00:09] **Brian Trammell**: And from what I've heard from from, like, the discussion in here, my inclination is do you click the button on Monday? I will I'll give time for people to look at stuff on the list. But Yeah. That's fine. That's fine. If they yeah. That's that's actually the best outcome, but, like, we don't wanna hold them up. Okay. I hear pretty pretty that's a pretty good signal on that.

[01:00:34] **Sanjay Mishra**: If I may just add the last word is that the as one of the co editors of the document for Appman, my goal is to close these open PRs that we have as soon as I as possible. And if there are you know, open up quickly, if there's a short window to submit any new PRs Yeah. Otherwise, we should just go ahead and Like, close

[01:00:58] **Brian Trammell**: I don't know. When are you when are you back in like, I'm back on, like, the August 12. Like, I would you know, when I come to work, I will be like, okay. PRs are closed. I'll send something out to the list saying like like, saying this as well from the chairs. If you have anything to do, get them in by the August 12. That'll be the closing window, and then we'll drive that down over the month of August. And then, hopefully, it's sort of, like, mid end August to mid September, we have something that we can do a working group last call on. Working group last call is then done by beginning of October. That would be the that would be the time frame we're looking at. And I think that that then ends up with these two documents bumping into each other in the queue, which is the which is the good thing. And if we don't get it done, then great. We've already sent that protocol. Marcus, can you make sure the notes say that? Thank you.

[01:01:46] **Sanjay Mishra**: Thank you.

[01:01:47] **Brian Trammell**: Thank you. Good. Next. Where are we in the agenda? That was a good discussion. Thank you all. Thank you all very much. We're going to be where we are. Yes.

[01:02:17] **Marcus Ihlar**: Can we try to discuss? Yeah.

[01:02:19] **Brian Trammell**: I think, yeah, now we're on open discussion around. No. Go back back to the no. We're gonna go back to the the agenda because I've Yeah. Yes. So oh, hey. We're actually on time. Amazing. So future of the working group discussion. So we've got like, we now have a decision on we're sending up protocol in a couple of days. We're sending up AppMan as fast as we can get the PRs closed. We have a few other drafts before the working group. Would like to take some time to discuss, would we like to do those here? Would we like to send those elsewhere? I think the most baked of these that has an actual draft is Martin's on scone echo. Do you wanna do you have an opinion that you'd like to voice about scone echo?

[01:03:22] **Martin Duke**: Martin, Google. I wrote it up. I presented at the interim, so I didn't wanna waste everyone's time and present it again. Nothing has changed since the interim. I haven't done anything. Seems like there's fairly positive reception. If people wanna work on it, that's great. If people don't wanna work on it, it's not really up to me, but Google might do it anyway. However, like, if there are if people have real cons as I said in my presentation, I have a lot of trouble reasoning about the privacy properties of this thing. And if there's a signal from the community that this is very bad for the Internet for some reason, I would be happy to try to wave my management off from this idea. So, like, even if we don't pursue it, I would love people to take a look at it and share that feedback. But I'm again, I'm I'm happy to to move the draft along if people wanna work on it here.

[01:04:20] **Brian Trammell**: So so, like, in the the question of keep the working group open and recharter it versus just, like, declare victory, close it down, and and, like, take our blue dots off and go have a vacation. Are there other venues where you think they're the right people to get that feedback from that we could possibly take this to?

[01:04:46] **Martin Duke**: Well, you think we It is a quick extension, so a quick seems like the obvious place to put it. Neither Lucas oh, no. Matt's here to get mad, so that's great. So I'll float that.

[01:04:55] **Brian Trammell**: Okay. I mean, it naturally fits here if we're still a going concern. Right?

[01:05:01] **Sanjay Mishra**: Yeah.

[01:05:02] **Martin Duke**: Yeah. I mean, I I'm this is my my strong preference is not to keep working groups open for a single draft that is just sort of, like, minor. Yeah. But that's more of an a decision than Right. Than mine for sure.

[01:05:17] **Brian Trammell**: Yes.

[01:05:18] **Martin Duke**: Thanks. Cool.

[01:05:22] **Brian Trammell**: Next up is three here. Is not three remote. No.

[01:05:28] **Zahid Sarker**: No. It's all remote already, but

[01:05:31] **Brian Trammell**: Okay.

[01:05:31] **Zahid Sarker**: Since I'm able to attend. Yeah.

[01:05:33] **Brian Trammell**: Okay. Are there I I I don't necessarily wanna have a discussion about somebody's draft where the people who are interested in the draft are not in the room. Marcus, you you show up on this list.

[01:05:50] **Marcus Ihlar**: I thought it was clear from last meeting. I just, you know, wanted to expire and

[01:05:54] **Brian Trammell**: Okay.

[01:05:55] **Marcus Ihlar**: Disappear from this list.

[01:05:56] **Brian Trammell**: Yep. Good. Cool. I think Wes why did my computer do that? Hold on. Let me find.

[01:06:08] **Zahid Sarker**: Yeah. You see

[01:06:09] **Brian Trammell**: Yeah. We have two messages from the on the list. One is Wes still has Scone for TCP and had thought that so this TCPM Scone that the scone TCP option might make sense in TCPM. However, right, this group of people is maybe more attuned to why you would do this and what the the pitfalls are, and you've got some TCP experience in the room anyway. It might be better to run it through here. Does anyone have so I see Martin and Lars in the queue. Are we talking about TCPM, or are we talking about other things on this list? So this is the okay. Good. Go ahead.

[01:06:53] **Martin Thomson**: So all of the things on this list. This working group's gonna be open for a little longer anyway to sort of deal with the dribs and drives that come through when what have you. If if these proposals mature enough, then I think it probably makes sense to to talk about rechartering

[01:07:13] **Brian Trammell**: Okay.

[01:07:13] **Martin Thomson**: But not now. Okay. And if they're not ready in time, and I, you know, had some discussions earlier this week with Marcus and others about some ideas that they have in this general space, I suggest that those can be taken to other working groups if this working group closes before that happens. I don't think we need to worry too much about this. It's good to have the discussion, but it's it's not something that I think we should need need to oh, no. We need to keep the working group open or, no. We need to

[01:07:41] **Brian Trammell**: absolutely close right now because it's not really an an urgent What I'm hearing is is see what happens with sort of these things Let it roll

[01:07:48] **Martin Thomson**: for a

[01:07:49] **Brian Trammell**: little bit. Yeah. As long as we have to be open anyway because, like, stuff's gonna come back on protocol and stuff might come back on

[01:07:55] **Martin Thomson**: app. If we get to that point and none of these things are mature enough to talk about adoption That's then I think we we let the natural course of things take its action, and we we close. There are many other venues in this in this organization that can take this up. Some of these, I think, probably may be the sort of thing that you would wanna take to a buff or something like that or Yep. Or at least a dispatch session anyway. Yep. So.

[01:08:18] **Brian Trammell**: No. That's that's good feedback. Thanks. Lars?

[01:08:22] **Lars Eggert**: Lars, I think, Mozilla. I'll be slightly more aggressive in Brazil, and then we do you wanna succeed now or soon or or never? Which is overstating it. But think I sing closing the working group is actually a signal that, you know, this thing is done and ready. And I think once the main documents that we just talked about, like, are done and ready, I think it would be a strong signal to to close the working group. There's TSVWG if there's related follow on work that that we wanna do. If something gets ready, as Martin said, like, in in the remaining runway, that's also fine. Right? But I I keeping the working group open for some assorted items that that may or may not have energy left seems like the wrong call. So I I would basically propose for like, if you get your thing done in the remaining runway that we have before the other ones come out of RFCs, great. Otherwise, you know, close the group. Anything else can get traction elsewhere.

[01:09:15] **Brian Trammell**: Alright. So I'm hearing I'm hearing stronger signal here that this is a conversation we're gonna have in San Francisco. And if you've got interesting stuff in this space, you're on notice that this is a conversation we're gonna

[01:09:25] **Zahid Sarker**: have.

[01:09:26] **Lars Eggert**: If you really, really want one of these, if you're like one of the proponents, right, put the energy in now.

[01:09:31] **Brian Trammell**: Yep. Okay. Cool. Corey.

[01:09:34] **Gorry Fairhurst**: Well, another AD comment. Thanks for helping the AD. Oh, I'm I'll drain the queue first.

[01:09:44] **Brian Trammell**: Yeah. No. Oh, you want others to

[01:09:49] **Martin Duke**: Okay. Martin Duke, as one of those proponents, I I maybe this is a stupid question for former AD to ask, but, like, what do I need to do to make it more ready? Okay. I I I feel like it's pretty simple, and we we can't adopt it because it's not chartered. I mean, I I guess I could, like, nag people on the list of go file issues.

[01:10:10] **Brian Trammell**: I think that's probably what we're asking you to do is nag people on this those to go file issues. I think you say you I mean, I heard a very clear privacy consideration. Somebody should maybe look at this and have an opinion. That that sounds like a thing that you might wanna get advice from from other people who are in this room. Okay. You can use feel free to use the list for that. Right?

[01:10:29] **Martin Duke**: Okay. Yeah. So I'll I'll send out the list. Like, people may may not have comments. Right. And if And, like, there may may not be GitHub issues to come out of it, and I'll I'll certainly do the PRs, but, like, that's Yeah. Okay. And it's an individual draft. There's only so far you can beat people Right. When Yeah. But it's not adopted.

[01:10:46] **Brian Trammell**: I I I think that the model that we're sort of leaning toward here is, like, adoption in WGLC in the same Oh, okay. Right? Like, get it like, you have time to get it ready before we'd have the rechordering discussion. Right? And, like, you can do the work necessary to get it ready while we're doing the parallel rechordering. Okay. Right?

[01:11:08] **Martin Duke**: So Alright. Thank

[01:11:10] **Lars Eggert**: you. Okay.

[01:11:12] **Gorry Fairhurst**: I was gonna talk at the end of the thing. On this particular there's only one on this list here, which is so simple. We've actually talked about it several times already, and it's only one parameter. I'm not sure what more is needed for that document at this point. I'm alluding only to that top one. That top document has been placed in front of the working group in April. If you're interested in that, please read it. If you hate it, please say you hate it. If you love it, please say you love it. I could squint at the charter and say, does that fit within charter even? I'm not doing that at the moment, but look at that document and see. The other ones are clearly extra work to me. Yeah. So I'll comment on finally at the end, but please discuss that one specifically right now if you want to or on the mailing list as soon as possible because the working group is running out of energy.

[01:12:09] **Zahid Sarker**: I I think, Gurri, you just said what what I was trying to say. So I I'm in from this list, I'm interested in three. Two one of them is, like, out of Skoln. Another is, like, Martin Dux echo, which is he's claiming, like, almost ready. And then the last one is, like, if we can look at something under the path change thing, that would be great. But there's just no, like, meeting time on all those things. So so I think I'm repeating the same thing. And I kind of like what Lars said, like, closing the working group actually a good sign that we're done, and we can do things in later on. Rechartering, reopening the working group, may keep the mailing just alive, has TSVWG as a as a anchoring point, all these options are there. So until San Francisco, we run, and then in San Francisco, we decide what to do. I think this any decision in this meeting is premature for me.

[01:13:07] **Brian Trammell**: I've heard that I've heard that real clear.

[01:13:15] **Mirja Kühlewind**: Just very quickly on the first document. I don't have a strong opinion about the document itself, but I think it belongs in the quick working group and not here.

[01:13:33] **Presenter**: Probably the second from the the last here. If you look at that current charter, that's going we talk about a lot of UDP for TOPL. And then the last sentence of charter is, okay. Let's make a quick as the initial starting point. And then we, this time, submit some real scenario in, a rookie. That is the based on the UDP part. It's like well, more like the AI. Everyone talk about it. And a lot of traffics across the DCs that are going through the the RoCE technologies. And then we want to leverage the the similar principle being discussed in the the SCOAN part, and then to get, like, a rate adaptive rate adjustment. So, like so our proposal is to keep the the SCORM open and then to recharge it. And then well, because of the current charter, it just, like, make a quick at the starting point. And then now we can relax the restriction about the quick. And then to, you know, either remove that the the final line of the initial point, it just, like, change something else. Since the initial point does not prevent, we just go beyond the initial point. So the RoCE well, just by the way, that the the draft we proposed is based on the UDP. So yeah. But, basically, well, in this case, we can include UDP cost is already in the charter, UDP for TOBL. So thank you.

[01:15:02] **Martin Duke**: Sorry. I keep coming up here, but I can't think fast at the mic. Because I was kinda blown away by your, like, adopt working class call thing in the same session deal. And and what surprises me about that suggestion is implementation.

[01:15:19] **Brian Trammell**: Well, so we've done that with protocol too. Right? Adopt last call and then hold?

[01:15:24] **Martin Duke**: Okay. So you're not you're not expecting, like, three implementations by note by No. By Sam's

[01:15:31] **Brian Trammell**: I mean, like, if you can get three implementations done and over summer holidays, then great. Mean, like,

[01:15:34] **Christian Huitema**: there's Yeah.

[01:15:35] **Brian Trammell**: That's awesome. I mean, like thing called vibe coding. It's awesome.

[01:15:37] **Martin Duke**: I could probably do one. Yeah. But, like, but, like, I don't know if people are gonna You know, I I can't speak to whether people are gonna rally around running a bunch of code on something that's this speculative at this point. Right.

[01:15:48] **Brian Trammell**: No. That makes sense.

[01:15:49] **Martin Duke**: But okay. But if you're not if you're not expecting implementations by then in this whole Yeah. In this speed run, like, then then

[01:15:55] **Brian Trammell**: No. That

[01:15:56] **Martin Duke**: that's cool. Alright.

[01:15:56] **Brian Trammell**: No. But the speed run model that we had for for Scone protocol, I think, worked relatively well. Right? Like, so I'm I'm pretty happy with how that worked. So

[01:16:04] **Martin Duke**: I mean, it, like, it took two years.

[01:16:06] **Brian Trammell**: That's a speed run-in this area.

[01:16:09] **Martin Duke**: No. Totally. But, you know, you're talking about, like like, an hour and a half

[01:16:13] **Zahid Sarker**: Yeah. Yeah.

[01:16:15] **Martin Duke**: Of of adopted draft lifetime. So Yeah. Cool. Alright. Thank you.

[01:16:22] **Lars Eggert**: Last second, Mozilla, I don't wanna rattle, but on on on the RoCE one. Right? I mean, RoCE works because it's incredibly tightly integrated with the fabric flow control, and there's there's special end to end congestion control. And I kinda wonder how that would even work if something else in the network also has opinions about rates. So so it seems like if you have RoCE deployed, you already have way more knobs than Scone gives you to manage your traffic. So I I I don't quite see how how Scone adds anything into into into a RoCE network, but maybe I'm misunderstanding it.

[01:17:03] **Presenter**: Mister chair, instead of just talking on the fly, and can you just display one slide? Because the probably the next couple of slides, we are the one talking about the challenge in the RoCE. I think there are only one slide. Yeah. That's the thing. The challenge part is on the left box regarding the long RTT in the wide area network, and it's simply depend on the DC, the congestion control. Notification, convergence is going to be too slow.

[01:17:32] **Martin Thomson**: Yeah. You don't deploy

[01:17:34] **Brian Trammell**: area on

[01:17:37] **Zahid Sarker**: network.

[01:17:38] **Presenter**: No. No. It's not. It's like because of the AI things, because we cannot do now the the compute power capability is not sufficient. Yeah. Now it's we have to go through some the cross DC. Yeah. Yeah. Thank you.

[01:17:55] **Brian Trammell**: Yep. So I think the what is it? Okay. Go ahead.

[01:17:59] **Gorry Fairhurst**: Just on RoCE. This looks a little bit to me like multilayer int versus Internet part versus transport part, and how you manage that congestion and ingress and building networks, that looks like TSVWG to me. Not saying that any of the documents that we've talked about here shouldn't progress in the IETF, and quite the opposite. I think if they have support, we'd love to progress them. All I'm talking about is whether this is the correct home for that particular piece of work. Consider also whether this is more suitable for TSVWG because it talks about both network layer and the transport.

[01:18:41] **Brian Trammell**: So what I've heard pretty clear from the working group and also from the AD, and I think this would be the plan that we would adopt, is if you have interesting engineering work that you think might fit in Scone and you would like to consider it for a rechartering, have it ready for San Francisco. Right? And we'll have a more detailed discussion about, like, sort of where that goes or how we dispatch it out there. Right? So I think that's the that's the clear guidance that we got here.

[01:19:09] **Gorry Fairhurst**: Cool. Yes. Particularly, first document. Yes. Get that discussed if you really think it needs to go ahead because Right. I've done my thinking. There were various concerns around SCAL in the first place when we did the chartering. They probably applied to that first document, so there is a good reason why this group needs to comment on the usefulness, the implementability and the dangers, if any, of that document. And please do.

[01:19:39] **Brian Trammell**: So one other thing that I I did wanna channel from the list. So Jason Livinggood was pointing out that there's probably interesting work that could be done sort of in the Scone API space where this would be the right group of people. I think that I'm also gonna take that back to the list and say, you know, where we got in in Vienna was if you wanna be considered for rechartering, get, you know, get it to a point where it's it's actually ready to consider in in San Francisco. Any other yeah. I went ahead and locked the queue. Does anyone else wanna, like, jump the locked queue?

[01:20:23] **Presenter**: Well, I know it's going to be discussed in San Francisco for the rechartered part, but that's just the one data point for MASQUE related because there's a discussion about the six g architecture, although it's still fluid and then dynamic. But the new things proposed, like, there's some something. Well, basically, you try to give two different type of the UPF things. And then with the MASQUE as the one the ones the features to to be deployed there. So with with that new architecture, if adopted by the end of the year for the six g, I think the the MASQUE with the in the scope will be a better choice. Yeah. Just for data point for the group. Thank you.

[01:21:09] **Brian Trammell**: Thank you. With that, I think we're on to any other business. Correct? Yeah. Any other business? Going rep. Yeah.

[01:21:29] **Presenter**: Yes. Just some thought regarding the app and the manageability, the document part. So far, it seems everything is based on the what we have right now for the quick based protocol. So if this one app and the management ability document is, you know, the finally published, but later will keep us going alive and evolving. So on that case, will new technology, new architecture, those type of things will impact the the current one.

[01:22:05] **Brian Trammell**: Yeah. I would like, my so speaking as an individual here, just like sort of like the the the readability, the way that I would suggest approaching that would be each of the extensions that's adding sort of like the scone signaling to a different protocol would have to may have, like, the applicability and manageability in its operational consideration section. Right? Like, these would be sort of like different diffs to that. I I would I would not wanna be like, okay. Here's seven different back ends. We're gonna keep the AppMan document open forever. I think, like, that'd be a really good way to make Sanjay very angry and saw head even angrier, and I'm just not interested in that. So yeah. Cool. But thanks. It's a good point. Alright. Already said going, so going. Gone. Thank you all very much. We will see you on the list and in San Francisco. Have a great rest of your week.

[01:23:10] **Marcus Ihlar**: Just wanted to thank Brian because this at this hackathon, this was the first hackathon where we actually had real scones.

[01:23:17] **Brian Trammell**: Yes.

[01:23:17] **Marcus Ihlar**: Those were excellent. Thank you.

[01:23:19] **Brian Trammell**: Thank you.

[01:23:24] **Zahid Sarker**: Oh,

[01:23:29] **Brian Trammell**: in the where to send it. Oh, okay. Okay. So it might be