**Session Date/Time:** 20 Mar 2026 06:00

**Chen Wu:** Hi, Brian.

**Brian Trammell:** Good morning. How's my audio?

**Chen Wu:** Good. Good. So let's kick off our discussion. So welcome to Shenzhen meeting, welcome to SCONE working group meeting. My name is Chen Wu and my co-chair Brian Trammell online, so will co-host this meeting. So thanks everyone to manage to come to this meeting. So this is really the last session for today. Yeah.

**Chen Wu:** Note Well apply. So this is the new format of the Note Well. It's applied to everyone. Please be aware the IETF policy, IETF process, and conduct yourself in a professional manner. And please also be aware that your contribution to this meeting will be deemed as an IETF contribution. And if you have any IPR related to your contribution, please disclose according to IETF rules.

**Chen Wu:** Meeting tips for in-person participants: if you already sitting in this room, you should, you know, sign in to this session using Meetecho on-site tools. And we have, you know, hanging from the microphone and outside there are some barcodes. You can scan the barcode and go directly from there. And if you already joined the session and so please be aware, you know, logging in to this session is important for you, you know, to join the queue for the discussion and also to participate the, you know, hands raising, polling. And also, when you complete your presentation or make your comments, please turn your audio, video off. For remote participants, the same guideline apply. And use of headset is strong recommended.

**Chen Wu:** Administrative: Meetecho, actually we as the chair using the Meetecho to manage the queue. And actually on the bottom, you have hands button. Actually, you can use that to join the queue. And for chat and Jabber already integrated into this Meetecho and you can help to forward the key discussion point to the meeting room. Blue sheet, actually we don't need because we already, you know, can automatically record your participation using the Meetecho. Note-taking, and I have sent the note link to the chat window and please help with the minutes taking. And it doesn't need to be detailed. And if you make your comments, please, you know, make sure the comments, you know, has been captured well in the meeting minutes. So we provide the link for the online agenda and slides. You can get access to it.

**Chen Wu:** Working group status. So since last IETF 124 Montreal meeting, we don't schedule any interim meeting since, you know, all the agenda charter items, you know, on the right track. And we set up the two working group GitHub for both SCONE base protocol and also applicability and manageability. And for established experimentation and interoperability, since the Montreal meeting, actually in this way we don't have a hackathon project but we do have Marcus, will provide the implementation status report. And so we will continue to connect multi-vendor interoperability experience to support SCONE protocol publication.

**Chen Wu:** Document status. We have SCONE base protocol actually has already posted working group last call and really waiting for, you know, more implementation experience to be accumulated and we can decision to moving for the publication. On today's agenda, we have two working group drafts. One is draft-ietf-scone-protocol. The second is draft-ietf-scone-applicability-manageability. This will be the focus of today. Liaison and communication, we don't receive liaison from any standard body, but we expect, you know, there's some update from 3GPP and Zahed will give a short update.

**Chen Wu:** The goal for today's meeting and we'll try to establish experimentation and pre-interoperable basis for a hackathon project. And most important is we will revisit working group last call comments on draft-ietf-scone-protocol to drive for completion. In addition, we'll review the status and input on applicability and manageability topics. In this time, actually we have new proposal from Sri and to talk about Wi-Fi applicability. We'll also, you know, to explore some, you know, individual draft topics and so this is a agenda for today's discussion. Any agenda bash?

**Chen Wu:** Now, let's move to the first topic. And I think it's Marcus, right? Or Martin?

**Brian Trammell:** Martin, we cannot hear you. Can you open your mic? It's showing unmuted, but...

**Martin Duke:** Yeah, I think it's a, it's a in-the-browser problem. Yeah.

**Chen Wu:** So you want to share your screen or share your- how do I pass control to you?

**Brian Trammell:** We can't hear him. Oh, oh. Can- can you hear me now? Ah, yes. Cool. Great. Oh, you're in Tokyo. That's correct. Thank you, Kazuo. Yeah.

**Martin Duke:** So, um, as Chen pointed out, we're- we're past working group last call on the- on the main document. So we're not going to take all of the time that you've given us here. I think what we're discovering as people implement things is there's going to be a trickle of tiny little issues and whatnot. Marcus was very helpful in putting together a pull request that sort of cleaned it- a few things up editorial-wise. And I discovered last week, I think it was, that we didn't really say anything about multiple- we didn't say anything about multiple SCONE packets in the one datagram, for which we now have a pull request that says there's no point doing this. Anything that's on the path is going to be updating the first one. And if you put others in there, they don't. Um, but on the other hand, uh, if you receive a packet- a datagram that's got multiple SCONE packets in it, uh, you're free to drop it, but it's- it's not an end- connection-ending situation for these sorts of things. Otherwise, it'd be a denial-of-service vector.

**Martin Duke:** Uh, that pull request is up. I think the editors that have discussed it are pretty happy with it. Uh, so that's a normative change, but I think it's probably an acceptable one. Give people a chance to come to the microphone and tell us otherwise. Um, but aside from that and whatever sort of other minor things come up over the course of the next little while, I think we're really looking to- to get some experience with implementation. Um, our plans now seem to be that we'll be turning something on in Firefox just to see that we can accept the packets and- and get things going. Um, but obviously, because we're a browser, we're not going to be able to pass those signals to anything usefully. So, um, that's something that we may want to talk about somewhere else, but those people are interested in that discussion reach out. I've got some ideas and would be happy to collaborate on that front. Uh, I'm really interested to hear what folks who have um other implementations that are not browser-like have in terms of their implementation experience and- that sort of thing. So if you've got experience on that one, please- please do share. I think that's really the main point of discussion here.

**Chen Wu:** Yeah, we have a Zahed on the queue. You want to make a comments?

**Zaheduzzaman Sarker:** Zahed. Yeah, on the- on the multiple SCONE on the same datagram, I think- I think you made the right call here. So we actually looked into on our side to see like whether there is a possibility and exactly what the network element should do about it. And my- my thinking was like network element should not do anything about it. It's the endpoints should do the care about it. And the question was like whether there'll be some error or something that you want to do? No, I think- I think in this case, we would probably have our- our usual internal diagnostic logging to sort of check whether things are going a little bit strange, but- this shouldn't happen. Uh, from the network element perspective. Yeah, this has nothing to do with- if you're a network element, why would you even look for a second packet in- in this case? Exactly. That's exactly the point. And I think I mean, yeah, if there's something malicious happening and an endpoint should take care of it, that's what and then you can decide like as you said like if the question is like whether you're going to terminate the call because something bad happening, that's also endpoint's decision. Yes. Can't- can't really terminate the connection. If you terminate the connection, then you're opening yourself up to denial of service. Uh, if a- if a something has added an extra SCONE packet to the datagrams that are flying by, uh, then that- that would be akin to damaging the AAD on- on QUIC packets, in which case uh we just drop those and carry on, right? So that's the right way to deal with- deal with the situation there as well. Yep. So I- I think the- the thing that you suggested is the right thing to do. Yes. So go ahead and do that. Right. Thank you.

**Brian Trammell:** So- so I had a comment here as individual and then a question as chair. Um, comment as individual: uh, I- I saw this PR and I was kind of surprised this language wasn't already in the draft. So it's like it's a normative change, but um I was like wait a minute, this is editorial, right? Because this is kind of obvious. I think I really like having the "may" here because I do see one situation in which you might want to terminate connection on this and that is to get someone's attention, right? It's like your implementation is broken. Turning it into an availability risk gets somebody else to care about it if you can't find somebody on a telephone, right? Yeah, we're not really saying anything about that and I think that's probably based on- on that feedback the right thing to do. Yep. No, I- agree completely. And as individual, I already said, hey, go ahead, ship it.

**Brian Trammell:** Um, question about so um I- I agree with your assessment, chair hat on, I agree with your assessment that we're going to see things come in as a trickle. Um, just for IETF process cleanliness, I think what I'd prefer to do is have us put uh this draft into "waiting for implementation experience" and then do one push of the GitHub draft into the ID per meeting cycle just to make sure that like people who are reading the ID version of it off the data tracker are, you know, at least getting like one update every, you know, every meeting cycle. So is that- Totally manageable. Very easy. I- I was- I was wondering whether you were going to ask about um doing a- doing a final check if we sit in this state for too long and the trickle gains enough volume, we may have a discussion about- Yeah, what I- what I- what I would do as chair is basically look at the size of the diff when we come out of that "waiting for implementation experience" state and if there's like, it might be that we're like, oh, oh, we all realize this is going to need another working group last call. I would hold- hold off on that last call until we want to come out of that state just so we don't do like seven last calls on this. Um, but I think we need to have sort of like a one-way flag that we keep for ourselves that, okay, this is actually big enough and then we will do a final- as chairs we'll do a final review and be like, mmm, okay, does- was this all editorial or was this... Yeah. Yeah. So I think in the current state of things, uh an email to the list saying we're about to go to publication would be enough based on the changes that we have so far, but if- if things start to get a little bit more, you know, major, whether that be volume or severity, then we'll- we'll reassess. That's fine. To be clear, in my judgment, PR 144, even though it is a normative change, doesn't hit that bar, right? Because like I think any, you know, reasonable person would say this is editorial. Okay. Cool. Thank you.

**Marcus Ihlar:** So, some questions on this. I- I kind of agree with the approach. Uh, I think it would be very good to clarify like how much experience do we expect to get before shipping this? Like, we- we have a number of implementations here, we already have some interop, and I would be worried that we are waiting in this state for too long, especially now as Zahed will be presenting soon, there is a dependency coming here from 3GPP on this document. So if- if we are like stuck in waiting for implementation experience too long, that- that- that would be problematic. At the same time, I fully agree with this. And- I don't even- I don't think we need those slides, but I was just going to present that we didn't do any interop at this session, but we do have implementations and we're actually actively looking for endpoints to test with and so on. Uh, but I would like us to, you know, say something about the deadlines here because- yeah. We- we- we also need to make progress.

