**Session Date/Time:** 22 Jul 2026 09:30

[00:03:35] **Gorry Fairhurst**: Hello. This is WIT area. So take a seat if you're coming in and welcome. This is the area meeting for the web and Internet transport area. We will divide our meeting time into roughly two parts. Do you want me to fly or you want me just to talk louder?

[00:04:04] **Brian Trammell**: Talk louder.

[00:04:05] **Gorry Fairhurst**: Oh, easy. Right. I could easily talk louder, but flying is really hard. So Brian made an unhelpful comment for the notes. Okay. Our notetaker is Martin, but we're going to try and generate the notes automatically. So Martin is on hand should the power go out but the lights remain on or something. We have our agenda split into two parts and it looks like this. And first of all, welcome. I'm Gory Fairhurst and this is

[00:04:42] **Mike Bishop**: Mike Bishop.

[00:04:45] **Gorry Fairhurst**: So we're at the WIT ADs. You're very welcome here and you're very welcome to talk to us during this meeting by the mic line or after this meeting should you have any questions. We do have a meeting on Sunday, each IETF. It's in the meeting agenda. It's a time where you can come and talk about any draft or any working groups, so take advantage of that if you can or wish to next IETF. For the moment, we're going to send the first slide deck looking at current working group activities across WIT, and the second half in a different slide deck where we'll review the particular subject of foo over quick. Mike?

[00:05:29] **Mike Bishop**: And, of course, we will start with the. I imagine you've seen it several times already this week, but these are the policies and procedures that you've agreed to by joining the IETF for these sessions. If you don't agree, please don't participate. And I see, Ted, you're requesting to share slides. Is there okay. Thank you. Alright. So within our area, we have a collection of 18 working groups and two directorates, in some ways a legacy of the formation of this area. There are two of us, and we have a bot this time around.

[00:06:15] **Gorry Fairhurst**: And the bot is called?

[00:06:17] **Mike Bishop**: We had PTTH earlier this week. It's the second time around for the reverse HTTP effort, And I think it went pretty well. If you weren't able to be there, check out the reporting.

[00:06:33] **Gorry Fairhurst**: So this is the set of working groups that I'm the responsible AD for. They mainly relate to transport protocols. And if you have new work for these working groups that you'd like to discuss with an AD, then I'm the person to talk to. We have been doing work. We have some documents past working group last call. Stream reset is known IETF re review. And NFS v four, I always find that hard, is going to IETF last call very soon if it hasn't already done so. We have some documents post IESG review, and I'm hoping that these are relatively easy to clean up based on the discussion comments that the IESG have given, So we don't expect further trouble with publishing these ones.

[00:07:30] **Mike Bishop**: And then these are the working groups that I'm the responsibility for. It's worth noting given when we were talking about new work a moment ago. So dispatch, which had previously been only for art area but was frequently co co meeting with sec dispatch for the sec area, has been rechartered to cover art, sec, and portions of wit where it's not obvious where your work should go. So if you have something that is squarely about an extension to QUIC or to TCP, you know the appropriate working groups. Take them to the appropriate working groups. If you have something that seems like it may be in the WIT area, but it doesn't squarely fit an existing working group, it's not a particular transport topic, that's gonna be going to dispatch. And they can if you have questions about what falls into which category, you can always speak to us. We're happy to help with that. So these are the working groups that I'm responsible for. We have a number of drafts that have come from the working group to the ADs in the past cycle. We've got one on the tele chat, couple of last calls that are crossing this week or have just ended. I think a few of these ended just before the week started. So we will be making and getting these through. And we've had several drafts come out that have been approved by the ISG and are now with the RFC editor. I'm glad to see a lot of these progressing. A few few blocked in the queue with missing references, but we'll get there. RFC has been published this time around. We have four. I'm particularly proud with the HTTP QUERY method because I'm not responsible at the author, but actually author. We already talked about PTTH. So we have two directorates in the area.

[00:09:49] **Gorry Fairhurst**: Magnus, you can talk about this.