**Martin Duke:** I mean, I think from the perspective of the editors, um and I'm maybe reaching a little bit, but they'll tell me if I'm wrong, we're ready to go at any point in terms of the document. It's just that we would like to get some- some evidence that this works in the wild. Um, and that- that means a little bit more than just people implementing it. It means seeing someone somewhere with a- with a real application saying that it's- that it's giving them some value.

**Brian Trammell:** So I'm going to- I'm going to make up a- a starting point for this discussion just to see how much people- like just to get the discussion going. I think we had one cross-vendor vendor or like cross-implementation interop on the real network that we looked at last time. This was the- the Ericsson and the Meta thing I think, if- if I recall correctly. Last time, actually, Chin, if you can bring up- I have a slide deck on interoperability. I have a picture of the interop that we got- last time. Yeah, yeah, yeah. It's one of the slides there. So but I can talk to that now. So- so we had a few interop points that were interesting. We had some university guys in Aachen doing a network element and the client and then they were talking to a server by- by us from Ericsson through network element. We actually chained two network elements even. Uh, and then at that hackathon we also did Matt implemented support for SCONE in the- in the Android Facebook application and then we were sending SCONE packets through- through the network element updating rates and so on. So if you hop off, yeah, it's this one. Yeah. Yeah. Exactly. I remember that. I think I drew that slide. Um, so yeah, I think what I'd want to see here just as a starting point and we'll see how much we- we hate this. Um, two independent network elements, two independent servers, two independent clients with at least one of those intending to ship.

**Chen Wu:** Okay, we're done.

**Marcus Ihlar:** Uh, just one clarification question there. Like we have been testing setting, updating SCONE packets and so on. The draft also discusses things like throughput measurement, things like that. Are these things that we actually want to test before shipping this as well, or is this something we'll...

**Martin Duke:** I- I don't think the throughput measurement thing is worth um worth gating on. I think the- the thing we're delivering is the signal, and as long as the signal is getting through, then that's good. I think whatever policy enforcement network elements are going to be doing on the back end of that uh is- is not something that we can predict. It- in a lot of cases, it's completely orthogonal to what we're doing. So I wouldn't- I wouldn't gate on that.

**Marcus Ihlar:** Good. Thanks.

**Mirja Kühlewind:** Mirja Kühlewind here. So I came to the mic to actually disagree that we should wait. I- I'm not sure what we're waiting for. Um, like you just said, we want to see that there are actually benefits. I don't think that's something where we need to draft- keep the draft open, right? If we did a bad job and the protocol doesn't work, that would be very sad, but we wouldn't just throw it away or like I mean like- if we want to keep the draft open, then this would be things we're expecting where we find problems in the implementation or things that we overlooked that we might through test- find through testing. That's the kind of thing that you keep the draft open for, but I think test- testing-wise, we're actually pretty good here. And it's not like such a big protocol. It's very straightforward. So I- I think we're ready to go.

**Brian Trammell:** I- I think the biggest thing when- when we had this discussion in Madrid about keeping it open, I think the biggest thing that we were uncomfortable with, if I recall correctly, please correct me, was the- the time constants, right? Like is this- is this 67-second time constant a... um, like close enough to what we need? Um, if we believe as a working group that we have sufficient experience to say yes and we have the two, two, and two, then- then I would say editor's discretion is to when they think the document's ready.

**Marcus Ihlar:** So, sorry for hopping in here, but that kind of puts me back to my previous question because that the 67-second stuff somehow relates to- to measurements and that depends on...

**Brian Trammell:** True. Okay. Yeah. 

**Marcus Ihlar:** Like, we are definitely interested in doing these tests. We- we are actively doing such tests internally, but I'm not sure if that's relevant for protocol interoperability and progressing the document. Um, but... Okay. Okay.

**Mirja Kühlewind:** Yeah, I- I wanted to say thing- I'm not- I'm not sure how we get that answer actually without running it for, you know, for a while and then figuring it out. I mean like, if the intention is to change this number to whatever, 32 or another number, I'm not sure that makes a big difference actually.

**Chen Wu:** Yeah, we have Corey.

**Gorry Fairhurst:** Yeah, still no video. I don't know what happened to my video. Never mind. Um, it's better without the video probably. I- I think I would like to see some consideration of these numbers. And I suspect we can probably do it for the next meeting and just people present some slides and say, yeah, we've considered all this stuff and we've looked at it internally. I'm not sure we need an interop for that part. I don't know how that helps, but I think we should have had some reasoned discussion of why the numbers are the way they are and people have looked at them and got their implementations. I'm not sure we need a whole process about this. I suspect if people declare next meeting um we've had experience, we've tried it, um we have implemented it, some of us, and we're sharing this, and the spec's not changing, then- then we're ready to go.

**Zaheduzzaman Sarker:** So Zahed again. So yeah, I thought like I'll be discussing this when I was presenting- I'll be presenting the 3GPP thing but as we started to discuss here, yeah, there is a need that we have a some dependency and, you know, like 3GPP they go on clock kind of they have a schedule all the- all the release and everything, it would be great if we can do that. Um, and the second thing I wanted to say like, yeah, we need some interop. I think we are doing it. We need also some- somebody to say like, hey, with the 67 monitoring period is the most vulnerable kind of like part of this whole protocol because it's a simple protocol. If somebody just come and say like, this is working for us and they own the content or like they own the user experience, then it would be great. Um, and for that, we can target the next meeting. That's what I was going to say, like maybe in- in Vienna we- we all the interest party we make sure like something we have ready for the working group to consider in Vienna and after Vienna we- we are good to go. And that would be like the- I mean, that's- would be the- my sprint here. And then in Vienna we can decide like what to do, keep it open more or not. So Vienna is a- like a good time frame I would say like to- to finish this up. Uh, don't- and don't forget that we have this app-man thing that we also want to ship, that means like those authors, this working group need to work on the- that document also really fast.

**Brian Trammell:** All right. So the- what I'm hearing in the room is uh Vienna or before. Um, I think we should have a discussion at the end of this meeting about what we would need in terms of interim meetings, if any, in order to meet Vienna or before. Um, Marcus?

**Marcus Ihlar:** I- I would be very happy if we get there before. I don't think we need all of that time. It seems a little bit excessive, but yeah. We can have that as an ambition maybe.

**Brian Trammell:** Okay, cool. Um, so let me propose the following: uh, we start after this meeting a thread on the list um of, you know, do we think we have enough experience to ship this or not? We evaluate that and we have as a working group a very motivated hard target to not let that go beyond Vienna. Nobody seems to be disagreeing me on- with me on that, so we'll take that as guidance to the chairs to get this done by then. Cool. Thank you very much.

**Chen Wu:** So we move to the next.

**Brian Trammell:** Yep, I think we've- that's the interop, right? Or?

**Chen Wu:** Interop. I think Marcus, you have interop.

**Brian Trammell:** Actually, we've kind of already talked about it.

**Chen Wu:** Okay. Next is Zahed and SCONE applicability. Yeah.

**Zaheduzzaman Sarker:** Hello? Can you hear me now? I guess. Cool. Uh, so this is like I'm- I'm presenting on behalf of like the authors of the applicability manageability and- Okay, so basically we adopted this one and we- we had version 00, we adopted that one and we say like we- we got some comments and feedbacks, so we made changes um in the version 01. Um, so that's basically- So what changed? We actually looked into um reordered the whole section, clear problem description and all this thing that's I hope at much more clear. Align- and there were some alignment issue there were some- some terminology used in the SCONE protocol that was not there or like so we stopped uh tried to sync with the SCONE protocol document. Um, and then we also like got some comments, clarifications, uh suggestion for the condition control mechanism, so we updated that one. I don't have an exotic list of the things on the diff, you can go and look into that one. Um, so the idea here is now there was some discussion about the maturity of the document and all this thing. So obviously it's 01 only and if the working group would like to progress on that one along with the same kind- put it on the same stage as uh status or like the quality as the SCONE protocol, we need reviews to improve the document. So that's the ask here that please go ahead and read the document and provide- file issues so that we can solve it in next version. Um, that's it. I mean, I don't know what to say. These are like very editorial changes and clarifications and we just need the commenters or reviewers who provided feedback go- to read the document and tell us then we can have the discussion and talk about the maturity of it. Any comments on the- that's- that's the update. Anybody has read the document other than the authors?

**Chen Wu:** Yeah, anyone make a comments? And John in queue.

**Zaheduzzaman Sarker:** Because there's another part of discussion that I think we're going to- have some open discussion about applicability statements both in SCONE and the applicability manageability document. Um, but that's for later session I guess. Apart from that, you can tell me.

**Marcus Ihlar:** Yeah, I- I think this is- is good. I think we're- as we're wrapping up the protocol, I'm planning to spend more time on this. We have been thinking quite a lot about the relation to L4S and so on, we'd be happy to- to contribute on- on that part to your document as well. Uh, and yeah, I- I think if we put our effort into this, I think we should be- it would be great if we can target to get this published in some reasonable time frame for 3GPP as well because we're now starting to get quite a lot of questions around the applicability and the use of SCONE and so on. And- and yeah, I- I would be happy to spend more time on- on contributing to this, yeah.

**Zaheduzzaman Sarker:** That's great. So chairs and note-takers, please note Marcus volunteer. So I mean- I mean, this would be great from the- from the protocol um authors from the protocol document to actually review this one because then you can see the discrepancy on like the things where you need to align or things where you need to put more details on applicability manageability and like kind of reduce the load on SCONE protocol document and stuff like that. So it would be great. And but this is for general- whoever trying to deploy SCONE in your network, please read this document and tell us whether this is any good- good information for you.

**Chen Wu:** Next, Lucas.

**Lucas Pardue:** Yeah, so I- I haven't read the latest version of the document. I read one prior to the working group adoption. Um, so I- I can take another look. Uh, I was kind of asking the chat like is- is the idea to publish this document alongside the protocol? Do they need to be tightly coupled? Probably not, but just thinking back to some of the uh feedback we got during the uh QUIC applicability and management documents, like I'm wondering if we wait too long we'll- we'll go down the process and then get interesting feedback from maybe people in the network or ops areas on like, "Oh, you should have thought about this, you should have thought about that." So is there- is there maybe a way we could get them to do some early review now and give us like- pose us some good questions we could think about while we have a bit of time rather than leave it too late? The answer might be "No, don't do that," um but it just came to mind.