[00:09:54] **Magnus Westerlund**: Magnus Westerlund, Ericsson. But here, I'm the secretary for the Transport Air Review team. I do triaging, selects which documents we actually think we should review out of the ITF last calls and Telechat reviews, which is automatically suggested. We also get these days a very positive, nice number of early review requests. So we also do those for working group shares, etcetera, in other working groups who needs want to check with us that we think it's okay on the transport related stuff they might have included. So we have reviewed 16 documents since last ITF meeting. So basically, that's one document per person in the review team, basically. We have, I think, we are 18 or so reviewers at the moment. We do have room for more persons if you're interested in doing this and have interesting skills. There are always particular areas of that could be have more people available that should be able to review certain transport related aspects. So if you're interested, do send an email to TSV Triage. We also have a common issues Wiki, so which contains useful information for people.

[00:11:26] **Mike Bishop**: And, Magnus, what are the particular areas of expertise you're looking for right now?

[00:11:30] **Magnus Westerlund**: I don't know if I'm looking specific one, but, yeah, it's let's see. I have a fair amount of people on the which has real time media, so that I don't need. I think it's intersection security. I might need a bit more maybe congestion control would be good. So

[00:11:58] **Gorry Fairhurst**: So one of the things I should need to give thanks for the team for is when documents are sent to to review, they go through this triage process. And we do try and find reviewers who have expertise in the area. So this is not a call to know about the whole of transport. It's if you're a expert or understand one part of the transport puzzle really well, then you'd be good in the review team and you won't go and get landed a young model for QOS or something just because you're on the review team.

[00:12:29] **Magnus Westerlund**: Yeah. Yeah. You sometimes might get a bit of, I mean, more wider field that but it's usually, like, expected to what you you would you know. So but yeah. Yeah. I mean, we can if you have a fair general understanding, works out well also, yes, that you can point to and have read UDP guidelines and a few other of our various documents to understand where where the kind of issues might lay. Just to flag things is probably most relevant. I mean a lot of the reviews is actually the early reviews goes to the working group and etcetera directly. But most is actually to support the EDs on noticing things that might need to discuss this, etcetera, to or have to be dealt with before. So And

[00:13:17] **Gorry Fairhurst**: this is the current review team just for transparency. So TSV Art is just one of the teams. The other team is the HTTP directorate, and that's Mike's work.

[00:13:28] **Mike Bishop**: So we also have this directorate to provide reviews and guidance on how to build protocols that interact with HTTP because we we find that that is sometimes challenging if HTTP is not the world you live in. If you have some other protocol and you're trying to build on top of or send it over HTTP, it's not always obvious how best to use the many, many tools that HTTP affords you. So this directorate does reviews and consultations when working groups ask for it or as things seem necessary as they come to last call. It's a smaller directorate. Mark Nottingham is the secretary, and we have several other reviewers. We would like to do more early reviews because it is really hard when we get to the ISG review and discover that there is a fundamental issue with how something is interacting with h t p that really should have been sorted out at a much earlier draft. No one likes having that happen, especially not the AD who has to put a discuss on it. So if you are using such a protocol, please request early reviews.

[00:14:46] **Lucas Pardue**: Lucas? Sorry. I didn't go in the queue yet. You're missing Ben from that list. Ah. So thanks, Ben.

[00:14:54] **Mike Bishop**: Thank you, and we will fix that. So the the next piece on our agenda let me switch slides here. There have been a lot of documents recently dealing with, like, how can we put things over QUIC in particular because that's the the newest in the transport staple. And as with mappings over HTTP, sometimes they take good advantage of the features that are there, and sometimes that is less so. And sometimes they have particular goals that they're trying to achieve by using QUIC, and sometimes just someone has said we should do this over QUIC, and they are. So we thought we might take a little bit of time to gather some of the expertise in the room and talk about what are the considerations when you're trying to pick a transport for your protocol. And in particular, to quick, what are some of the things that you need to be aware of when you're trying to build on top of it. So not all transport mechanisms are equal. Sometimes you can build a protocol directly on top of UDP, and sometimes you build a protocol directly on top of UDP and then discover, oh, but wait. We need a security story. And then we need a congestion control story. And we need a reliability story because sometimes datagrams don't arrive. And by the end of it, you build quick.

[00:16:41] **Gorry Fairhurst**: Or maybe you don't. But you should have looked at all these things. Yes. So, I mean, this is not preaching to people who probably don't understand this. But the point is that when we get a UDP document, we have, like, UDP guidelines, which are first point of checklist of these things should be in here. And there are more as well, but it's a good starting point. We have some other guidance that the review team is using, but we don't really have a guidance list for how you put a new protocol on top of QUIC that's not HTTP. And HTTP is one solution. QUIC's one solution. TCP, STTP, RTP. I didn't include DCCP, but I could have done. Basically, there are choices to be made here in which IETF transport you are going to layer on top of. I guess as ADs, we're hoping that you don't actually do RFCs for each of these, that you actually choose the ones that actually match the thing you're trying to transport. So the first thing is choosing the right protocol to transport your data over. And where we're going to talk mainly about the two red columns, the UDP versus QUIC here. Assuming that if you already have it over TCP, then it probably is okay. Right. Next slide. So UDP is something that just adds a tiny header and creates a lot of problems when you then write an RFC to use it. Provides a very small set of features and of course, you should read RFC 8085 because it helps. And there are big dragons lurking out there ready to get your protocol spec when you don't think about how it works across the internet with reordering and loss and intermittency and other things that might happen such as congestion control. And

[00:18:51] **Mike Bishop**: so if you're able to use a slightly higher level protocol, you can reuse a lot of the work that's already been done and take advantage of that. So quick is version one and version two, although version two is somewhat limited in deployment, Provides you a lot of these pieces that you can take advantage of. It gives you multiplexing. It gives you optional reliability. It gives you a security story. But also there are cases when you may not need everything that Quick gives you. And, Lucas, did you wanna

[00:19:32] **Lucas Pardue**: Yes. So the area directors kindly volunteered me to kind of talk to some of the aspects of Quick as a Quick working group chair, but also as a application mapping enthusiast. That's the reason I was primarily brought into the QUIC working group in the first place to make sure that the transport service that we were defining made sense for my particular focus of HTTP, but others too. And I think it is two mindsets that I see in using QUIC, which is the the connection oriented features, the security, but also things that QUIC provides that other transports maybe don't as well, such as connection IDs and ways to do cleverer or or more efficient closures, etcetera, etcetera. Cool. Part of the features are we'll go into some of these. Right? So single well, TLS 1.3 handshake, which means it inherits a lot of the capabilities that are are there for TLS that we might be familiar with. Yes. We got DTLS, but I'm gonna pretend that doesn't exist right now. We have a single connection as a single congestion control context. That's a bit weird because we've we've just dispatched multiple paths for QUIC where each path would have a congestion control context. That's something else people should be thinking about if they wanted to go down a multi path route, which is probably a whole day of cool talks. But again, we're not going go into. We have flow control, connection and stream level flow control that interestingly don't apply to datagrams. And the reason being because that helps emulate the behavior of using raw UDP, say. So you get the message oriented semantics that you would like for delivering application data, which I'll go into on the next slide, if I remember correctly, but not yet. Oh, and we've got migration, which is, you know, understood commonly as one of the killer features of QUIC. In practice, the deployability story there varies, in at least in the world that I'm familiar with. The protocol works, but some of the aspects of kind of the deciding so so a lot of this is what I would call an exercise left to the reader. Just because you can do all of these features of QUIC, there's a lot of work still remaining to decide how your deployment does things. Are you controlling kind of both ends of a client? Is the interop story very diverse. The environments that these things are installed into mean that you can maybe not predict precisely how one end would work. But, yeah, if we go into the next slide, please. Effectively, what I care about most is the transport interface for application data. While QUIC can provide that interface, it's really unopinionated about how applications drive it, which is something I've seen that can be surprising to application mapping developers, depending on the complexity of the application that they're using. So we have quick streams. These are logical byte streams. There's like four of them, depending on this combination of being client or server initiated and whether they're bidirectional or unidirectional. So that's which endpoint in a quick connection, because there's only two, has initiated the streams, obviously, and and whether they exist in a a pair. You I could talk again a lot about the state machine for those streams and how they're kind of modeled as two independent send and receive models, which gets more complicated when you have a bidirectional stream. I'm going to write a blog post on this in the coming weeks because I've had to explain it a lot to people. It's not hard. It's just surprising and takes some work to go through what that means. And the reason it's surprising is that unlike TCP, there's semantics that allow both closing the stream or the send side of a stream, resetting the send side of the stream, but also something that's a bit unique to QUIC, which is the remote peer can ask you to stop well, to reset your side. And that doesn't sound that hard. And it's not practically from quick perspective. But it raises a lot of questions if you're an application and you're not used to the fact that the reset might happen under your feet. And something we're probably not going to go into today, or maybe we will, but the the kind of the there's not a single API for quick implementations. So their approach to surfacing that level of information may be surprising to you. And while that be something we would love to solve in a general abstraction, not quite there yet. You know, we've had quick deployments for years now. The protocol works itself, but we're still figuring out some of these issues. So if you are doing foo over quick and we have some guidance about the applicability, but you're hitting something that is maybe not working so well for you, that might just be because we haven't learned the lesson yet and written the guidance or understood as a community. But anyway, we should probably move on to the next slide for time. And while we have these byte streams as a core part of the the protocol, RFC 9000 quick version one, and any compatible version of Quick with it, we added a this message oriented Datagram extension shortly after, I believe, which is a it's not flow controlled, but it is congestion controlled. And again, that might be surprising for people who are coming from a, well, I'll just use UDP to deliver these things. This is the benefit. It means that within a single quick connection, you can multiplex streams and datagrams. And the relationship between those things is not necessarily as tight as you might think. While we have a notion in the RFC 9,000 about streams and that implementation should allow prioritization of them, although there's no defined mechanism for that. It's kind of an implementation specific thing and a lot of us are aligned around a certain model. Datagrams doesn't strictly fall into that. There's no multiplexing of datagrams built into QUIC itself. This was an open issue we discussed during the time. I think the initial proposal did have a multiplexing identifier in there. And we decided as a transport service, there wasn't much more that QUIC could provide with that. So it's often delegated to the applications. And that's a real kind of rake to avoid. If you need that kind of thing, there's various ways you could do it. And when we're going through the exercise for for HTTP, when it's using datagrams, we've defined RFC 9297, which uses a variable length integer. That doesn't necessarily apply to every application that might want to use QUIC. There could be a more complex data structure that helps it do more efficient multiplexing and routing. If you're to run something tunneling over quick, say, multiple different contexts, whatever, your needs might be different. So wasting bites on that, not so great. Hence, why we've gone with the approach that we have today. Yeah.