**Zaheduzzaman Sarker:** Yeah, I- I mean- I'm fine. I think if chairs have any comment on that one. So...

**Brian Trammell:** So, um, I- I think- I would ask the AD to- to contradict me here, uh but I think we can send out documents that are sort of like kind of working group done but not working group last call out for early directorate review, and I think it would be the ops-dir review, um would probably be the most interesting one to get. I mean, we can certainly ask for that.

**Zaheduzzaman Sarker:** I- I mean, I think we can send document to review for any time you like as a call for early review with a specific question. Because sometimes we send early review without asking the right question like what to look at. It's not useful. So it's not general description rec- review we should go- do, I mean, I think I don't know what Gorry thinks, but I think we can, if you are the first- the working group do you think you're in good shape then you go for early review.

**Gorry Fairhurst:** Yeah, if you think in good shape, just go for it. Um, there is some guidance from Ops Area on what they're expecting, so maybe look at that guidance document, which is currently a draft, but I can forward it to the group and that will give you an idea of what they're expecting and therefore you make the real feedback more positive. So I'll send that out to everybody on the mailing list and then you can decide when the document's ready for that review.

**Brian Trammell:** Thank you.

**Mirja Kühlewind:** Mirja Kühlewind again. Um, I only had a very quick read of the document. I still need to do a proper review and send you feedback written- in written form, but that's why I give my feedback here. Um, I think uh there- you're on both sides like for example adding something about the relationship to congestion control is a very good idea. That's a question we get very often and we can address this in this document, so that will be very useful. Um, but there's also still stuff in the document which was, I think, from previous versions where it was more like a requirement document and it's kind of still touching on topics that I think were resolved in the- in the protocol document itself. So I think we can actually just remove a little bit more text there on that side. Um, so I think we should really take- look at this document and- and maybe even separate those two points out where we look at "What does an operator need to know who wants to deploy SCONE?" and like, for example, there we get the question very often, you know, "Can we use SCONE and L4S on the same network?" Yes, you can. So answering this question is good. And then the other thing is what needs an application uh needs to know that wants to use SCONE. Like that's more maybe this question about measurement intervals and what you have to consider there. And like putting- separating these points a little bit where possible I think would be useful for the document.

**Zaheduzzaman Sarker:** Yeah, I- I think that- that way- I think that's where the applicability discussion is more important here because if we have some concrete kind of way like what are the applicability and what goes in SCONE protocol, what goes in this protocol, we have a pretty good idea then actually what you're doing to- you're suggesting we could do easily. Right now it's a bit tough because we don't- it's more about like the manageability document than those kind of things. And some- what when I joined this group of authors, I actually tried to do requirement- so whatever solved, don't put any requirement, put it into some like, okay, it's- this is a solved thing, this is an statement rather than requirement. So we can work on that one. So that's why I think I was asking the chairs to give the time this working group and this session to talk about applicability. There are a couple of things that we can work on this document and make it a bit even better.

**Mirja Kühlewind:** I mean, if we actually have a lot of time in this session, we- not this session, but in a session, we could really you- could- we could go through the sections and actually have a discussion about each of them I guess. Yeah. Sure. Sure.

**Zaheduzzaman Sarker:** So what I would suggest like you guys review, uh give a review and then we update the document and then go scope- section by section to actually agree on on these things if required.

**Marcus Ihlar:** Sounds like an interim to me. Um, uh on the OpsDir review question here, I don't think it makes sense to just send the applicability document for review. If we send it for review, because that doesn't bring them enough context. So I guess we need to review both then, just to clarify. If that's the intention, yeah.

**Zaheduzzaman Sarker:** Yeah, the applicability manageability document is useless without the SCONE. So I think yes, I agree with that. Um, for that one actually, I mean we can- we can send it. Yeah.

**Mirja Kühlewind:** Mirja Kühlewind again. One quick thought: I talked recently to somebody um who did something with QUIC in the network and I was like, "We wrote this in the manageability document, did you read that?" and he was like, "I didn't know it existed," right? So I mean that's a problem we should also consider here. Not sure how to solve that.

**Zaheduzzaman Sarker:** I mean, one thing that- I mean definitely as- I think Martin had a comment like, okay, you don't want to normatively reference this applicability manageability document, but I think the protocol document somehow should have a something to the reference saying like, "Hey, if you are planning, if you're reading this document, we expect you to also read this document to know like what you can do and how you can use it." So I think that would be one way of doing this. Um, for- for QUIC I think there is the separation, there is a RFC 9000 is the only thing people read, perhaps. People forget about applicability manageability, and that's two documents more to read, that's one- another issue I guess.

**Mirja Kühlewind:** Yeah, but I mean QUIC is also already a long document. Yes, it is. So that's not the problem here at least. No.

**Lucas Pardue:** Yeah, that's kind of what I was getting at with my earlier question in the chat like are we progressing these at the same time? That the issue Mirja raises is like, I see it a lot, people asking questions and I'm like, "Go look at these documents, they're really useful," and they're like, "Oh, I didn't know." So I- I suspect maybe if you put the protocol document out and the ops people review it, they would raise a load of questions that we're answering in a different document. So if there was some way to like soft-link them... Yes. ...that- that could be useful. But anyway, again, this is all kind of details, don't need to go into it right now.

**Zaheduzzaman Sarker:** Yeah, I- I think so too. Um, so then the time is over, but... we have time. So maybe you want to refresh the time-is-over thing so that people not scared or don't use it because we have lots of time. No, but don't- don't get out of this slide yet. We have this 3GPP update thing. No, not this one. You- yeah. The next slide. Yes.

**Zaheduzzaman Sarker:** So here, um I just want to give a very short update. Um, maybe I give a couple of things so that you understand what's going on there. So 3GPP is a standard organization that work on creating mobile networks. That's their- tariff. They have different groups like we have different areas and there is a one group called SA2. Um, they have- also something called change- protocol specification, they go- they run things by release date, date, date, so they have a particular um release points and um until the release point they actually expect and they have a T-doc, which is basically gives an study item, then they start to work on this and you actually create a change request. You say like, "I want to change something on the specification," you send a change request, they agree on the change request, then- then drop that into the specification. That's the process how 3GPP does. So in last- meeting, um it happened in- it was number 173 meeting in SA2. SA2 is the group. Um, they agreed on as a short amendment, they call TI20, Technical Enhancement. It's a number is always there to refer it, TI20, uh to incorporate the support for 3GPP- support for SCONE in 3GPP network. Um, so that's it. The follow-up: that means like in release- 20, wherever the- the- it is in the market and these people are using it, deploying it, you have a chance to really- deploy SCONE. Uh, that's the decision they made, so it is part of the release 19 right now. The details how they are doing to incorporate, how they are going to connect this SCONE into other kind of network functions they have, this is still up- up open and they are working on it. We don't need to bother. What we need to um get informed like 3GPP now gonna have specification and they're- and if somebody deploy the specification, we're going to get SCONE deployed. So in 3GPP network, that's the idea. There was like a 17 company who agreed to do that or like supported this effort, that also contains vendors, um the mobile operators, and the content providers. And you can find all the additional information there. And that's why I think the main point of sharing this information here, as other SDOs are having a dependency, they have a time scale to follow, so I think that perhaps we need to take into account to push things a bit faster here in IETF so that um people can go and deploy. And this is a very good news for SCONE protocol. One of the main use case that SCONE had was mobile networks.

**Zaheduzzaman Sarker:** I don't expect anybody to question me now on 3GPP process or anything, this is just an for your information, but I'm open. If you have anything you want to know about 3GPP or about this TI-doc, please connect with me.

**Brian Trammell:** So I- I do have a question about this as chair. So given the- given the state of SCONE in the 3GPP process right now, would like shooting for- IESG publication in- at or before Vienna be sufficient for feeding into that process of the protocol document? Or do we need to go faster?

**Zaheduzzaman Sarker:** I- I think that's- that's doable. I mean, if you're going to send it just after Vienna, that should be fine. That should be fine. We don't need to go faster than Vienna if we find in the process between now and then that- yeah, we need the time.

**Marcus Ihlar:** Faster is better, but...

**Brian Trammell:** Faster is better, yeah, I understand, but like- I mean, yeah, we're obviously not going to keep this open until Vancouver, right? But...

**Zaheduzzaman Sarker:** Yeah, 3GPP has like 0.5 meeting slot time to fix the- fix these things, so it's actually- they are fixing- they are freezing their release 20. I- I don't know exactly date, but it is somewhere after summer.

**Brian Trammell:** All right, that's useful. Thanks. And I think after Vienna if we need, we can expedite the IESG review process or RFC publication process there. Gorry will help us. Yeah. But I'm seeing a very emerging- an emerging consensus that ship- ship by Vienna is- is our target. Yeah. Cool. Thanks.

**Chen Wu:** So for next, you know, the applicability will have some overlapping with SCONE protocol, so you will lead the discussion. Okay. So...

**Zaheduzzaman Sarker:** Yeah, so- yeah, so this is the applicability discussion that we wanted to have. Um, so as you know, uh this SCONE protocol that went to working group last call and when we were reviewing that we realized like, okay, we have an applicability section in SCONE protocol itself. And then we also have applicability manageability doc as a milestone and we're working on that one. And the discussion- so this is might be some creating some like, okay, consistency and duplication issue. Like, okay, if you're duplicating things, you need to say same thing. Do you- do you need to same thing on two different documents? Where do you put it and all these things? So the idea of this discussion today is like, okay, where the applicability statement should remain and how much um both document, one document, or what not? So that's the idea. Um, and this came up out of like the propo- there are some proposals that came out of from the- working group last call review. Um, just to be clear, I don't have any favorite and we have- basically we have these two points: keeping applicability, rename the applicability section and keeping the section and reduce some of the text in the SCONE document and details in the applicability document. And for the third I just- for the completeness, I added that one. So I think we need to do something. So let's focus on the renaming the applicability section to SCONE uses. I mean, that's a like to- that could work. But still, I mean renaming a section doesn't really change the content of the section. And the I think the comment that we received in the mailing list saying like, "Okay, let's wait on the maturity of the app-man document and then we try to move," the question was then "Well, when- if we don't move things now, how can we make the document mature?" So what I would like to discuss: what people think about option one. The second option is basically uh keep the section in the SCONE document, but in a bare-minimum level and then go point to app-man document for the details. So for example, congestion control um kind of this interaction with congestion control, you can just say like in this- this is not a congestion control signal, you should not use SCONE as a congestion control signal and then in the app-man document we go in details interaction with different congestion control, L4S and what not. We don't need to overload this SCONE protocol document with all those details. So but and the "do nothing" means "well, we have duplicate inconsistency perhaps in the description and duplication." So just wanted to discuss what do you think we should do?

**Mirja Kühlewind:** Mirja Kühlewind. So I think the SCONE protocol document is in really good shape and it says the right thing, so I wouldn't want to change that. Um, I actually- I mean, the name change doesn't make a difference, but I was wondering if "applicability" is a renaming of that section, but I don't like- that doesn't make a big difference, so whatever. Um, I think we should really take the opportunity in the manageability and applicability statement to say the things that we can't say in the protocol document. Like- like- like the example you had on your other slide, like talking about the relationship to L4S. That's like super useful, it really doesn't belong into the protocol document, right? Um, and maybe there is not like a long list, maybe it's just a few things, but if they have a value, let's put them there. So I- I again repeat actually my comment from- from the previous slide set: I think there is actually um too much stuff in the applicability and manageability document that really doesn't belong there and that's why we have this overlap. That was because we started with the requirements and now we address the requirements and we can just like remove a lot of the stuff. Yeah, I- I mean- I mean the thing is like my- my main goal is to like even if like it's a little bit of things. Like I gave an example: like the whole text I copied here in this is in SCONE protocol document. And the SCONE protocol document could just say the first paragraph and leave the details for the SCONE applicability manageability. It's- it's there. It could be one way of doing things. So you actually- I agree with you, the things that SCONE protocol says on applicability part is useful but doesn't need to be that detail. Is it those things, is it related to protocol description, protocol specification? Because there are also sections in SCONE protocol document where you talk about these things again.

**Mirja Kühlewind:** So a little- a little bit of overlap is okay because- um the- this is- this is different people who are reading this document, right? On the one hand, it's somebody who wants to implement the protocol or wants to implement an- an element in the network that actually reads the data or writes the data in the protocol. Um, the other document is a little bit more on like, "Do I actually even want to start deployment of SCONE in this setup? Like before I even start implementing it, what do I need to know?" So I think it is- it is a different scope and it's- it's a different audience.

**Zaheduzzaman Sarker:** Yeah, I mean the thing is like whoever- yes and kind of perhaps no. Whoever would like to deploy in network element or applications, they would need to read both of these. Like SCONE document, if we can make it like standalone um or we make it a complementary to each other. So that's the idea. And the idea perhaps, I mean, my- it seems like the- the idea would be to have the second bullet and try to see like what are the minimum things, get rid of something from the app-man and or reduce the- some of the things in SCONE protocol itself. I don't know like and that's why I was thinking maybe I'll- like somebody should create some PRs and to then we can judge like, okay, how much change we're talking about, right? So we can- we can do that as well. But I- I didn't want to do huge PRs on the both of the documents without having a clear instruction from working group how to- how to deal with this.

**Marcus Ihlar:** Um, there- there is one more option too in order to reduce overlap and that is to just make everything one single document. This is- this is a small protocol. Uh, the guidance are useful and I think it's like- it's useful to have guidance together with the protocol. I have personal experience of that with implementers in my company, um and like Mirja said before, people sometimes don't tend- don't- do not tend to read the companion documents and that's a problem. And given that we have a- it's such a small problem space here, I wonder if we could just merge everything into a single document uh because we need some text to establish the necessary context for reading the protocol. You need to understand. And like you said, you probably- anybody who intends to deploy and run this probably needs to read both of these documents anyway. So maybe a way forward could be to see "Can we get all the stuff we need from app-man into the main protocol spec without overbloating it?" I think that would be an- something to explore as well. Maybe a question for the group and the chairs.

**Zaheduzzaman Sarker:** My- my opinion is like I would like to keep them separate as much as possible for two reasons: is like in app-man document, we can have a quite a bit of details. People don't need to read it just like if you are just coder- coder, just coding the protocol, the somebody else operations and like application management and those people can read the details of it and analyze that's one reason. Another reason like the SCONE protocol as Mirja was saying is in good shape. So if you want to now change a lot of things again, you need to go through the working group process again and that's creating more delay. I'm afraid merging this document is going to create more delays and as we have been discussing, this is going to put us a bit onto the back foot saying like we need more time to... Yeah, okay. So that's why I- I want to keep it separate if it is possible. And what I really like about SCONE protocol document is simple and short. Yeah, and we don't need to overload that one.

**Marcus Ihlar:** If we keep it separate, I'm, yeah, I'm worried about removing too much from the main protocol spec.

**Zaheduzzaman Sarker:** Yeah, sure, sure. I mean, that's- I mean I don't think like you're going to move the whole section or whole point, but yeah, some of the details could move.

**Dan Druta:** Dan Druta. Um, I think there's areas in the applicability that have not been covered, including use cases because that's what applicability is all about: "When do you actually want to use it? How?" Um, the- the- there are questions about how- what should be done if you change the access network, um from a client perspective. So I- I do think that there's- there's- it needs to be sort of a user's guide, if you want, for engineers, um how to use the protocol, right? That's how I see the applicability. Um, measurement- compliance. It's an area where it's just a statement there right now basically: "Oh, you have to have a measure- a means to measure it." But are we comparing apples to apples um from a network perspective versus uh the- the application and so on? So I do think that- that one I- has a place. Um, I- I don't know if in the end we don't end up with a lot of details, maybe merging is the right thing, but um I- I- I think this- this should be uh expanded and I'm willing to help. Thank you.

**Zaheduzzaman Sarker:** So- so then just to get your idea, you think some details could be uh in the app-man document that would be helpful for you. Yeah, okay. Yeah, like I said, I- I think there's- there's a lot of things that- that makes sense to be described because we didn't have a- use cases and requirements. Okay, we don't need requirements that are fulfilled, but we still need to explain where this makes sense to be used and how. Um, how the measurements uh are- are consistent between the application and the network and um and just what happens when you're- like I said, when you're changing access. Um, how- how is that actually counted on the- on the client side? Um, if you go from Wi-Fi to 5G and 5G to Wi-Fi, um you may or may not get signals. Um, that- anyway, I'm just saying that there's room for improvement and I think it has a different purpose with probably different audience.

**Zaheduzzaman Sarker:** Yes. Thank you. And uh if you think like there's room for improvement, just create issues and create pull requests. I'll- we'll be very glad to uh look at those things. So I don't know like you chairs making any sense out of the discussion? So one thing: we don't want to merge, that's my conclusion. Another thing is like maybe the second option is the right option. But then we need to sit together and say like, okay, what are the things that could be, should be moved or like shuffled around? And I also heard like some interim to focus really on like app-man document to just solidify things. That's the three thing coming out of the discussion so far.

**Brian Trammell:** That's what I think- as well, but we do still have two people in the queue.

**Zaheduzzaman Sarker:** Oh, I have! Okay, Gorry, go ahead. Sorry. I cannot see. I- there is no expansion. So you chairs need to guide me. If there's people in the queue.

**Gorry Fairhurst:** Hi. Um, okay, so I tried in the chat to ask why don't we just try to do everything as in why don't we try to publish the two documents, publish them at the same time, have both ready for Vienna, have both consistent, and then if we succeed, we could get two successive RFC numbers. That way, you get to read one and you get to read the other. I- I think if that's- if that is what the working group wants, we- we can- we can ask for this. So, um it's a challenge just to see um whether we can complete everything by Vienna. I mean, if merging them was an option, then surely completing them is also an option.

**Zaheduzzaman Sarker:** Yeah, I mean the working assumption is like we should be going together and that's why I was saying like if you want to do things by Vienna, we need to really work on this one. And in that case, we need might like the suggestion was like interim or something like to- to finish it up. And please remember, I don't think- my personally don't think like there is a lot of change needed. So it's a very minimum, just but we want to do a look at it together and make the changes. And if there's no need for changes, that's also an option.

**Gorry Fairhurst:** Yeah, and I think on this one it means that the working group really has to decide um in this meeting to commit to some sort of review cycle so you can actually get eyes on these documents and make these decisions in a matter of weeks rather than months. Yep. Okay, that's all I wanted to say.

**Mirja Kühlewind:** Mirja Kühlewind. Yeah, I don't have a strong opinion about one or two documents like at the point where we want to publish it, if everything is ready and we want to merge them together, it doesn't make a difference, so- but I do have a strong opinion that I think the- the protocol document is in very good shape. I just read it recently. I wouldn't want to remove stuff from there because even so it touches on applicability, it really gives the context you need in order to understand the protocol. So I would really like just to see the approach that everything- like in the applicability statement or manageability statement shouldn't have the goal to like explain the whole space and answer every question that ever will come up because we will learn so much in the process of deploying it, like we will never finish it. So we should really take the opportunity and write those things down that we- that we know now we think are important we want to say in addition to the protocol document. And for me, sorry I'm saying L4S again, but for me that is a very um good discussion to have. And the other point um that I would like to see in the in the applicability/manageability statement is about how you um if you need enforcement, if the reg- if the signal is not adhered to or if like what the use cases are for that. Like either you can- you can monitor the signal and then like have a rate limiter or you can monitor the signal and do nothing and it's also fine, right? A little bit discussion about these kind of different cases and where it makes sense. So these are the two things that I find really, really valuable and not sure about all the other things in the draft.