[00:26:57] **Gorry Fairhurst**: So

[00:27:01] **Mike Bishop**: one of the advantages of building to the structure, this idea of there are connections, connections contain a collection of byte streams and also messages, is that you have more or less the same conceptual surface between QUIC, web transport, and QMux, which is coming out of QUIC, which maps that onto a TCP session. So if your application can interact with the layer below it using those primitives, then you are in the process of being able to run over any of these things and swap them out. And mock, for example, is building on top of QUIC and defining both QUIC and web transport mappings using these same logical pieces.

[00:27:56] **Gorry Fairhurst**: And there again, there's TAPS as well, which tries to bring the various transports together and provide a high layer API. So there are a choice of different API services here. And I guess this is the start of the slides that are meant to create discussion in the room. So it's okay to ask questions or contribute more to this as we go through. Please do.

[00:28:24] **Lucas Pardue**: Magnus, that's good. Just before we get to Magnus, would it be worth expanding a little bit more on what QMux is?

[00:28:30] **Gorry Fairhurst**: Well, let's not forget Magnus, and you expand after Magnus.

[00:28:34] **Magnus Westerlund**: Okay. Magnus Wesseland, as Mark here, I do want to expand on our working group choice between Rawquik and WebTransport. And I mean, this is to serve two different and I think the working group is quite aware that they are have share a lot of similar properties, but there are some important differences. And this really gets into when you start doing certain things, and especially when it comes to cross layer stuff. Because when you're in the web browser and have only have web transport, you have a certain API. In RealQuick, you have maybe more availability, certain fine grained information, which the current web transport APIs will not give you. So these are important aspects when you start digging deeper. But for high level semantically, you might have this very similar experience.

[00:29:29] **Gorry Fairhurst**: That's probably an interesting conclusion for most of these, And