**Zaheduzzaman Sarker:** Yeah, sure, but I mean if you have suggestions how to improve, please send the PR. Definitely create issue. Who is- who is the next in the queue? Brian.

**Brian Trammell:** Uh, yeah, so I- I threw myself in basically to um say I really like Gorry's approach or Gorry's suggestion, right? Like that we basically say, hey, we're going to try and get all of this out by Vienna. I think that's doable. I think- uh as- as chair I'm taking guidance from this discussion that we should be aggressive about interims in this cycle and maybe even have our goal to be um not meet in Vienna, right? Like see if we can get to the point. I don't think that's realistic, right? I think we probably will want to do a few sort of like closing-off things and figure out next steps, but basically get to the point where we can get both of these documents out without requiring meeting in Vienna. So- so I'm- I'm taking that as- as a chair as guidance to create the uh an interim schedule and sort of like um traffic on the list, etc., etc. to- to set a review cadence that will get us there. Um, but I really do like Gorry's- like what I'm hearing from this discussion is um, hey, there's probably some stuff that should go into applicability. We really don't want to- we really don't want to mess with protocol because it's in pretty good shape. All of this stuff goes in the document, we should like sort of like focus on getting that into a good package as well. Martin?

**Kazuo Noguchi:** Who appears to be Kazuo because audio problems. Uh, so I just wanted to sort of level set on expectations here and- and facts as far as I see them right now. I've- I've read this- this document. I think it's a very nice clear concise summary of the sort of things that- that an operator might need to- to think about in terms of- of using SCONE. It's nowhere near as comprehensive as the applicability section in the main document. That's the present state of things. Now, if- um if someone's willing to contribute the text that Mirja's talking about um with respect to L4S or um some of the different sort of generic network architecture things uh akin to the- the sort of things that um in the upcoming drafts that we're talking about, then I think it would be a useful thing to have still, but I'm tending to go with- uh the suggestion from earlier to- uh to sort of find any novel information that's in here and try to merge it into the main document uh in its present state. Uh, now that's not to say that if it grows a little bit bigger that- than it doesn't have independent value, but uh it is very short right now. And maybe that's the virtue of it, uh but then it would be a- a title change for the applicability and manageability document which is a- a concise summary of SCONE for network operators would be the new title. Uh, and that may be valuable, but um I- I think it would probably be better in that case to- to merge that in the main document.

**Zaheduzzaman Sarker:** So- um Martin, you were saying like um put all the applicability thing whatever it is in the main document SCONE specification document and make it- the other one completely manageability one?

**Martin Duke:** No, I'm- I'm saying right now the material that you have right now is almost entirely duplicative of what we have in the main document. Yeah, exactly. And- It may be a bit longer, but there's not a lot more- I don't think- I think maybe there's a couple of things around the edges uh with respect to QoS and some of these things which has a more uh network operator focus to the language in it, but essentially I think it's duplicative of the language that we have in the main document um in terms of the substance of it. And so if there's anything that we've missed in the main document that's in this new- in this applicability document, then maybe that's the way to do it, but um right now it reads very much like a very succinct um concise document addressed to network operators for how to understand and think about SCONE, which is not- which is useful thing to have, but I think in the- in the sort of grand scheme of things, I would rather- I would rather not have that document um and instead merge it into the- into the main draft. But, you know, Mirja had some- had some good- good examples of what things that you might be able to say to an operator that would be much more detailed. So if- if that materializes, then maybe it- it turns into its own document again.

**Brian Trammell:** Yeah, I think we'll- we'll see if we get like we- we're going to put an interim on the schedule, uh we'll see if we get text by that interim and we can make- we can re-ask that question um uh if we hit that deadline or not.

**Zaheduzzaman Sarker:** Yeah, I- I think- I think this is good. I think this is good. I mean, if we have interims to discuss this one in a very regular basis, and I think then we'll just sort it out. I wanted to put a bit more effort uh to create some PR to just as example, but I as I said like I was not sure my effort uh is needed right now at that level. So that's why having this discussion I think we have a- very good discussion and if you host all the interims, I think we'll get to a place where at the end before Vienna we can decide like what exactly to do. Yep. Yep. I think the next talk, which we should probably get to, um is- is going to be an example of something that might fall into that- that larger document. Cool. I think we're done from my side here.

**Brian Trammell:** Yep. Thanks a lot, Zahed.

**Zaheduzzaman Sarker:** Thank you.

**Chen Wu:** So next is Sri, Wi-Fi applicability.

**Sri Gundavelli:** Okay. Can share the slides. Okay. You have a control now. Okay, all right. Sorry, let me pick my- Okay. Uh, thank you, chairs. So I'm Sri Gundavelli, I work for Cisco. I'm with my co-authors Mark Grayson, Joey Joshua, and Joey maybe joining as well. So this- is an applicability document, draft-ietf-scone-applicability-manageability for IEEE 802.11-based access networks.

**Sri Gundavelli:** I- I think the- the key discussion point was during IETF 124 uh there was a presentation on SCONE for cellular, SCONE for 5G, at the time there was a discussion, there was a question in the- side forum on "Will there be uh another companion document for Wi-Fi?" And in the charter we signed up for that, I signed up for that, and- and we published the document. So why- so the- so the question is "What do we intend to cover in this document? Why- why is it required? What's the relation to the base document?" So base document is as we all know, uh defining the protocol, signaling behavior, the semantics, right? The applicability draft document do not go into any of those things, does not- no- does not change the semantics, no protocol changes. It's more an informational spec on how SCONE can be deployed in Wi-Fi networks. Where the SCONE function will be implemented, what are the operational considerations, how do you- what- what level of visibility that's present in the- in the- in- in Wi-Fi environment for someone to com- for the network to compute the rate values. As well and potentially- it's currently it's not there but we intend to publish an example algorithm for rate calculation. So this document was extensively somewhat reviewed by in the Wireless Broadband Alliance and all of us all the authors are members of- of that forum. There's a- community there's a very good level of interest, we see value in- in this rate signal.

**Sri Gundavelli:** So again the larger context, I think why- I- I think the key question is if SCONE is a access agnostic, you know, is there value in publishing a document on a access- access specific uh on- for every access? I think we tend to think yes because the considerations are different, the visibility, how you do the rate calculation, what is visible to the network element is completely different. In Wi-Fi environments, stations share their time, these are physical rate adaptations, there's MCS- something called MCS, right? There's a channel load considerations, there's interface- interference considerations, right? There are also like in cellular, there are policies, user-specific policies that typically come from AAA and that have to be honored by the access network. So today such rate signal is not present. Yeah, sure, the endpoint can know its RSSI value, it can know its packet losses and other things, it can do some real-time calculation, but there is no rate signal from the network. So I think the excitement in the WBA community is such a- there is a utility, there's a broader utility for this- such a rate signal. I think- any- I think there's also a discussion point I think in my discussions there was a comment that oh, SCONE is- is not a very aggressive signal, right? It's computed, it's an estimate for a window of time. But in our opinion, that itself has a- there's a value because if we know that for a- for a window of time, I'm getting so and so uh such a rate, right? My hando- I can even use that signal in my handover decision logic. I'm using an application, the network is not able to meet my rate criteria for the application, maybe that is a good signal for me to move, instead of if I do react too quickly, I'm doing a flip-flop, right? But so in that sense a slow signal has a value.

**Sri Gundavelli:** Again, nothing new, a SCONE protocol recap, but with Wi-Fi network elements in picture, right? I think Wi-Fi, typically the air interface is the bottleneck, right? So implementing a SCONE any function on the AP where it has visibility into the air interface, MAC layer visibility, right? A guidance derived locally is- is- makes sense. So these are few variations, I think, you know, today Wi-Fi networks have certain variations how you deploy, what we typically see is a Wi-Fi access point, but there's also a controller, there's a policy function which is AAA, right? And there's a cloud management function. Based on how you split, I think there are- these variations like sometimes, you know, in a controller-based architecture even the data plane terminates through the controller. Some of the MAC and fine- some of some of the functions are split, like, you know, at the access point is- is kept in a- handles- handles messages, the transactions which are- way- which- which need to be handled at a very aggressive rate, for example, there's a data frame and the network needs to send an ACK frame, that potentially an ACK frame cannot come from a controller but it- it will come from the access point. So typically the way it splits is some the- even the control- controller will have good level of visibility in any- in any case, right? But in some cases, the controller is just- sets it up but it's more an- a policy-handling function. Depends on how you split it up, but- but I think we tried to articulate as like how in each of the scenarios typically where uh the SCONE placement makes sense, right? SCONE any co-located with the AP because AP has air interface visibility, MAC layer visibility, right? A guidance derived locally is- is- makes sense, right? So these are few variations. I think nothing- stands- stands out, but largely a guidance on how the where the any function has to be implemented.

**Sri Gundavelli:** Now, from the policy point of view, uh like in cellular system, there is a- it's not exactly, you don't call it subscription profile, but there are user-specific policies in enterprise or in any environment, their policies, which are in some cases can be even rate-limiting policies or are defined in AAA and are conveyed to controller/AP based on the previously discussed models. And that policy element has to reach the SCONE any and SCONE any with visibility to the air interface and even the WAN metrics has to do the computation and provide the- the guidance. So AAA RADIUS already defines per-user bandwidth policies. I think we talked about this, there's some many vendor-specific VSAs that are used, the AP contr- AP enforces these limits and can derive advisory rate throughput uh value. SCONE exposes the resulting rate guidance to the endpoint.

**Sri Gundavelli:** I think now the- with respect to the actual algorithm, what- what level of visibility that a SCONE any can have in Wi-Fi context. I think- or maybe the elements that- that matter the most in the SCONE rate calculation. The physical rate, the MCS, what we tend to think there's a channel load, right? Like, you know, channel is 70% at load condition, right? The number of contending stations, so or- or maybe for the downlink case it's the packets that are queued at the access point, right? The policy limits, right? Packet error rates what we're seeing on each, right? Because every station is at a particular RSSI value, even there are some transmission issues at the- at the access point, it needs to look at all of those things, that how much is the backlog and the airte- airtime contention with stations with the AP and also, you know, neighbor AP. All based on all of these elements, the- the rate calculation has to happen. Now, the SCONE the rate guidance calculation is unspecified, but we in plan- intend to, I think we are planning to do some level of interop with few vendors are interested, and if you're successful in that we plan to publish an algor- an algorithm or approach as how, you know, what- what parameters matter and how we can uh do this rate calculation.