[00:29:33] **Lucas Pardue**: to respond to that point, I think some of this, if if you're approaching like, should I use UDP? Should I use QUIC? Should I use what real quick say or web transport HTTP is? How much of the batteries included do you need or want within your context and your domain? And we can't necessarily tell people what the right answer is for them. But sometimes when things are complex, people tend to do the simplest thing, is I'll just use RealQuick for now. And then a significant effort might be required to rebuild some of the capabilities that you would get for free from the other things. But with the QMux, I just wanted to go into a little bit more information. I think there's two things that would be relevant to this group, which is if you're using QUIC, you may be in an environment where that doesn't succeed because it's running over UDP. And there's various reasons why those don't go through. Some of our documents go into the potential need for a TCP based fallback. So if you're using QUIC and all of its powerful features, and you do need to fall back to something over TCP, what do you go to? It could be that you have an application mapping that runs over TCP already, and it's then you can just fall back to the older thing, fab. If not, and you were doing something like HTTP, and operating at its semantic level, and you were using h three to get the benefit of QUIC, and that doesn't work, you can fall back to h two, and it's fine. If you're in the middle where you don't really care about the HTTP semantics, but you wanted to have a multiplexing layer over TCP to maintain your application interface of all of these multiple streams with bidirectionality and either endpoint being able to initiate them. The kind of previous option was to try and use H2, which provides some streams, but also comes with all of the HTTP stuff bolted in that you can't pull out easily. You end up having to sidestep. So QMux is an attempt at porting or polyfilling or however you want to phrase it, the stream model, one of the most powerful things about QUIC back to TCP, so that as an application developer, you can just consider things in that domain and worry less so about more glue and more middleware to translate between, oh, this is quick streams model, this is HTTP model, or this is my my own hand rolled multiplexing layer within TCP or or any reliable byte stream. And this is adopted work in a quick working group. If you want to know more, come to the session later today.

[00:32:07] **Gorry Fairhurst**: And there are some RFCs that could help. Most people probably have know these exist, but I'm making a list just so that people are aware and people can find different ones of these depending on your perspective. One or more of these is probably going to be more relevant to what you're trying to do. Do you wanna say more about these? Or it's just a list of RFCs?

[00:32:36] **Mike Bishop**: So I think it's you it's worth pointing out that each TCP has its own BCP of these best practices for building on top of it. And a question that came up during the development of QUIC was whether we need a similar BCP for best practices for protocols on top of QUIC. Now there's the applicability and management, RFC, which covers a lot of that, and Brian is here in the room with us who helped offer that. And I think I saw Miria, but maybe not right now. She was outside when I came in. So they they worked on that, and they are and that is a large portion of the way toward that guidance. But I think there's an open question as to whether people who are building on top of Quick need more guidance as to what they should do. And so if you have thoughts on that, we would like to hear that. And if you have the start of a draft in that area, we would love to see that.

[00:33:50] **Brian Trammell**: Ted Hardie. Ted, I do think it would be valuable, but I think we'd have to be very, very careful. As you know, QUIC has a set of characteristics which it guarantees will be present in all versions. But that is not necessarily the full set of characteristics of any particular QUIC version. And indeed, there are specific characteristics of QUIC versions which might make them attractive for a particular use. Or it might be possible to build a version of QUIC which meets a specific use case by adding new features to the features which are guaranteed to be present in all versions. So writing such a document would be a little bit different from writing, say, what do you do on top of HTTP? Because HTTP semantics, this point, are meant to be relatively fixed, compared to where QUIC is. And the difficulty, then, would be saying, Okay, what are the design spaces for what's in the core pieces of QUIC, which will always be present, versus where can you innovate if you need something different from QUIC? Now, if you're simply trying to build on top of one of the versions, obviously you need to be limited to the characteristics of that specific version. But we're really trying hard not to ossify quick. And I do want to make sure that if you do write such a document, it doesn't have the effect of ossifying the understanding of how QUIC works to whatever versions were available when the document was written. Thanks.

[00:35:29] **Gorry Fairhurst**: Yeah. Thanks, Ted. That was helpful.