**Sri Gundavelli:** I- I think there's another discussion point, I think in RADIUS, I think you know, there is a- something called connect info. Um, it's- it's- it's- the idea there is to indicate the access network performance to an identity provider. Excuse me. Excuse me. So for example, I'm going to a particular Starbucks and my performance is not- my link performance is not good, my identity provider, if it's an Verizon or AT&T can make a decision that, you know, based on all the data that we have, this network is not- you know, may not meet the SLA that we- we want to provide, right? They may deny the authorization. In that sense, there is telemetry that's going from the access point to the identity provider, right? But what the missing element was there is no such indication even though the access point says, "I'm seeing all of these parameters, this is how, you know, potentially in fact almost it's- it's very similar to in the SCONE- this indirectly translates to some- some QoE or measure- aggregate level QoE. I think, you know, depends on how you derive it, but we are able to characterize the venue environment based on this RADIUS signal from the AP to the AAA. Now, the missing element is a corresponding signal from the AP to the- to the device is not present. Maybe in the SCONE as a- as a more as an application level, even though it's end-to-end, but we tend to think we are- we can realize that signal in the form of SCONE. So it completes the loop in one sense, right? Here we are able to indicate something about the network performance to a- a AAA. Again, I recognize- we recognize that is a path signal, but still uh the sema- semantically we are able to deliver the same thing to the endpoint on other side. So in that sense, I think it completes the loop. Of course, we can wait for a 802.11 signal or something, but again on an access basis if we define the signals, they're never implemented. The- the excitement about this is the- the presence of this in the QUIC, you know, we can can realize the ecosystem very quickly, I think uh we can realize that signal very quickly and- and see deployments. I think that is a- another point.

**Sri Gundavelli:** And I think some discussions on roaming and handovers how, you know, some more thought needs to go into this, but uh in 802.11 there's intra-AP AP-to-AP handovers. In that- in those scenarios what exactly happens to a SCONE? Sure, I'm in this environment, I do move to a different environment, sure, the rate calculation has to again uh to be done in the new environment, but with respect to timers and other things, we need to be a little bit sensitive. I think uh Martin was saying other things, but uh we did capture some- some aspects, right? But we need some more thought as to go into this, right? This and- and I think- this is a- I think I had a lot of discussions, I think maybe you know I'm- a slightly controversial topic, but- but again uh we tend to think there's value in both uplink and downlink. I'm not- you know I- I do recognize, you know, I understand that the focus was more on downlink and there is- for whatever reasons I'm not arguing about that, but a general comment is if we can make it symmetric, I understand the technical challenges, but somehow if an endpoint can get rate signals for both directions, a given peer it has value. I leave it at that, that's more as an FYI. Uh, other than- finally summary point, I think uh SCONE is access agnostic, this draft explains applicability to Wi-Fi uh deployments, AP wireless LAN controller has visibility into radio conditions and policy elements. Based on that, we can do the SCONE rate guidance. And I'll pause here and I think I'll ask my co-author Mark to, you know, he can- he can explain things better than me. Mark, you want to chime in and say few things?

**Chen Wu:** So, Sri, you are ready for question. So Marcus.

**Marcus Ihlar:** All right. Um, thanks a lot for this presentation. I think it's- it's really interesting to see a discussion of applicability in- in one more access. Uh, a few questions. Uh, SCONE as it's written right now comes with some assumptions on- on applicability, like we have this 67-second monitoring period and so on. Is this something that is uh does that match your view of applicability in this particular- particular scenario?

**Sri Gundavelli:** Absolutely. I think uh the- the time window, I think I was saying there is a value in- in- see, in Wi-Fi today, if you look at it, the client behaviors can be very reactive. The problem with that is you're always doing- it's like a ping-pong, right? But if you can provide an estimation on a window of time, I know that from- based on all the data that I have, most likely I'm going to give you such a bit rate or I'm going to- whatever, right? Or I'm going to send- uh this is the downlink rate I have, I can offer you, right? I think that indication, even it's a- I call it a slow signal, has value. I think I'm not precisely commenting whether 67 seconds or 40 seconds or whatever, but a slow signal- uh at a slow frequency has value in my opinion, Marcus. Okay.

**Marcus Ihlar:** Yeah. I think that's good. Uh, what I'm a little bit concerned is that if we start getting signals with vastly different semantics, then it can be problematic for the endpoints to understand what they mean. But uh if that works for you, that- that's good because there's always the option of like if we realize that you need some slightly different semantics to this, you could have like a different version number and stuff like that, but- but if this works, this- this is good. The other question is uh or comment rather is about the-

**Sri Gundavelli:** I would only add one comment, though. I think we would- we plan to do some interop, maybe we'll have bit more visibility. Right now it's bit uh theoretical. So it's possible, you know, after our implementations, we may say that, yeah, maybe you know, we may need a different profile. I do not know yet, honestly, but... Yeah. Okay. Let's see then.

**Marcus Ihlar:** Um, on the uplink thing, I mean, it's- it's not fully true that the SCONE protocol right now doesn't support uplink rates. It's just a little bit different way. I mean, it's not- they're not being sent in the downlink towards the client, so- so the- the- the- the- advice are sent in the direction of- of the traffic. So as long as you have the possibility from the endpoints to coordinate in some way, uh you can actually signal uh uplink rate limits or throughput advice uh with the current protocol.

**Sri Gundavelli:** Yeah, I- I say only one thing, right? It's fine, the indirection mode is totally fine, but as long as the protocol- it's at the same protocol layer. It should not be at the application layer, that was my argument actually, right? Uh, it- so I don't want to shift the burden to applications and say, "Now it's your burden to you talk to your peer to get it at an application layer," but if it's at the transport layer, in the QUIC layer somewhere, it makes sense in my opinion, whether even the signal from the other side.

**Marcus Ihlar:** But I mean, even in the- in the base spec, even for downlink in some sense we- we- we are shifting the- shifting the burden to the application layer because a lot of the use cases that were motivating this were uh like, you know, video on demand and things like that and you somehow get this signal on the transport layer and that's propagated up to some application layer and then that drives whatever that application does. And that could be, for instance, limiting the range of uh encoding bitrates that you- you're like requesting when you're requesting video. So I think already like in the base assumptions of SCONE, we- we kind of punt a lot of that up to the- to the applications and let them deal with it. But- and also that's partially, you know, I think there are some good benefits with doing it that way because um we don't necessarily, because we have this long average window, we don't necessarily want SCONE to be a transport layer signal. We don't want it to be directly influencing congestion control, uh at least for some networks like 3GPP networks, we're pretty happy with allowing the endpoints to decide themselves how they most efficiently like determine how to burst out data because typically our- our networks kind of enjoy getting large bursts of data and things like that. So- so leaving these averaging decisions up to the application layer rather than, you know, influencing some pacer in the transport layer is also beneficial depending on the- but maybe your applicability- applicability statement is different. So, yeah. These are things I think we need to understand better.

**Sri Gundavelli:** thank you so much, great feedback, appreciate it here.

**Zaheduzzaman Sarker:** Zahed. Uh, I- just kind of wanted to say things that Marcus just said on the applicability part and the uplink-downlink part, so let's not repeat that. So the thing like when we started to this work, SCONE work, we actually talked about it what are the things is- do you- is it like for a particular mobile or cellular technologies or is it for the internet? And we went for the internet part of it, so it's- that's why it's access agnostic. Now, um then we had this uh like description of like things like how in 3GPP network one can apply uh SCONE and all this thing and I think it was said from the working group like, "Okay, this is something that 3GPP or other SDOs can handle, like you have this protocol in IETF, how do you apply it in your network, it's up to you." So I think this is something that also kind of like similar question here, like in your description today, but I say I have not read the document, sorry about that one, so I was just listening to you. I understand like it is possible to apply SCONE in Wi-Fi networks in a different kind of setup even, that's great to hear. But if you are agreeing also like the long kind of monitoring period is is really something that you can confirm to, so I was thinking like what's really the difference here? Like why do we need a document on a access-specific thing? It's not clear to me, because then shall we have this kind of access-specific manageability applicability document for all the access? This is- this is not clear to me, like what exactly the target of this draft and why IETF should do it for- for IEEE, like it's access-specific things. Because this is the exact comment it was said when we tried to do cellular use case. I think we need to practice the same questions here.

**Sri Gundavelli:** No, Zahed, but- but at the same time, we published RFC 3314, we told 3GPP how to implement IPv6 in their networks, right? We published user documents. Uh, so this working group- this is exactly I wanted to hear from Sri, you like this working group need to understand like we can say some of the things without a normative things, but this working group didn't wanted to publish anything on that level. Correct, correct, correct. It's informative saying like, you know, this is what we think is the best. It's on not norm- a normative spec. We are not mandating as how IEEE should do it or any vendor should do it, but these are observations. It's a good- that's a useful document, it's good for the community. And see, at the end it will benefit SCONE, I- I think that would be my argument, yeah.

**Dan Druta:** Dan Druta. Actually, um I'm wondering if what you're- in your applicability, do you see any changes uh to the Wi-Fi uh specifications um as a result of incorporating this SCONE concept? And the reason I'm asking is because um one thing that you didn't uh display there, you had more enterprise Wi-Fi scenarios, but there's actually fixed wireless. Um, yeah. And the one that I'm more concerned is that: how do I propagate um SCONE via Wi-Fi um to a tethered device, basically saying, "This is- this is the advice that I got from the mobile network"? It kind of goes um and- gets- gets lost at the- at the- at the access point, so to speak, or the device that actually acts as- as a- as a hotspot. So I do think that um if there is something to talk about Wi-Fi is figuring out how that can be propagated um and- I think there are some ideas about how to propagate that, but that would go into the Wi-Fi Alliance to actually know that you're attached to a Wi-Fi hotspot that is a- a 5G or a- a wireless device, which is not possible today.

**Sri Gundavelli:** Uh, great discussion point. I think in general from the Wi-Fi implementation point of view on the northbound, it can be any type of WAN- WAN interface, it can be like you talked about the fixed wireless, it could be fixed 5G access, um but uh I- I think the rate calculation potentially you have to get that telemetry saying like, you know, "This is the link you have," right? And in your rate estimation, that plays out too potentially, right? I think- see, these are all implementation considerations. But one point I do want to clarify is like Wi-Fi Alliance or IEEE they focus on the air interface aspects. They don't look at systems beyond that link, right? So that's probably another reason why we should do this in IETF because we have a little bit the scope is not limited to one link or like, you know, we can look at as a any other routing element, look at on all sides and say, "These are the considerations," right? So that's my- my beyond this.

**Chen Wu:** Sri, we need to wrap up. So Marcus, can you make a brief, otherwise we can take it to the list.

**Sri Gundavelli:** Mark, you want to comment anything? You were not able to earlier.

**Brian Trammell:** I suspect that Mark is still having issues with his audio into Meetecho, because he's showing unmuted but no signal. So, yes, please take the comment to list. Thank you very much.

**Sri Gundavelli:** Thank you so much. Great- great- great feedback. Appreciate it here.

**Chen Wu:** Thank you. Let's move to the next topic. I think it's Marcus, right? Sri, you should stop sharing. 

**Sri Gundavelli:** Oh, I- okay, one second. Okay, I stopped. Yeah, sorry. 

**Chen Wu:** Which one is first? MASQUE? Okay, MASQUE first then. 

**Marcus Ihlar:** Hello. Uh, I would like to start by apologizing to everyone because I completely forgot that this was on the agenda, so these slides are very hastily made. Uh, but yeah, I'm going to talk about this. We- we- we brought this up on IETF 121 when we were discussing potential options for signaling throughput advice. Uh, we decided to park this because we wanted to focus on the main specification and the SCONE protocol, which is the thing we're working on and the thing we're focusing on in this group. Um, and just very clear disclaimer: that this document was not intended to be like a- a competitor or an alternative to the general SCONE protocol for general throughput advice signaling. We believe that the SCONE protocol is perfectly suitable for that and the better choice. However, there might be some deployments where you are running proxies and you want to rate-limit the traffic that is associated with proxying requests. For instance, you might have a proxy that is associated with your access network and you might be aware of rate limits and if you're running this type of proxy, you have the possibility to signal this using- using mechanisms within your proxied connection. Um, or you might want to enforce certain policies to your- that are specific to- to subscriptions to your proxy service. So you might want to notify clients that there- there is a- there is a maximum rate that you can get through this particular proxy service. Yeah, the way to do that is to send a capsule. We haven't done much work since- since IETF 121. We did a little bit of work, we took on Zahed as a co-author as well, but basically uh the difference between this signaling and SCONE signaling is that you could explicitly encode the uh the rate limit as a- as a number. You don't need to map it to a table because we're not space-constrained in the same way. We're relating a little bit back to the previous discussion because we're not constrained for space here. We- we also have the possibility to indicate uh whether a advice applies to uplink, downlink, or both. Uh, and in this particular case, it is uh it is more needed than it is in the SCONE protocol because here we're only communicating between a client endpoint and the proxy and not uh there is no communication going all the way up to the- to the server. There is an optional field for- for average window, the idea is that it should be defaulted to 67 seconds as specified in SCONE, but you might want to communicate something different. Um, how throughput advice are used by clients is somehow out of scope, at least for now, but things that you could use use this information for as a client of a proxy service could be to apply some backpressure to- to whatever application or upper layer thing that is uh sending traffic uh through this client. Uh, you could forward as a client you could forward this information through some out-of-band API or control channel to- to the applications that are making use of your of the proxying. Uh, or as a client you could adjust sending behavior on behalf of the application, but these are like, yeah, there are ways you could do this, we're just briefly touching upon it in the draft and we're not trying to mandate anything.

**Marcus Ihlar:** Uh, there are some interaction with SCONE considerations here, and some of that might be something that actually should go into like a more general discussion uh in an applicability document or wherever we do those discussions. Uh, but some things here like, you know, for instance a proxy may observe end-to-end SCONE packets on proxied flows. Uh, and if you are signaling throughput advice using your- your proxy channel, you should probably not be modifying the- the SCONE packets on the end-to-end channel because that's that- that might refer to a different scope than uh than the one you're trying to signal, but on the other hand then clients may get throughput advice from two sources and need to handle that. There's also in this document there's some short discussion on uh the interaction and this is something that probably doesn't fit in this document but rather fits in some applicability document or something. There's some interesting interaction between end-to-end use of end-to-end SCONE and the QUIC-aware forwarding extension that's defined for- for CONNECT-UDP. And that is that uh that draft or that document currently says that long header packets are always sent in what is called tunneled mode. So this QUIC-aware forwarding is an optimization for MASQUE proxying where you basically uh once you have established that- that you're running QUIC over your proxy connection, you- you don't have to encapsulate all your- your QUIC packets into full HTTP datagrams, you can send them kind of uh unencapsulated. You're just fiddling with some- some- some connection ID headers kind of, uh but there is that draft specifically says that long header packets should always be sent in tunneled mode. So if you're running this type of proxy service and you start seeing SCONE packets, that means that some of those packets will just be- most probably be uh tunneled. And that might be something you're not expecting as- as an operator of this type of proxy service. So that might be something just to discuss or, yeah, anyway, that's- that's one observation that we made here, but maybe this is a discussion better suited for some other document.

**Marcus Ihlar:** So, uh a couple of questions for this working group, like is this work relevant for anyone in here? Is there any appetite to work on something like this? I would think that would be very useful for us to know, uh and if people think that there is appetite, is this the right venue to do that work? These are some questions we'd like to- to get from anyone. Yeah, Christian?

**Christian Huitema:** Good evening. I mean, nice to speak you- to you on a Friday. But- sorry. Uh, it be- mean if you look at the- the various service that define MASQUE, MASQUE defines a number of services over MASQUE and those services will have different way of handling SCONE information. Like if you do IP over MASQUE, for example, you're passing an IP packet and if that IP packet happens to have SCONE content, you'd never know. Uh, the interesting part is probably the UDP service, as you mentioned, especially the UDP CONNECT and the UDP-aware service. And if we do anything, it will be something like, okay, study how SCONE passes over UDP CONNECT and is there a hotspot and should we- smoothen that hotspot? That would be pretty much what- what I would say.

**Marcus Ihlar:** Yeah, that makes sense. And do you think that that is something that would go into like some applicability document, uh not as a document on its own, or do you have any opinions on that?

**Christian Huitema:** I think the proper way to do that is to actually publish the SCONE document and then uh have the- the MASQUE working group say, "Hey, we may want to do something about interop there," and do that in MASQUE because it's, as you say, it's probably something about how to compress or encode or tunnel that particular packet and that looks like MASQUE.

**Marcus Ihlar:** Okay, makes sense. Thanks.

**Mirja Kühlewind:** Mirja Kühlewind trying to join the queue. Ah, we have a queue. I wanted to reply to Christian very quickly. So this is actually an alternative signaling that is proposed. I mean, you- it can happen that you have end-to-end SCONE packets uh and then you don't care about them that's- but this- this draft proposes a MASQUE extension to signal the SCONE rate signal in a capsule.

**Christian Huitema:** Right, but it is also the discussion here about what how to handle- No, I'm not mixing. I'm saying, hey, we probably don't need to do a SCONE-specific stuff, we already have all the tools we want.

**Mirja Kühlewind:** So the- yeah, the use case behind this is that if you already have MASQUE deployed, then maybe that's just easier to use MASQUE instead of deploy SCONE. If you have SCONE deployed and MASQUE, whatever you can do both. But if you don't have SCONE deployed but you have MASQUE deployed, that might be easier.

**Christian Huitema:** Yeah, okay. So take my vote to say that don't do that. Just pass SCONE inside of MASQUE and that seems more robust and easier to define.

**Mirja Kühlewind:** Um, I mean I- you know, I think that will happen as well, but then you actually need to- pass the IP packets in the- in the MASQUE proxy. So it's actually also, I mean, it's probably not complicated, but it's also not necessarily easy.

**Lucas Pardue:** Yeah, so um in my mind, one of the reasons I was interested in SCONE is because of MASQUE proxying, like I'm- I'm not a network operator and all of all of that stuff, all of that jazz. Um, so to me, a MASQUE proxy always was a network element and I'm glad that the proposals or what we've come up with um and the architecture of SCONE allow it to be. Um, I- I'm- I'm not understanding necessarily why the- the SCONE signaling that we have doesn't work for a MASQUE proxy uh at least in the UDP and IP modes. The only thing I can see is it wouldn't work for CONNECT or- CONNECT-TCP, but so what? Like use a- use a new protocol and then you get the better features. So in summary, like maybe the idea of having a MASQUE proxy apply limits and stuff is relevant, but whether the capsule to achieve that is relevant, I think I tend towards "no." But that- maybe if there was more data and evidence that trying to use SCONE in MASQUE doesn't actually work and that there would be people interested in a capsule... like, it seems we need a bit more information along that line to my mind, at least. Because otherwise, it's just another way of doing a different thing and now we've got to do twice that work and it's- it's annoying.

**Marcus Ihlar:** Yeah, that's- that's super good feedback as well, and- I think that's a reasonable way forward to see how far we can get with- with the SCONE signaling we have before we start doing more work. But, yeah. Do we have any more opinions?

**Dan Druta:** Dan Druta. Actually, I think the issue with having multiple ways of doing the same thing is that it's going to put some burden on the clients. Fair point. Okay. So any other comments? So move to the last as well.