[00:35:35] **Yaroslav**: Hi. Yaroslav. A statement and perhaps a question. So I think there is another option for protocol designers on this in a spectrum of options. Between QUIC and web transport, there is an option to build your protocol on top of HTTP, which I don't think was listed, but it's also could be potentially very attractive option, kinda maybe easier than web transport and more batteries included compared to just building things on top of QUIC. And another what I think is important consideration that I'm not sure if it's reflected anywhere is ossification protection, that is stickiness. So if you build your custom protocol on top of UTP, then some middle boxes on the Internet might not like it. If you build your protocol on top of QUIC with your own custom LPN, again, maybe a bit it's more likely to succeed. But if you build on top of HTTP, then it is very likely to succeed. And I think this is another consideration then that people would have in mind. So is there a plan to have this presentation as a draft or some kind of VCP guidance for protocol designers? Or is it will will that be just the presentation here?

[00:37:04] **Gorry Fairhurst**: I don't think there's a plan, but you mentioned the concept. I think as ADs, what we would love is to evolve perhaps a checklist of things that should be thought about when you design something. And that might not even be an RFC. It might be a Wiki page initially until we get this into the right shape that is useful to the community where it's directed and also offers the right advice. And the things that you just said like, can you do it over HTTP? Is that actually the easy way for you to do things? Maybe we need to order these questions because if the answer to that is yes, then you don't have to learn about any of the strangeness of how you do flow control, different APIs, different options, what might be in the stack as optional versus required, etcetera. You just use it. So maybe we need a checklist, but it might also have to be a little bit ordered to let people get out of reading the whole checklist because they find an easier solution on the path.

[00:38:04] **Yaroslav**: Thank you.

[00:38:09] **Brian Trammell**: Hello, Brian. Hello, Brian Trammell. I feel like I was summoned to the microphone. So yes, very much to a checklist. One of the things that I've seen as a port reviewer is I get the distinct impression that people are taking clods and saying, please build me a protocol to do a thing. And it's building the protocol to do a thing. And if we write stuff that those agents can easily discover quickly, we will have less interesting, but yes. I and I want them to be less interesting conversations among the port reviewers with respect to should we give this thing a port. On the I really like sort

[00:38:46] **Martin Duke**: of that I I like

[00:38:47] **Brian Trammell**: the Wiki idea. I like the possibly short circuit people to HTTP. I wanted to give a tiny ad for another draft I have. Draftrammel four four three is enough. It is way less contentious than that title makes it sound. Just about like, hey. Do you need a port? Which I think probably we'll talk about in TSVWG. As the a co author of ninety three zero eight and ninety three twelve, of like the user guides to QUIC, the ninety three zero eight, sort of the applicability stuff, I think, has has not necessarily aged well as, like, people have actually built applications on top of it. Right? It was a good snapshot of how we thought this was gonna be at the time, which also sort of points us toward a wiki as opposed to an RFC. I think ninety three twelve aged better primarily because it's talking about stuff that changes less in in the in the wire image. The contentious thing that I think I wanted to say up here is, like, I I do still think that one of the problems that we have with quick quick adoption, teaching quick, getting people into this area is the lack of sort of a common API. I I kinda have this weird wish that QMux turns into that, and I understand that not a lot of people share that wish. But, like, talking about that as part of the adoption thing, I think, would be another thing that maybe would be come off of this this discussion as well. So thanks.

[00:40:05] **Gorry Fairhurst**: Thanks, Brian. Yeah.

[00:40:08] **Benoit Claise**: Hello. I'm I'm Benoit. I typically spend my time in the ops part of the ITF, and I see a lot of ops related protocols over QUIC. Q.

[00:40:19] **Gorry Fairhurst**: Next slide.

[00:40:25] **Benoit Claise**: Exactly. So to answer your question about the the guidelines and the checkpoints, absolutely. So I'm responsible for the last one, which is telemetry. And telemetry, it's a set of protocols already, which are UDP based. This is Syslog. This is Radius. This is IP fix. This is Yang push. And we're trying to get all the advantages of QUIC. And thanks, Luca, for the review, by the way. So getting this check, the check that you mentioned would be very much appreciated. Why? Because even if we say, in this case, it's telemetry, it's push based telemetry. So we say dial out in our language. You say initiated by the the router in your terminology. I have even request to say, can you extend this in dial in? And then we start to see, oh, do I need to have guidelines for management foo over QUIC? And the answer, we're not special in in ops. Right? So there are plenty of different protocols that might benefit from the same checklist that you're mentioning. So absolutely, thank you.