**Marcus Ihlar:** All right, next thing. This is not SCONE, it's just inspired by SCONE. We're not asking for adoption in SCONE, we just want to kind of- bring- bring some attention to- to some work that we're doing that is inspired by- the way we're signaling information in SCONE and, yeah, see if you have any feedback on- on these things. Um, so, yeah, we- we've been- working on bits for a long time related to- to end-to-end encrypted transport protocols. There are a lot of desire to measure things like delay and packet loss by- network operators for a multitude of reasons. Um, the spin bit was defined for RFC 9000, it can be used to measure round-trip delays, it is not widely deployed for various reasons, uh but it is there. Um, but yeah, there's also desire to measure packet loss, there are some desires to- to- to improve the accuracy of- of- of delay measurements and so on. Um, and- some of this resulted in an RFC defined in the IPPM working group that describes a- protocol-agnostic measurement techniques using explicit bits in packet headers. So it's really like ways endpoints could expose certain signals to the network that allow the network to- measure and estimate a number of metrics such as round-trip delays, upstream and downstream packet loss, and things like that. Um, since this RFC was published, there has been some attempt to map these uh bits onto uh QUIC, uh and that resulted in- in this draft- quick-explicit-measurements, uh and initially this draft was focusing on like how can we get these measurement bits into the- kind of QUIC version one header as it looks right now. And the motivation for this, yeah, I said it already, but- diagnostic measurements, benchmarking, troubleshooting, uh you typically want- I mean, a lot of operators already have a lot of measurement infrastructure and telemetry infrastructure on the various lower-layer um technologies that they make use of, uh that is very useful, but sometimes for both benchmarking and troubleshooting purposes you want to- to- to be able to tie measurements to- to active application sessions to- to understand more about what an application is experiencing and what segments of my network is kind of causing that level of experience or, so, yeah. These are some motivations for this.

**Marcus Ihlar:** Um, and just a quick recap of uh what was defined in this RFC 9506, it defined a- number of bits that you can use uh with- with different algorithms to- to measure different things. So it mentioned the "S" the spin bit, which is already defined with an algorithm in RFC 9000 that allows you to measure round-trip times, end-to-end round-trip times if you are a- a unidirectional observer, meaning that you can only see packets in one direction. If you see packet in both directions, you can uh also estimate half-RTTs, so the RTT between the measurement point and the upstream server for instance and the measurement point and the downstream client as an example. Um, impairment resilience is low, etc. Then there's a "D" delay bit that is slightly different, it uses fewer packets, it can measure the same metrics but it has other properties on being more robust to- to impairments and so on, and these can be combined to be even more robust. Then there were a number of uh bits defined for- for packet loss measurements, uh some of them are directly uh um taken from- from previous work in IPPM working group that is called "alternate marking" where you basically create square waves that- that you're counting the number of packets and then you can estimate the upstream loss based on that. There are also some bits that allow you to- to estimate end-to-end loss by- by having endpoints set a- a loss event bit you can say. I'm not going to go into details here. If you're interested, we have Giuseppe here who is a measurement expert, so if you want to talk to him, he's around a little bit longer. But anyway, let's- move forward, this was just a recap.

**Marcus Ihlar:** But okay, initial attempts were trying to map this onto QUIC headers and we have a problem with real estate. Basically right now there- we the spin bit is in there, uh then there are two reserved bits and if you want more than that you're screwed and if you only put two more bits in there, well, then you take up all the space of the- the header and these- bits cannot be used for other purposes. Another issue is coordination and detection: say that, okay, say that we map these bits into this header, but we have some problem that these V1 header bits are greased, uh meaning that they typically from the perspective of a measurement point, they tend to take up random values. So you would need to do some- and also they might be used by other extensions for- for other purposes, right? That- that's a possibility. Uh, so if you want to detect whether bits are used for measurement or not, you need to do quite some work just to see that these are actually- this is a flow that is flipping the bits in the way I want to- that I would understand as- like something that allows me to measure things. And that might not- might not be very straightforward.

**Marcus Ihlar:** Um, so the solution is to be inspired by SCONE and uh that's what's proposed in this draft. So basically uh instead of putting these bits into uh the- the well-defined QUIC version one header, uh we follow the model of SCONE where you use a dedicated long header packet with a specific version number that is easy to detect. So it's easy for a network element to- to detect that this is a measurement session. Um, that also gives you six bits of payload in the first octet, uh so you could fit a number of bits in there and define which ones are useful. Uh, and of course then the QUIC endpoints would need to announce support for this, uh using transport parameters, uh and then these packets would be inserted in front of regular QUIC packets uh in the UDP datagrams, having the same properties as SCONE that you need to have the same connection IDs on these outer packets as you have on your inner ones so that you can ensure that uh the packets are correctly routed to the correct endpoints and so on. Uh, some motivation for this: uh an explicit measurement layer removes the need for reserving space in the QUIC short header. Um, they're easy to identify like I said, and uh it also follows some of the traditions of lower layer measurement mechanisms that- that has been defined in IETF, we where we typically define extensions and encapsulations to- to protocols like examples of this would be like IOAM for IPv6 and MPLS, uh alternate marking in these kind of things. So- so this kind of follows on that in- in the same spirit even though it's on higher layers. Um, this is an example of how such a packet could look, but that's not really the interesting part right now.

**Marcus Ihlar:** Um, there are bunch of issues and trade-offs with this: of course, if you do measurements like this, it means that you need to put this packet in the- in the front of your UDP datagram and that inflates it by at least uh eight octets I think, and it could most probably be larger depending on how, you know, what connection IDs are used uh in the end-to-end flow. Um, there is also an interesting uh topic here around integrity. So here's a property where it's very different from SCONE because in- in the case of SCONE, we explicitly want the capability for networks to modify the bits in the header where in this case the bits are inserted by the endpoints and should not be modified by the network. So um you might want to consider some mechanisms then for- for protecting these bits, probably only between the endpoints, uh but uh you could implement some- uh tampering detection of course that would add some overhead and complexity, but um you know a very simple way would be because this is such a small payload, would be that you- you replicate that inside a protected frame or something, but this is something that needs to be considered. Um, of course like with the spin bit and any mechanism like this, there is a risk for fake or skewed measurements. Endpoints can decide to for whatever reason they want to uh generate false अह results by setting bits that are not set in accordance to these algorithms. So any measurement point needs to be robust against that and most likely not trigger direct network- policy actions based on these measurements. Uh, of course there's a number of privacy and security considerations you you need to think about. Um, if you have sessions like this, they are very clearly identifiable. If you see these packets, you would know that this is a- this is a measurement session and, you know, on-path adversaries can use that to track user behavior, uh they could also specifically target measurement traffic for various reasons in order to disrupt operators, uh influence benchmarking results or or what not. Um, some other open issues that we have thought about: like this could be uh a possibility to remove the the use, the need of having a spin bit in- in these short headers like if we define this explicit measurement layer instead. Um, also some other interesting aspects here is that some of these bits require that you use them- that you set them on every packet for the algorithm to work, whereas others require less frequent marking. And an interesting topic would then be like, could you negotiate specific methods depending on whether you care or not about inflating every packet? Uh, and yeah, I think that was the last one.

**Marcus Ihlar:** So I'm not asking for adoption here, I just is kind of bringing up that this communication model potentially opens up for other pieces of work and most probably this is something that would need and some feedback we got and I agree with that this if this is interesting to people, this might be something that we want to bring up in a- possibly new venue, possibly a BoF or something like that. But yeah, it was mostly a heads-up on this and if anybody has any input, feedback, or comments on this, I'd be happy to take that. Yeah, Christian?

**Christian Huitema:** So, uh the same feedback you got from me before only now with a visual aid. I- I think we really don't need to- have- have this come out again unless there's enough interest in a community to actually run a BoF, uh because I think at that point we- we might have more than one use case to discuss and the set of concerns would get the right people in the room. Uh, I agree with- with Brian and I did say in the- in the quick chat uh that SCONE itself would not have flown years ago and the fact that it is- getting authentic consideration now means that people may be willing to work on this, but I also remember spending 18 months of my life trying to get the spin bit through and then finding that nobody used it. So defining this and finding a way to deploy it are- um going to be challenging. Yep, I- I want to encourage anybody who's interested in following up on it to prepare themselves for quite a bit of time. Yep. That's a very good point. Thank you.

**Chen Wu:** Any other feedback? I think we can wrap up. Right. Thanks a lot. Yeah. So I think, yeah, so Brian you...

**Brian Trammell:** Uh, yeah, I wanted to come back to uh some of the conversations we were having about applicability and manageability. Um, I think what we've heard is uh there is some desire to have a little bit more text in that document, um and that we'll have to make a decision about merging versus publishing together um once we have that text in. So my suggestion would be that we set sort of end April, start May a- an interim uh meeting for specifically the applicability manageability discussion, and the intention would be is please get your PRs in for that document by that meeting um or uh you have missed the bus. Uh, another thing I've heard a lot is a desire in this working group to be done in or for Vienna. That would be the point of having that meeting sort of like end April, begin May, um so that we can then also get um some feedback from the uh operations directorate uh reviewers or from one of the- some of the operations working groups on sort of like the, "Hey, here's the document we have with all of the merged stuff, what do you think about this? Is this a- is this a guide that you would use? Is this- is this guidance useful?" Um, unless there are strong objections to that as a plan, uh I will go ahead and um send out some suggestions for dates and times for those, get those interims scheduled, um and uh drive forward to getting done by Vienna. So I'll wait for anyone to come into the queue. Now, okay. We don't hate... ah, no, it was a... I- I just closed like the- the my on-site tool so I- I'm not able to join. I think that makes a lot of sense to me and let's go to- let's do that. Yep, timeline looks really good for me. Yep. Yep. Expect a- um expect an email to- me from the list before you all land in wherever you are going back to. Cool. All right. With that, um I hear the church bells ringing, which means it's 9:00 here, which means it's 5:00 there, which means that was the IETF 125. Thank you very much for joining us and we will see you at the interim.

**Chen Wu:** Thank you. See you in next meeting.