[00:41:33] **Gorry Fairhurst**: Okay. Well, we'll talk more about that.

[00:41:38] **Mike Bishop**: Lucas?

[00:41:39] **Lucas Pardue**: Yeah. I'll put myself in the queue. So two two brief topics. So I might talk about building stuff on HTTP. One of the the issues that the director has is whether people are actually building a protocol on u d on on HTTP, or if they're trying to just effectively tunnel through HTTP and and take that protocol and and pass it around as post payloads or response payloads. And in addition to that, we have mask, which is is about tunneling protocols over HTTP. And that's another tool in this whole tool set that maybe people could be using. It's all quite nuanced. So I do think a set of have you considered or something like that with maybe some links to examples for people to make that judgment call. Can't police them, but we can maybe nudge them in in the right direction.

[00:42:30] **Gorry Fairhurst**: I feel the next one down might also turn into the same topic. Once mock is widely deployed in various forms, people are going to say, Well, I can't send this data blob over it, or this new type of thing, and that calls a different person to the mic. But you get to carry on in a second.

[00:42:46] **Lucas Pardue**: Yeah. And then the other one is, you've got all these examples of something over quick. I do try and keep track of new drafts and kind of do a cursory review of, are they checking the boxes in my mental checklist of what is kind of make sure this thing is not just gonna work on initial deployment, but be evolvable and maintainable in the future. So also moonlighting in the IAB with a draft about protocol greasing and variability and some of the things some of the extension points of quick that are non obvious, like error codes. You don't want to think about errors when you're designing a protocol that's just going to send some messages and work. There are approaches to greasing some of those code points in quick that are being defined in that document. That would also be worth linking here. And again, having just making sure people are aware of some of the potential future pitfalls in a year or two's time when they need to come back and rev that version of the document or extend it in some way. Martin

[00:43:47] **Martin Duke**: Duke, Google. Several comments about this. First of all, I I agree with Ted that when you think about quick versions, but I think my spin is different. If we just if we're gonna produce something, explicitly say quick v one and v two because the the invariants for quick are just highly oriented towards network observers and wire image things rather than, like, than contracts for the application. So I don't think we can actually say anything useful about Quikr free for applications. Second note is more generally I think this I think some something in some form would be useful based on experience in mock. Mock was heavily is heavily populated with quick experts, and it took us an embarrassingly long time to think hard about head find blocking and and what we needed from that and kinda get it right with the whole peeps thing for those of us who were there. And I don't know. I'm not even a 100 sure we got it right. But but yeah. So this this stuff is hard to say nothing in things like flow control. I I do wonder what the right format is. I think certainly something for TSV art would be a great like, a a fairly foolproof thing to do because we will almost certainly review things that are over quick, and the TSVR people can probably be trusted to to not mess it up as badly. I I'm curious. Maybe, Mike, you could share something about the experience of the HTP document because RFCs quickly become, like, cryptic numbers that nobody that people don't know about and maybe don't read, especially if it's a long document. And, like, I don't know. Has that do you

[00:45:32] **Mike Bishop**: think that changed, that improved the situation? Or So, certainly, I think it has been a useful resource either for people finding it themselves or to have something to point to and not have to re explain it every time that we interact with them from the directorate or on the ISG reviews. The the bis of that BCP is in the Achievea working group right now. I have to go back and look at its status because I thought it was done for a while, but I haven't seen it sent to me. Okay. But, yes, it is it is a useful resource. RFCs do ossify. There's a reason there's abyss. It's being updated with things that we've learned over time.

[00:46:18] **Yaroslav**: Mhmm.

[00:46:18] **Martin Duke**: Brian's point about AI is actually quite convincing too. Think Yes. I think spewing out text may be more valuable than it used to be in the past just because of that whole dynamic. So I think, yes, definitely a, like, TSDR checklist, maybe an RC, and I do think that something is needed in some form. Thanks.

[00:46:39] **Mike Bishop**: And, honestly, to the point of AI being able to consume things and produce something based on it, pointing AI back to those embarrassingly long discussions of mock and saying, you know, what were the thorny points?

[00:46:59] **Gorry Fairhurst**: Alright. We're gonna take the one more slide. So we'll swap Lucas for pair if he wishes to come here. And the slide is simply a little bit more than a list of drafts. It's actually the activity that's going on in ops area.

[00:47:23] **Per**: Yes. So my name is Perra Nachon. This is the first time I see this slide, so give me ten seconds to digest. I had a long, long slide deck that I submitted where that I wasn't going to present all of it. But, basically yes. Exactly. So I I I'm I'm involved in in this in ops area, taking disc taking an ongoing discussion of do we need guidelines or something for control plane protocols, management protocols, the data plane telemetry that Benoit mentioned. And there is probably a big benefit for us to have such guidelines because there is knowledge, but it's not evenly distributed, you could say. The one must that we have is order delivery. Otherwise, it's a bunch of maze of integrity, confidentiality, and authentication depending on your use case protocol, etcetera. Quick might solve a few of these things. So, typically, what you do otherwise is that you bolt on security with, for instance, TLS or DTLS. And with QUIC, you would have that included from the very start. What QUIC is not or is not seen is it's not possible to just take it as a drop in replacement for TCP. So if it would be possible to create such a profile for a drop in replacement for TCP where the use case is a good fit, that would be interesting. And there are in my slide deck, I have a lots and lots of operational considerations of deployments, usage, and so on. I can post them to the chat later on. And if you would be able to or willing to help us with this, please come to the ops area tomorrow. No? Yes. Tomorrow, sixteen thirty. Or grab me in the corridor or any ops person you know. I'll be at the quick working group as well.

[00:49:39] **Gorry Fairhurst**: Thanks for coming and advertising this session and also saying this is not just WIT thinking, There are people in the ops who are seriously trying to figure out the right way to go here.

[00:49:50] **Per**: Yeah, and I heard the same comments that guidelines would be a neat thing to have. I very much support that as well.

[00:49:57] **Mike Bishop**: Thank

[00:49:57] **Gorry Fairhurst**: you. Shall we just do that? Well, I wondered whether in which area we would actually have a poll and see who would be willing to volunteer to help draw together a set of guidelines in a wiki. We will determine a process for doing it, but who in the room is actually willing to do it? You can vote in the tool, but if you also raise your hand, that would be super good. Oh, we can't vote in the tool unless we ask a question in the tool.

[00:50:25] **Mike Bishop**: Well, if we do that, then we don't know who answered yes. Yeah.

[00:50:30] **Gorry Fairhurst**: Oh, I wanted to do a poll, but yeah. Okay.

[00:50:33] **Magnus Westerlund**: I've not

[00:50:34] **Gorry Fairhurst**: done one for ages. Right. No. But please show your hands if you're willing to volunteer. Magnus, yeah. Lucas, yeah. Brian. We have some people. We're not gonna do this in private. We're gonna try and put something together. If those people will will facilitate and make that happen, that'd be great. We'll host it on the wiki. We'll point other people in which area to that, and we'll see if we can refine it and make it useful. Thanks for volunteering and please continue to look at this as we make more calls because it's not going to be easy to figure out what that advice stroke guidelines should be. But I think the expertise exists, so it'd be loved to have it in one place. Should we just go to our final slide? Our final slide was open mic. We're not going to particularly have an open mic, but we were gonna have well, you can come talk, whatever you like in the last chunk. We're also interested in news from around the area. So is there anything that is going on that at this IETF or coming up on the radar which you would like to just say something about at the mic to alert other people to?

[00:51:57] **Mike Bishop**: We're failing that. Would you like ten minutes to get to your lunch reservations before everyone else?

[00:52:04] **Gorry Fairhurst**: Which is also on offer. And actually, it's the default. So thank you ever so much for coming to WIT area. We plan to hold a WIT area meeting next IETF. That would be good if you could come also. But in the meantime, we will use the mailing list for discussing this topic a little bit more to produce a draft of those guidelines.

[00:52:37] **Mike Bishop**: Thank you.

[00:53:04] **Gorry Fairhurst**: Did we not, don't you, said that they were volunteering? Do we know who volunteered on a piece of paper or in an email or something?

[00:53:13] **Mike Bishop**: Well, I think our new teacher should have captured that. Yeah. But I'm writing this.

[00:53:17] **Gorry Fairhurst**: It was Brian, Michael, Lucas. Yeah? Yeah. Ozzie. We wanna guess, please. Are you happy with Brian's thinking