**Session Date/Time:** 20 Jul 2026 14:30

[00:01:48] **Kazuho Oku**: Time.

[00:01:51] **Hannes Tschofenig**: We need to start.

[00:01:53] **David Schinazi**: Yeah. Well, and also where's this? Is Yaroslav here?

[00:02:02] **Hannes Tschofenig**: Artie, get everyone in.

[00:02:16] **David Schinazi**: There we go. I was hoping that Yaroslav would make it before he closed the door.

[00:02:22] **Hannes Tschofenig**: Yaroslav, we can't start without you.

[00:02:28] **David Schinazi**: Alright. It looks like most of our enthusiasts are in the room, so we're gonna get started. Hello, everyone, and happy Monday. Welcome to IETF 116 in Vienna. This is the working group forming BOF for PTTH, also known as POTATO. We are Hannes Tschofenig, and I am David Schinazi. Your chairs. First, this is the note well. By joining for this meeting by joining this meeting, you have agreed to this note well when you registered. If you haven't read it, please do so. You're bound by it, especially when it comes to following the ITF code of conduct. So a little background history of potato. Some of you might remember we had a nonworking group performing boff in Madrid, and then there was quite a bit of enthusiasm in the room. But it being not working before, we didn't quite have a charter yet. So we started work on a charter on the mailing list in the months that followed. We didn't quite get make the deadline for submitting a BOF for the November IETF in Montreal. And then life was busy. A bunch of the proponents were remote in March, the ITF in Yokohama. So we kinda took a break,

[00:03:51] **Kent Watsen**: but we're back.

[00:03:52] **David Schinazi**: So trying to kick this effort back up again and see if there's interest in the community to form a working group here. So our agenda today, you're gonna hear me blabber on for a little bit, and then we're gonna have four different presentations around use cases. We're not going into to go into the solution space today. Our goal really is to agree on a scope for a working group. And then we're gonna, at the end of that, go over the proposed charter that we have written up. Would anyone like to bash the agenda? Alright. So a bit more background. Reverse HTTP or PTTH or POTATO. Oh, this is fascinating. Martin, your die cuts don't render properly in MeetEco. We'll have to file a bug. So this idea dates back to at least 2008. I'm sure there may have been some before. This was there were ways to do this in h t p one, then folks proposed ways to do this in h t t p two, then in HTTP three. And then this year, Martin Thompson decided to do horrible, horrible things with Unicode and wrote a proposal that would solve this problem space. But if you get the PDF using your browser, it renders in an actually more horrendous way, which is great. Alright. So a very, very high level overview of what we're talking about. There's a small potato, and it wants to talk to a big potato. So it comes in and creates a network connection. So if this is TCP, you might recognize the three way handshake. And then in this context, the small potato is the TCP client. The big potato is the TCP server. That allows them to establish an HTTP connection between the two of them.

[00:05:51] **Hannes Tschofenig**: So when you're doing normal HTTP, then the small potato can send requests to the

[00:05:56] **David Schinazi**: big potato. And now, I'm going to explain reverse HTTP, and I want you all to focus very carefully because this is the really hard part to get. In reverse HTTP, we do it the other way around. The big potato sends the request to the small potato. In other words, in this context, the TCP client becomes an HTTP server and the TCP server becomes an HTTP client. Why would you wanna do this? To kinda zoom back out, what that allows you to do is this big potato, we're gonna call it a proxy, can now serve requests from other clients and forward them down to the worker, which is a small potato, and the request responses flow in the other direction. Okay. We're gonna now go into present if anyone has some clarifying questions about the nomenclature of potatoes, please don't hesitate to get in the queue. But otherwise, we're gonna jump into presentations of use cases for why this would be useful. Each presentation is gonna last about ten minutes, and we ask that you only bring clarifying questions to the mic. We're gonna take substantive discussion after those presentations are all done. Alright. And we'll do these later.

[00:07:21] **Hannes Tschofenig**: Kazuho.

[00:07:30] **Kazuho Oku**: So hello. I'm, Kazuho Hoku from Fastly. As I you see, I work for a CDN company, so I can talk about the use cases that CDN might care, though I cannot speak for the company but company itself. So this is more about my personal observations. So yes. Next, please. Oh, thank you. So before diving in, let's be clear about the terminology. As David just said, the problem with potatoes is that the worker connects to the proxy as a client, and the proxy acts as a TCP server. But once the proxy sorry. Oh, thank you. But once the proxy, is accepts the TCP connection, then the proxy becomes the client HTTP client and sends request to the back end. So, we cannot really say which is the client or which is the server, and that's the confusing part. So instead, in these presentations, we call the proxy a proxy, and the HTTP server hidden in the back end as a worker, because it's a TCP client and HTTP server. So, let me explain the benefits of PTTH as I see. First, it allows us to hide the servers, from networks. And the however, the problem that we have now today is that we have to open a hole in our firewalls, and we open them by writing down the IP addresses of CDNs. So it's you have to do that configuration, And because you have to write down the IP addresses rather than the names, it's very inflexible to configure. And compared to that with PTTH, workers establish outbound connection to the CDN using host names. And that means that there's no need to configure the files and that the CDN can update their IP addresses dynamically with the DNS because all the name resolutions are now done by the host name rather than using fixed IP address for whitelisting. The second benefit is that it has better load balancing and dynamic scaling. Because on the status quo, when you add a back end server or a group of servers, then you have to update the CDN configuration, like, you know, add this host name to the the set of the back ends that the CDN should connect to. Whereas with PTTH, back end operators can just clone a worker instance that has the necessary credentials to connect to the to the proxy. And then the workers would the new workers would automatically connect to the proxies and start receiving the request. So this, eliminates the need for manual configuration every time you add a new worker, and it doesn't require having a load balance between the proxy and worker just for, handling the additional load or reducing the scaling. And the third point is the prioritization. Under the current design, under the current ordinary HTTP, requests traverse from re proxies to typically load balances and to the back end servers. So, there's no good way of providing the request from the proxy in the order of importance. But with PTTH, because the proxy becomes the only queue that buffers the HTTP request, When the workers ask for a new request to be processed, the proxy has the pure freedom to provide whatever request that has the utmost importance, while delaying, for example, the request from AIs because you don't need to process them immediately. So this kind of, setup is only possible if you don't have multiple AIs of queues, but only have one queue in the proxy where from which all the workers pull the requests. And the fourth advantage that we see is that it allows us to better limit the concurrency of heavyweight requests. Handling of heavyweight requests is a complex task under today's ordinary HTTP architecture, And what people often do is they create a separate queue, that remembers the heavyweight requests, to be processed. So your ordinary web app just receives a request and submits that to a queue, where a small number of workers, connect to that queue, fetch the request, and submit the response. So there are many, parties involved. Whereas with PTTH, the proxy itself, count as a queue, and the workers can just use ordinary HTTP to fetch the request as they do they want to, process and submit the request. So, it, reduces the complexity of running a heavyweight request processes with limited number of concurrency. And the reasons, why we think that standardization is important is that there are already, proprietary solutions that do PTTH. But all of them requires custom applications to be installed into the customer's, deployment because they all speak their proprietary protocol. So this is a burden for many customers. And for many of them, they don't allow, you know, us to provide our software to be installed in their environment, their deployment because, you know, it's hard to control what, we might be doing. With PTTH, there's a possibility that HTTP servers or HTTP application servers can just implement PTTH as a standard. And then they can connect to the CDNs or other reverse proxies. And that will eliminate the need to install custom software on the deployments, and so we hope that it would help adoption. Ted?

[00:13:55] **Martin Duke**: Yeah. Martin Duke, Google. Can you go back a slide? Yep. So, I just I wanna is there a requirement here that maybe was not obvious from before? So you're saying that the workers pull HTTP requests. So that is something different than the proxy just simply initiating a HTTP request and sending it to when it gets something from the client. Like, is there some mechanism that you're implying where the client is saying you can send me your request now?

[00:14:26] **Kazuho Oku**: Well, so this is not something new to HTTP or how you do HTTP, but the the thing is that when processing a request, it's already the case that some for some kind of a heavyweight request, you have a separate queue behind an file. The client waits for the request to be processed, use the application server submits the request to a different queue, then our worker just subscribes subscribing to that queue, processes it. So there's that kind of deployment. And I'm saying that those kind of deployments can just use PTTH, and they would no longer need to have a separate messaging queue or something. Okay.

[00:15:07] **Hannes Tschofenig**: Martin, I tried a little bit differently. I think there's a common agreement on the base level requirements among the presenters, on the details, of course, on how sort of like the prioritization or other this authorization handling, etcetera, etcetera, there, obviously, things drift apart a little bit. So I think that's then left as an exercise for the working group to find out on how these details then actually materialize and which features are important and where some in which use cases some of those mechanisms are important and in which ones they aren't.

[00:15:47] **Martin Duke**: Great. Thank you.

[00:15:48] **Kazuho Oku**: Thank you. Right. So, let me explain some design considerations we have we have. And, of course, we want of course, if we are going to develop PTTH, want it to succeed. And so, therefore, we have to minimize the barrier to adoption. And it's important to understand that p h PTTH just reverses the setup direction and provides several benefits, but existing solutions already use HTTP. So PTTH is an addition. And it's always going to be addition, because HTTP as is isn't going away. So the the question is always like, how can we minimize the difference between ordinary HTTP and PTTH so that the integration cost can be minimized? And the second question would be like, how could PTTH support as many HTTP extensions as possible? For example, WebSockets. So so that it could it would be feature parity. Because if we don't have those two properties, then p potato becomes a something different from HTTP. And the more it becomes different, then it becomes more difficult to, you know, explain why it's important to implement this. So, in that respect, one of the important things is to think about the authentication, because before forwarding HTTP requests, a proxy needs to authenticate the worker. And I'd point out that cloud services, CDNs, and existing proper proprietary potato solutions today use bearer tokens for their API access. So, that means that it would be helpful if Potato could support token based authentication, because then the existing deployments that do HTTP today can, easily integrate PTTH without developing another authentication, system. And the second point is about scope. So, to in today's systems that I described, authentication tokens are often scoped to each customer to a configuration belonging to each customer. But at the same time, each configuration of a back end can be multiple. For example, slash app could be mapped to back end a, whereas slash assets could be mapped to a different back end. So in PTTH, it would be great if a proxy, could have a way to determine what worker's scope is. I mean, for each worker that connects to a proxy, the proxy needs to know, should I forward slash app, or should I forward slash assets as separately from from who the worker is based on the authentication. So to summarize, there are several benefits as I explained in PTTH that we see we see our IC as a CDN employee. And there are two considerations or maybe three, as I explained, like, it would be good if better token was supported and routing based on scope was possible. And, also, the it would be great if h many HTTP extensions could be supported. So that's what we see as opportunity for PTTH. Thank you.

[00:19:10] **David Schinazi**: Thank you, Kazuho. Yaroslav? Unless there are any questions for Kazuho? And there. Here's another quick.

[00:19:43] **Yaroslav Rosomakho**: Hello, everybody. My name is Yaroslav. I'm from Zscaler or Zscaler, depending on which side of the pond you come from. And today, I would like to share some of use cases in ZTNA space, Zero Trust Network Access. Unfortunately, the term ZTNA is not strictly speaking defined. It's a marketing term that is used by multiple vendors, sometimes describe different things. I'll try to reconcile that to the best of my ability. The use case is somewhat similar to what Kazuho just presented,

[00:20:20] **David Schinazi**: but worse.

[00:20:22] **Yaroslav Rosomakho**: So traditional remote access VPN architecture has been around for decades. The idea is that you deploy a VPN concentrator on-site or set of VPN concentrators, and you have your remote worker connecting to those VPN concentrators using one of delightful protocols such as IKE v two or WireGuard or some kind of proprietary VPN over TLS DTLS or maybe MASQUE Connect IP if if if if you're modern and like technologies developed in this century. And, basically, they're all kinda similar. Client obtains an IP address to make a tunnel interface. Client is routing traffic to the VPN concentrator. The connectivity is bidirectional, and it's transporting IP packets as the whole. One of the challenges with this architecture is that, well, you do need to have a v VPN concentrator. You do need to deploy it on-site. It needs to have a static public IP address typically, and it's an attack surface. So it can be subject to DDoS attack. There are regularly all sorts of wonderful zero day vulnerabilities discovered in VPN concentrators. So that's that's suboptimal. Many organizations during especially COVID days when all of a sudden everyone started working from home discovered lots of scalability challenges with their VPN concentrators. So idea of ZTNA architecture, and again, different vendors have different approach to this, but I believe quite a few vendors have lots of similarities. So Zscaler, Netskope, Microsoft's DTNA offering, Cisco, and few others follow roughly roughly the same the same architecture. So the idea is that client is connecting to cloud. Sometimes it's called broker. I guess we will be calling it in proxy in PTTH terms. And then instead of VPN concentrator on prem, organization deploys what we call now worker, or some vendors call it app connector or publisher, some gateway, some device, some VM that is establishing connection to the same cloud, and then connections from the client are encapsulated in the tunnel into the cloud, and those connections are then being proxied into connection that was established in the other direction from the worker. So this means that for on premises, you do not need to have static public IP addresses. It arguably scales better. Arguably, there is a reduced attack surface associated with this deployment compared to traditional VPN concentrator approach. Typically, in the TNA solutions, transport carries layer four flows. So TCP, instead of carrying the whole IP packets, client strips away all the necessary things and trend only TCP data is sent or datagrams UDP datagrams are sent for for UDP flows. So client to proxy connectivity, it's them established mask standards apply really well to it. So we have HTTP Connect. We have templated Connect TCP. We have Connect UDP that can travel or fall in all sorts of HTTP versions, and it maps, again, really, really well what ZTNAs accomplish on their client to proxy or client to the cloud connectivity. In the other direction, not so much. So, of course, you could potentially try and use Connect IP for that. So that is built just a really VPN client by the other name, but it requires all those wonderful challenges with IP addresses, have interesting challenges when it comes to adjusting MSS in in encapsulated packets. Now fragmentation become an interesting challenge. Again, you could look at things like connect UDP listen, but that is UDP only, have extra overhead, again, requires IP addresses for listening to the clients. So having standardized reverse HTTP Connect solution would solve address this use case, potentially allow building a vendor agnostic ZTNAs, which is great for customers and also makes much easier to migrate from one vendor ZTNA to another vendor ZTNA or maybe even create some kind of standard open source ZTNA, not only clients, which you can do today with HTTP Connects, but also workers. Another interesting use case is proxy to client connectivity. So, again, if you have this kind of client that is using connect methods for establishing outbound connectivity using mask proxy, there are cases where you actually want to have inbound connection in the client. For example, some of the device management systems such as RDP or SSH, VNC, SCCM, they require inbound connectivity into the client. And in these architectures, you do not assign IP address for your client. There is no client tunnel interface. Flows are being directly picked up using modern APIs provided by their operating system. So, yeah, there is there is no IP address there. And having inbound connectivity within the same channel would address those manageability requirements for clients in VPN like technologies that do not provide IP addresses. So desired properties of solution for those use cases is, of course, server initiated requests over HTTP three and HTTP two. This use case generally doesn't care about HTTP one. You really want to have multiple requests within multiple connects within the same tunnel for the whole thing to scale. Of course, reasonably small overhead is always great when you're encapsulating things within things. And for these use cases, it would be great to have regular and reverse requests over the same HTTP connection. One of great properties of mask is that it's very hard to distinguish between to discriminate between that and other HTTP traffic. So would be great to keep this property moving forwards given how things are being discriminated against VPNs in different jurisdictions. With that, any clarifying questions?

[00:27:18] **Hannes Tschofenig**: I have Ines in the queue. Are you She's

[00:27:22] **David Schinazi**: in the queue to share slides. I don't know if that's intentional.

[00:27:25] **Hannes Tschofenig**: Probably a mistake.

[00:27:26] **David Schinazi**: Like, was that intentional, Ines? I see you're trying to share slides. We're gonna assume it wasn't then. Alright. Jana?

[00:27:40] **Jana Iyengar**: How do you achieve these things today? Specifically, you talked about how device configuration information,

[00:27:45] **Yaroslav Rosomakho**: Proprietary for protocols. So every vendor that I've just mentioned has their own flavor of these implemented today, either via proprietary framing within TLS or sometimes some some some vendors use these things over IQv2. So, yeah, it would be great to have at least for the data plane some common protocol that would allow interoperability and easier migration.

[00:28:12] **Hannes Tschofenig**: Got it. Thank you.

[00:28:17] **David Schinazi**: Kent?

[00:28:19] **Kent Watsen**: Hi, Kent. I'm the author of RFC eighty seventy one, which is our NetConf call home, RestConf call home, which is for device management. So here we have devices being deployed behind firewalls that only allow outbound traffic. Devices are shipped from manufacturing with an IDEV ID certificate burned in tamper resistant memory, and and they call home to the orchestrator or the controller, which then can reverse that connection. It works because the layers, TCP and TLS or SSH are two distinct layers. And so first, the TCP connection establish a full duplex connection. And then at the layer above, they just flip roles. And so it's transparent. No standardization was necessary. All existing libraries work. All existing programming languages work. So I'm hoping to do the same here. Reverse quick would be were my first thought, but reverse h t is the second thought

[00:29:19] **Hannes Tschofenig**: Right.

[00:29:20] **Kent Watsen**: Which would work for RESTCONF, not for NETCONF. But

[00:29:22] **Yaroslav Rosomakho**: I don't want to to go too deep in the solution space, but, again, here, one of desired properties is bidirectionality. So if we reverse right after, for example, we negotiate TLS or QUIC, then, I mean, it it is reversed once and forever. You cannot do that bidirectionally. Secondly, yeah, authentication is a little bit more complex in this scenario because, again, it depends on vendor specific technology sometimes. Sometimes you need to do, like, OpenID Connect to get some access token, exchange it for certificate, or or do some other other moving parts before you get to establish a session.

[00:30:02] **Kent Watsen**: I I understand that this is the design part of the previous presentation was use cases, so maybe it belonged to use cases. We just mentioned the word authorization or authentication. I just wanna mention that operators were adamant that the authentication mechanisms should or stable regardless of the directionality of the connect. So again, the server the devices are shipped with these certificates, and that always has to be like the TLS certificate no matter what, whichever direction the TCP connection originated with.

[00:30:32] **Yaroslav Rosomakho**: Thanks.

[00:30:36] **Ted Hardie**: Ted Hardy. I guess the question that was raised for me by the previous speaker, and a little bit by Jana, was for invocation methods. In the charter at the moment, we don't actually have anything that indicates how you invoke a potato session as opposed to some other kind of TCP session to a peer. And it occurred to me that, you know, we might just be, at some point, adding a potato URI to let people know that this is the the target of it. But this idea here that you would reverse the directionality in the midst of a session actually makes that a little bit more complicated. And I'm wondering for the proprietary versions that have been shipped so far, how are you doing that?

[00:31:22] **Yaroslav Rosomakho**: So the management and signaling and enrollment, that is a separate process from the data plane. So when you Okay. So you don't need to go into

[00:31:35] **Ted Hardie**: it any further. Out of scope for the reverse HTTP proprietary mechanisms, because there's a separate signaling path, I think that answers my question. But I think it does raise a question for the BoF charter section that maybe the chairs want to note down, is we need to know whether the invocation of this is going to be done in band or out of band in order to understand the scope of the work. Thanks.

[00:32:00] **Yaroslav Rosomakho**: Thank you. Yes. Indeed, we need to, I think, draw a careful line in our charter between what signaling do we need to have for data plane to work versus what is remaining as an exercise for the reader in terms of configuring things, if I got your point correctly.

[00:32:20] **Ted Hardie**: Again, let's talk about it a little bit more in the chart, but the point I'm trying to make is right now, the the methods by which you invoke PTTH are not described in the charter as an output. If you keep to the idea that it is a separate signaling path, then that may be appropriate. But I think it still leaves open the question of how do you create bidirectionality in a a in a created session. So I I suggest that it's probably not out of scope for that discussion to happen as part of the working group, and some quite serious amount of thinking about how the invocation is gonna work, especially if it's in band, is gonna be needed.

[00:33:03] **Kazuho Oku**: Okay. Thank

[00:33:03] **Hannes Tschofenig**: you. The that the charter, of course, when it was written, it was it's difficult to balance the level of details you provide. So, it's written very generically. On that aspect, there is not even a hint there. For the security stuff that was discussed earlier, there is at least an item, because it came up in discussions in the past, of course. So, we'll have to do a little bit of wordsmissing and chatting about the charter text a little later in this meeting.

[00:33:39] **David Schinazi**: And to add to that, some of the solutions that have been proposed use a new type of HTTP Connect, so you could use HTTP authentication for them. Some of the other proposals are similar to the NetCon solution where you kinda flip the flip the layer around, and those can't use those as easily. So our current plan is to keep that specific design choice not in the charter so we can have that discussion as a working group if we decide to form one.

[00:34:14] **Speaker 8**: I had one question. That's my turn. Right? So I had one question regarding reversing the traffic. Now when once we reverse this, are we increasing the attack surface? What I mean by that is, like, in front of the servers, you have all the checks and balances with respect to firewall, you know, DoS attack for rate limiting and whatnot. Right? But these are very small devices which you may not have all these in front of those, you know, claims. Right? So in those cases, are we increasing any attack surfaces? Because I have what you mentioned is authentication and other solutions are yet to be discussed. But

[00:34:53] **Yaroslav Rosomakho**: Right. Obviously, we need to take care of availability of the whole system and deal with prioritization. In terms of increase attack surface fundamental, I mean, you create TLS connection between two endpoints. Right? So in one scenario, one is client and server and can send requests. In another scenario, we are reversing that. So if you're accepting requests from the outbound part, of course, you need to take care not to be overwhelmed to control your availability. Yes. There is a potential of those attacks, But also the question that was just raised about authentication and authorization, so make sure that you don't accept this reverse HTTP from random strangers on the Internet, yeah, will be will be important.

[00:35:43] **David Schinazi**: Thanks. And Althea?

[00:35:46] **Althea Komiraki**: Hi. Althea, this is Komiraki. So I'm from the similar sphere of services. And, yeah, reverse sounds great. Fewer connects fewer socket handshakes, great for NAT binding. However, operationally, separate HTP connections is the pragmatic default because there are other things to consider, like load balancing and direct service returns and things like that. So I'm just wondering if if all that is out of scope or have you put that all those considerations in? Maybe that's, like, question number one. And question number two is for this for your use case specifically, not the the PTTH thing, would you consider two separate HTTP transports to be part of this one connection, or they or it has to be the same HTTP transport?

[00:36:39] **Yaroslav Rosomakho**: Sorry. I'm not entirely sure.

[00:36:41] **David Schinazi**: I I think sorry. We were having a little hard time at the podium hearing you. But if I understood your question correctly, I think some of the proposed solutions have that property of allowing requests in both directions, whereas some of them don't, where you would create one connection that's just reverse, and you would have to create a separate forward one. But that'll depend on which solution we land on.

[00:37:07] **Althea Komiraki**: Okay. Okay. And the next thing was for this use case, the question that was not answered is for this use case, there are things like direct service return and other other use cases which do not want that the reverse path from the concentrator or the cloud hub or SASE hub, whatever you call it, is on the same path. Sometimes we need it to be on a different path, a shorter path.

[00:37:32] **Hannes Tschofenig**: Yeah. I think I think you're probably hinting to an authorization question of what specific functionality is needed for specific hosts that sit behind the proxy. So, for specific workers, what is the property you are basically allowing them to do? A little bit similar to what we saw in the first presentation with the CDNs, where there was a short description on the scopes and the permissions that are associated with them. So, are a couple of authorisation questions that need to be taken care of, in addition to the question overall on which worker is even allowed to connect to the proxy and which proxy accepts which worker. So, there are definitely a number of design considerations we would have to talk about. But I think it's premature to deep dive into those questions at this point in time because we are, at this meeting, we are fundamentally asking ourselves whether the problem scope is understood and whether we want to work on this topic in the IETF, whether we have the right level of expertise to actually do the work here. Of course, there will be more details to be looked at later on when those questions are answered appropriately.

[00:39:02] **Althea Komiraki**: Okay. That was not my question, but sounds good. I'll take it offline or wait.

[00:39:07] **Hannes Tschofenig**: Thank you.

[00:39:09] **David Schinazi**: Alright. Thank you, Yaroslav. Then we have Marius who is remote. Grant slide. Okay. Hold on. Yeah. Now I need to Yeah. Remove stop the clicker and stop this and grab to there. Alright. We're good to go, Marius.

[00:39:37] **Martin Duke**: Can you hear me all well? Yep.

[00:39:40] **David Schinazi**: That sounds great.

[00:39:41] **Martin Duke**: And I wanna talk about a use case for PTTH that circles up dynamic integration. Let me start by shedding what setups might look like, scaling up and scaling down the work. So in the diagram below, you see the set up that you have a client that is sending requests to a proxy, and this proxy is forwarding those requests to what we call a worker nowadays. Normal the audio, this is called origin, but for simplicity. And when you wanna worker, usually, docker container or something, whatever. This is controlled by, like, control plan and make sure that this new worker is third with proxy after running some red tags where the worker is actually booted up and then

[00:40:39] **Martin Thompson**: yeah. Maurice, can I just interrupt? Your audio was breaking up really badly. Very badly.

[00:40:44] **David Schinazi**: Okay. I thought it was just us up here. It's it's really it's the entire room.

[00:40:52] **Hannes Tschofenig**: Yeah. Turn off the video.

[00:40:53] **David Schinazi**: Yeah. Try turning off the video and speaking very slowly. Sorry about that. Is it better now?

[00:41:00] **Martin Duke**: Yes. And if it doesn't improve, then please let me know. So what I was saying is that we have a common setup here where the client is forwarding us to the proxy, which is then forwarding it to the worker. When you wanna scale up workers, get new ones, this is usually coordinated by something like a control plane. Once the worker has booted up, the control plane will then register it with the proxy to make sure that they can forward requests to the new worker instance. On the other side, when scaling down, this is controlled by the control plane. Make sure to tell the proxy to drain the existing connections, not send new requests to the worker instance. And once the worker is then idle, it then shuts it down, initiates it in whatever way. The issue with the setup is that the worker had no control over this configuration process. Even though the worker has usually the most knowledge about its current life cycle, it doesn't it's not able to configure the proxy because all of this configuration happen through the control plane in a usually proprietary mechanism. Now with PTT we can improve this a bit. Because the worker have existing connection to the proxy, which is the big fat pipe on the on the bottom right, we can use this connection to also send signals from the worker to the proxy. For example, to signal that the worker is now ready to accept requests. After it has booted up, it has done all its initialization checks. It is then ready to accept the request. On the other hand, once it want to shut down because it, yeah, is required to shut down, go into maintenance mode, this can instruct the proxy to drain existing connection and not send any requests. We can also use signals to increase or decrease request rate. The worker usually knows best how much load it's currently handling and that if there's still some more capacity or if it's already overcapacity it can reduce the cost rate. We could also think about a scenario worker dynamically announcing which request it wants to handle based on selectors for the host name, for example, or the request. Such a design would bring some in that it allows the worker to control its own it allow other proxy. Please send me a request. It can also add new endpoints dynamically available. Think about a use case where the worker is booting up. It's capable of handling some requests immediately while others, for example, are only able to be processed after you've loaded an LLM, for example, or you've prewarmed your cache. Those things will only become available once you have done those initialization requests, and then the work can pull the proxy. Hey. You can send me those now. As mentioned before, also training when shutting down, handling the control request rate, and this is capable to be done per connection. So this is not global per worker or even per proxy, but you can this worker could, in theory, multiple connections to the proxy and use one of those connection for the long lived requests such as WebSocket or web or a lot of connections are reserved for forklift API. Then you can configure and be depending on the worker load and resources. All that and the control interface between the proxy and the worker could even be partially standardized. This is currently not the case as also Kasuho hinted on before because this is mostly proprietary right now. The nice benefit of PTTH here is that we could likely reuse some or most existing HTTP signals for this. For example, in h two and h three, you have to go away frame. You have per connection stream limits, and those, for example, could be used to initiate or to signal those draining or request for changes. And overall, some of the might be out of standardization because they still are proprietary, but I think there's a decent chunk of signals that could be standardized could be based on existing HTTP mechanisms. So yeah. I think this is an improvement for certain deployment in regards to how the connection between a proxy and the worker is configured. Yep. That's all I have.

[00:45:45] **Hannes Tschofenig**: Thank you, Marius. I don't know if the audio got it crossed, but I think there was two interesting aspects in the presentation which I like to point out to you. One is the sort of, like, cycle of the worker. And previously in previous presentation, we talked specifically about like worker starts and talks to the proxy. But here's also the question of on additional requirements on what happens if that worker is going to shut down? How does it deal with existing connection without disrupting everything? And then also, the second aspect is the sort of like dealing with the load situation and sort of like providing some information back to the proxy to indicate that it has more processing capabilities for further requests or that it's already overloaded. I call this congestion control. Thank you, Marius.

[00:46:46] **Ted Hardie**: You are up.

[00:47:01] **Martin Thompson**: The power. Alright. That's the power.

[00:47:06] **Hannes Tschofenig**: Take it off this. Yeah.

[00:47:08] **Martin Thompson**: So we've heard about the use cases. I'm here to sort of summarize the scope that I see the working group, should it be formed, would have to contend with. So I see sort of three main legs to this problem, and the previous presenters touched on each one of them. The first one is the plumbing, how the bits get to a and b, and how the requests get back and forth. By the way, I have no AI generated images. David didn't give me a whole lot of time to generate slides. These are basically the first images that came up on a on a web search. So this this I consider to be absolutely essential for any work in this area. If we're going to do something, then we're going to work out how the bits get to the various parties that need them. But I also don't think it's particularly difficult. We can talk about tunnelling, we can talk about inverting the connections. That's not particularly interesting. The second problem is really the authorisation problem. So, this proxy, which I think is the wrong terminology but we'll get back to that, has to decide whether or not to allow the thing that's connecting into it to accept the request. It's got to decide whether to forward the request onwards or not, and that's going to be an interesting question to solve. Now, we potentially can leave this to something proprietary. We've routinely done this in HTTP. How you authenticate someone in HTTP? Well, you have some choices, and there are many of them. Maybe we can make some decisions here, maybe we don't. This starts to get pretty tricky. I'm not sure about this one, but I think this is probably something that we wanted to start paving the path for and have some understanding of the general shape in which these things fall. Maybe we don't want to overprescribe so that we can take advantage of the full spread of options that HTTP provides, but we do probably need to have some sort of idea of what these things look like in order to make progress, particularly as it relates to the first one. In some senses, the choices that we make at this level will dictate the shape of the protocol. And the final piece is some of the things that Murray has touched on in his presentation. The proxy thing bad name, needs a potentially works really well when you have just one client, and that client has the necessary capacity to serve the requests that are forwarded to it. If at some point the thing that is that the proxy is receiving more requests than that that worker can handle, we have some pushback mechanisms in some of the protocols. It can start refusing requests. It can send various 500 series status codes, for instance. It can also use things like flow control and stream limits in HTTP two and three, the only protocols that you really wanna use with this anyway, and it can sort of apply some amount of back pressure. But maybe the proxy wants to ask for more workers to be spun up. How does that happen? And so, this one, I think, is far less necessary. I think you can get a long way here without digging in deeply on this one. But also, it could be quite tricky in terms of trying to get through all the different deployments that people have and work out the right shape to have that sort of control surface. So my suggestion there would be to explicitly leave that out of scope in the current charter and concentrate on the first two cases. And that's all I have.

[00:51:13] **David Schinazi**: Thank you, Martin. But it looks like you have questions, starting with Emile.

[00:51:25] **Hannes Tschofenig**: Thanks, Martin. I have one question. Getaway here is a reverse proxy or what is it?

[00:51:33] **Martin Thompson**: The terminology problem. So, the terminology that we had established in the previous discussions, there's a proxy and a worker. At least from an HTTP perspective, the proxy is a reverse proxy in the sense that you understand. It's not the forward proxy that acts on behalf of a client, it's the reverse proxy that acts on behalf of a server.

[00:51:58] **Hannes Tschofenig**: Okay, thank you. Okay?

[00:52:03] **Martin Thompson**: And the workers are origin servers in HTTP terminology. And I think we should be using those terms, but that's that's just me.

[00:52:12] **David Schinazi**: Bengal?

[00:52:13] **Bengal**: I yeah. Hey, Bengal. I really like the problem number two. And I guess the question is, can you say any more about, like, if that's in scope, how what types of things that could look like? I just I'm I just signed on to be an editor with one of the HTTP signatures editors, Manu Sporny, on this thing at w three c called authorization capabilities. That's like an object capability model. I definitely wanna know if there's other things you already have in mind for how authorization could work here.

[00:52:43] **Martin Thompson**: I think this is relatively straightforward. For the most part, proxy that's acting here is going to receive a connection from a worker. It needs to sort of authenticate that worker in most cases to know which worker it's talking to. And then from that point, it either has configuration that says, I send these requests to this identity of worker, or the worker itself maybe wants to say, I want to take ownership of this portion of the URL space, and that's something that Kazuho was talking about before. So, And that might just be a prefix match or a pattern match on URLs. That's something that we'll have to work out. Right?

[00:53:21] **Hannes Tschofenig**: In that presentation, that was the slide that talked about scopes. The scope terminology hinted a little bit to OAuth work, which used scopes as a name for permissions. But I don't want to go there. In this. Right.

[00:53:40] **Martin Thompson**: I think using the word scope there may be inadvisable. Think of it as a as the set of URLs that might get forwarded to the worker.

[00:53:49] **David Schinazi**: A realm, perhaps?

[00:53:51] **Martin Thompson**: Please don't.

[00:53:55] **Mike Blanche**: Mike Blanche, a potato enthusiast. Thank you. I think this is good, but I think this whole conversation illustrates as perhaps problem zero, which is terminology. Yes. I know we're not talking charter yet, but I that that isn't on the charter. And maybe that is something that should be on

[00:54:11] **Jonathan Lennox**: the

[00:54:11] **Mike Blanche**: charter because worker works for certain things, but not for others. And, yeah, we can get we can get very confused if we don't start with terminology.

[00:54:19] **Martin Thompson**: Yes. I I was very bad. David was very clear in his instructions and said that we need to use the words proxy and worker in this context. I think we've successfully confused everyone at this point now.

[00:54:31] **David Schinazi**: Yeah. Yeah.

[00:54:31] **Martin Duke**: Great.

[00:54:33] **David Schinazi**: I was just hoping that all the presenters would use the same words because last time we didn't, and it was confusing. But this is ITF. We fail we find a way.

[00:54:43] **Kent Watsen**: Okay. I'm gonna try and take another bite at the apple. This is Kent again. Your next slide, scaling. You you frame it exactly the opposite the way that I would. In in in when you have a controller managing a plethora of device devices, the scalability is on the orchestrator or the controller. Each worker or device would, you know, not necessarily itself having to spin up more instances of itself when it's, like, under load. It would be the orchestrator that's doing it. In Mario's presentation, he had a slide where there's a fat pipe between what he called the proxy and the origin server. And I would actually you know, okay. I get that. But if I were to, as an architect, try to implement a software for it, I'd have a proxy as a component inside the controller. Right? So and it's kind of important that way because, like, we're doing zero touch. The device is turning up anytime. The origin sorry. The controller doesn't know when the device turns up. So if the device turns up and it connects to the proxy, how does the controller become aware of the fact that the device is looking to become managed? So by by grouping the proxy

[00:56:02] **Martin Thompson**: I think

[00:56:02] **Kent Watsen**: controller, then it's all top

[00:56:04] **Martin Thompson**: I I think you've just highlighted Mhmm. Why the the four stars might be a five star. Yeah. But it doesn't change the one star determination. Okay. So, yeah. I think

[00:56:15] **Michael**: I think that's that's a that's

[00:56:16] **Martin Thompson**: a good thing to explore. But I think you're thinking about a very different deployment to a lot of folks who are I I am. Who are deploying this. Yeah.

[00:56:21] **Kent Watsen**: Appreciate that. And as I mentioned before, RESTCONF call home, it actually already works. It's highly deployed by all vendors, Juniper, Cisco, Huawei, etcetera. The thing is that now we wanna use QUIC. So RESTCONF over QUIC, which works but not in the reverse direction. And that's necessary for Deep Space management manageability.

[00:56:43] **Martin Thompson**: Yeah. I'm gonna sit down right now because I think we've just ended the discussion phase. But I'd like to give back to the chairs because I think they wanna do a little bit of framing. I I noticed that we have an ID here. Mike gets to say something, but no one else.

[00:56:57] **Mike Bishop**: Well, I'm not speaking with my hat on at this point.

[00:57:00] **David Schinazi**: No. No. But

[00:57:02] **Martin Thompson**: I will get back in line then.

[00:57:03] **Mike Bishop**: I did have a clarification between your two and three. There seems to be an an implicit assumption here that the the proxy, the whatever you wanna call it right now, knows something about load on the origins on the workers. We and where do you think that flow fits in in each of these problems?

[00:57:31] **Martin Thompson**: So I didn't wanna get too much into this one, Mike, but you might imagine that the proxy is making a request to a worker and is unable to because it simply cannot get more streams from the HTTP two or three connection. That's the sort of thing that I was thinking of. There may be other ways in which they that we have to explore the problem to make a richer signalling for this purpose. Again, suggest that that's a problem for future us and not in this charter iteration. Yep.

[00:58:08] **David Schinazi**: Thank you, Martin. So getting back to the chair slides, which, by the way, I was able to fix the rendering of your draft, Martin. You're welcome. All right. Okay. One, two. Okay.

[00:58:36] **Hannes Tschofenig**: Yeah, good idea. Let's do an open mic before we go into these basic questions because afterwards, we would like to then spend time on the fine tuning of the charter text. You've seen the charter being posted to the mailing list and we have them up on the slides as well so you can read through them. We'll definitely do that. But that only makes sense if we can even answer these questions positively. So, maybe we do a show of hands.

[00:59:09] **David Schinazi**: Let's let's

[00:59:11] **Hannes Tschofenig**: see what but the first Yeah.

[00:59:13] **David Schinazi**: If people wanna, like, ask questions or comments before we jump into the both questions, please feel free to get in the queue now. So I see Michael.

[00:59:27] **Michael**: Yeah. Great. So for the the first question, I don't think that the problem space is sufficiently well at least articulated yet. I've got at least a list of, like, three other or four other use cases that I think would be good to introduce. It seems like we've got a lot of, like, workers for serving websites from a large company through CDN. There's a lot of peer to peer cases that this opens up. I guess I'll just quickly list. So the activity pub Mastodon situation, you've got two servers that are both synchronizing with each other. And right now, they have to open separate TCP connections to each other. It'd be nice to do that with one connection. It also there are also some use cases where a server would like to ask a client for some state. So you could think of that roughly as your web server asking your browser, you know, where's the mouse cursor or some other state in the client just to to put in your head. But there's some useful cases for that that I've been developing on, for instance, that I could give examples of. Also, pushed updates. There are a number of proposals for subscribing to state over HTTP where you can push updates from the server to the client. And those or from a server to a server, those oftentimes are in the form of the server sending a request to to push the updates. You send a put with the new value. And I'll just I'll just put it at that just to sketch the rough scope. And I think there could likely be more to flesh out, but that's kind of the array of what I've been looking at.

[01:01:10] **Hannes Tschofenig**: I Michael, I hear you say that you would possibly answer the question as, is the problem space well understood? You would say, yes, but I have even more use cases in mind, which, like, in the way how we started this off, obviously coming from a specific domain. And that's where we put the folks together. They have the use cases that you just mentioned with the VPN type of scenario or the classic CDN scenario. And, yes, indeed, I can see some of those additional use cases, which we didn't go into. And, probably, if we would do that, at some point in time, we would have to invite those proponents and figure out who are the stakeholders who care about the characteristics. Because, typically, it's not just the use case. There's many more aspects that we would have to look into. And, I think, from a starting point, this looks to us, at least David and myself, as a tractable problem if we scope it down to, for example, what Martin proposed. Because, in general, the classical mistake that one can make is to work on everything at once. And then because then we get nowhere. So we want to start small and then accomplish something and then see where the where the journey goes.

[01:02:40] **David Schinazi**: Yeah. And what I would add to that is I think our current scope of taking HTTP and just reversing it is a much simpler and track more tractable problem than changing HTTP semantics. I think if we wanna go in that direction, that would have to happen in the HTTP base working group. And so I think while some of your use cases might benefit from this, some of those might be out of scope because of the multiple layers that would need to be changed.

[01:03:09] **Michael**: Yeah. No. No. I'm not arguing for an increased scope, certainly.

[01:03:13] **Hannes Tschofenig**: But I

[01:03:13] **Michael**: think that as we do the work of defining the scope, I think it helps to keep in mind the broad array of of use cases. And I think we could probably do some more work in flushing out what those are, especially because this could be a building block that other things could be maybe these all these use case maybe all the use cases aren't complete from the work done here, but it could be a building block that others could flush out on in the future. Thanks.

[01:03:39] **Ted Hardie**: Ted Hurti, occasionally present with friendly suggestions. May I give the two of you chairs the friendly suggestion that since the first question you're asking requires a consideration of the scope and the charter spends a great deal of time talking about scope and what's out of scope, that you, in fact, do delay these questions until after you've reviewed the charter. Whereas I think doing it without doing that, you're going to have more questions like that where people are imagining a scope and trying to decide whether their particular preference is included or not. So I suggest we actually do delay this, do the charter discussion first, and then come back to these. Thank you.

[01:04:19] **Hannes Tschofenig**: Since you are very experienced ITF participants, I will follow your suggestion.

[01:04:28] **Rick Taylor**: Rick Taylor, so this is kind of triggered by one of the earlier presentations. I'm trying to go for question two and three here. Do we have an interoperability problem here or is it so I'm seeing nods. That wasn't clear to me. So if we are seeing that people want to get this to interoperate, then I see this as likely to be valid work. My second question was, was this just an effort to lean on the expertise of the people who attend the IIT ethnology to solve this problem, which is I think quite a critical question. But if people are nodding on interoperability, great. And it was your

[01:05:07] **Yaroslav Rosomakho**: Yeah. Just to give sorry for triggering you. Just to give a perspective from kind of ZTNA vendor space, it's generalizing probably to unhealthy degree, but most ZTNA vendors are in cloud services business, not in deploying all those gateways, boxes, shipping boxes business. So if we would standardize that, make it interoperable, make it vendor agnostic, that I think would be helpful for everyone.

[01:05:38] **Hannes Tschofenig**: Okay, that's good. So, let's jump to the slides on the chartered text. Here's again the link to the text. I think this is actually the start of the text already. PDTH group, Protocol for Transposed Transactions over HTTP, a little bit contrived. Working group is chartered to define a standardised mechanism for reversing the roles of HTTP clients and HTTP servers in a secure and interoperable way. This enables the creation of connections where the transport interactions are initiated by the entity that acts in the HTTP server role. Good, Shufar.

[01:06:21] **David Schinazi**: If anyone has questions or comments on this part, jump to the mic. Otherwise, we'll go to the next paragraph.

[01:06:33] **Hannes Tschofenig**: It was on the mailing list, the link to the GitHub repo, but scan the QR code. I think the QR code leads us to the charter text as well.

[01:06:42] **David Schinazi**: I'll put it in chat too.

[01:06:46] **Hannes Tschofenig**: Okay. Thanks, Ted. Okay. So, we'll continue. Oh, that's a good point. Thank you. In HTTP deployments, the client initiates requests and a server response. However, a growing set of use cases such as dynamic service hosting, edge computing, natural reversal, privacy preserving architectures and application layer round boost require that the entity in the HTTP server role be the one to initiate the transport layer connection. PTTH allows such transposed transaction where a transport layer client can act as an HTTP server and a transport layer server can act as an HTTP client. That way, the transport layer client can receive HTTP requests from a transport layer server and respond to them under explicit agreement and control. So, slide, I think, should make the scope of the work reasonably clear, I would hope so. You want to go to the bullet points? Okay. Alright.

[01:07:56] **David Schinazi**: Do you have a specific question about this text, or is it about the scope in general?

[01:08:01] **Jana Iyengar**: I do. But I think that's Ted's way of saying, Jenna, leave the mic. Alright. I'll yeah. Yeah. I'm gonna so just to this is a clarification question. I'm not wordsmithing or being a pedant here, but it says required. Require that the entity in the HDB server will be the one to initiate the transport layer connection. Nothing I heard today requires it. It seems like they would do better with it. Is that the intent? I don't care to wordsmith. I'm just trying to understand the intent here.

[01:08:31] **David Schinazi**: I think you're right. There are proprietary solutions that exist. And if we wanted to do this with HTP, that would require it. But I I think we're Smithing, that makes sense.

[01:08:42] **Hannes Tschofenig**: Thank you. Let's get to the bullet list. No, that's not yet there. Okay, the concept thing. The PTTH protocol will reuse existing HTTP concepts and designs wherever possible. The protocol will define how one endpoint can indicate its willingness to receive HTTP requests from the remote peer, how such requests are carried, and how security and probability are maintained across different versions of HTTP. The working group will produce a standard track specification that defines the following: a protocol mechanism to enable a transport layer client to receive HTTP requests from a transport layer server and respond to them rules and constraints for how transposed HTTP requests and responses are encoded and transported negotiation and signalling mechanisms security and privacy considerations authentication, authorisation, and origin constraints compatibility and applicability to existing HTTP versions reuse component, guidance for implementation and deployments in diverse environments. In there's a PR up there on the GitHub repo that access two of those bullets, namely the security and privacy considerations because those are needed in all of the documents. So, it's a little bit sort of like artificial in some sense because we have to do it anyway. And the negotiation and signalling mechanisms sounded a little bit too generic and can be covered with the previous items. Ken, do you want to say something about Yeah.

[01:10:33] **Kent Watsen**: What's in scope? I guess my question is, does the worker know who the clients are beforehand? Or is it more like it just sets up the service and any client can connect to the worker?

[01:10:50] **David Schinazi**: So HTTP is a multi hop protocol. So in this if you're thinking of a single hop, the what we call the worker will create a transport layer connection to the proxy, and it will pick one that it will then receive requests only from it. However, that proxy can be forwarding requests from other places. Okay.

[01:11:13] **Kent Watsen**: So if that is your use case, then it's not gonna work for what I was talking about, managing devices like RFC eighty seventy one.

[01:11:24] **Hannes Tschofenig**: Sure. Sure. I would like to understand that a little bit better, but Yaroslav.

[01:11:31] **Yaroslav Rosomakho**: I'll I'll just respond to that. So from existing deployments, there are both use cases in proprietary land. So for for example, for CDN regions when you're serving public content, well, you you really don't know who who those random strangers, bots, people up Internet that access your resources. As far as I understand, inject, like, an additional header to tell you the IP address or potentially other information. In case of ZTNA, both scenarios are possible. And I have seen in the wild somewhere authorization is completely delegated to the proxy side. You just get the request and you kind of trust proxy to do the necessary authentication authorization of the clients, or sometimes you get additional implementation specific, like a header or some kind of signature telling you about the nature of the client so you get to authenticate, authorize that. I'm not sure given that it is use case specific. I'm not sure if that should be in the charter, but with versatility of HTTP, clearly, both options are possible.

[01:12:42] **Kent Watsen**: Okay. And just to put a clarification on my point, when the devices, the network elements are trying to call home, they know exactly where they're trying to call home to. They were configured for manufacturing with an IP address or usually a domain name to connect to. So they know who they're trying to connect to, but it needs to be a reversal connect a reverse connection. I'll just add that r C eighty seventy one, even though it's called call home, like RESTCONF call home, it was originally called reverse TLS. And it actually is reverse TLS. If h t t p three never happened, then reverse h t p three sorry. Reverse h t p would have just simply been on top of reverse TLS. H t p on top of reverse TLS. It works. But with QUIC, that's the problem. H three, I can't reverse.

[01:13:32] **David Schinazi**: Yeah. And for what it's worth, one of the proposals, Martin's in particular, doesn't reverse TLS itself, but it reverses the application layer on top. So conceptually, for h it is very similar to what you described. But the TLS client and server roles are maintained.

[01:13:50] **Hannes Tschofenig**: I think we would all need to understand more on the solution space and the use case to really tell you, like, how that would shape out. I wouldn't want to, like, shoot from a hip and and tell you a lot that this is already in scope of the charter because I really don't know. Michael?

[01:14:13] **Michael**: Okay. So the one question that I have, I don't know if it's in or out of scope, that relates to the past use cases I brought up is whether this is gonna generalize a connection so that both parties can send respond request and get responses or whether it's strictly reversing it.

[01:14:31] **David Schinazi**: So that we've explicitly not made a decision on yet because some proposals enable this and some don't. And we're hoping to decide it in the working group if we were to form it.

[01:14:45] **Michael**: Okay. So part of the scope then would be to figure that out, I guess. Yes.

[01:14:53] **Hannes Tschofenig**: Jonas.

[01:14:54] **Jonathan Lennox**: Jonathan Lennox. Yeah. I mean, I'm just going to question a little bit the last bullet point on this slide. I feel like that guidance is a nice to have, but not necessarily as part of the initial standard stretch specification. And it seems like more something you'd wanna write after you've got some deployment experience and know what to tell people. So I think maybe that shouldn't be part of the initial standard spec specification, but maybe a follow on document or a nice to have or something like that. Also, somebody pointed out in the chat. It's not clear. The the it's currently word as though it will be a single document, whereas it might wanna be broken up. So I wanna be worded to

[01:15:30] **Hannes Tschofenig**: Good point. Yeah. It probably should reproduce one the or multiple, because we don't really know how we would really do the document management. On the last point, the rationale was that this is, like, in IEC review and in general discussion, there are often questions about operational aspects. And we have these insights, although from proprietary protocols, but those are ones that we could talk about in the documents. So, that's hinting to those implementation and deployment considerations. So, I think it's a good item to have in there. Okay. Do we have Mark?

[01:16:27] **Mark Nottingham**: Hi. Hi, Mark. Nottingham. Looking at the draft charter, I'm wondering, somewhat out loud, whether it would be good to explicitly say that the group should not expand or or or change HTTP semantics. Because I think there's gonna be a a bit of an attractive nuisance here to say, oh, while we're doing this, we could do that. And then you have a mismatch in semantics where it works over PTTH, but doesn't it work over normal HTTP, or something. You go off in a different direction. So I'm wondering if that would be a useful constraint to help focus the group's work. Okay.

[01:17:07] **Hannes Tschofenig**: David is going to live edit issues and a GitHub tracker, we'll keep that one in there as well. Michael, do you have another point?

[01:17:20] **Michael**: Yeah. Actually, just to elaborate a little bit on Mark's, I have this fear that a lot of the items on the that scope slide, the previous one, when you take out the server from HTTP, then you you've taken out authentication, authorization, the authority, routing, and a lot of the and load balancing across DNS. And then we have to redo them, and so I'm just afraid of redoing HTTP. But I I believe we can do it, but that was just a framing of my mind that also led matched with Mark. That's all.

[01:17:54] **Hannes Tschofenig**: But the the proposals that we've seen so far, the two live documents available, they make me feel good so that we don't go off into the weeds.

[01:18:07] **Michael**: Great. Yeah. I think it's doable, but I just wanna keep that in mind.

[01:18:10] **David Schinazi**: Yeah. Absolutely. And another way to think about this is that a lot of HTTP servers are also HTTP clients in that, like, their proxies where they receive requests and sometimes they don't answer it locally unless they send it off to something else. The big potato here, if we don't wanna call it a proxy, would be the same in except that that onward connection is this reversed one, but it would still have the routing layer locally.

[01:18:40] **Hannes Tschofenig**: Okay. Emily, do you want to say something?

[01:18:50] **Ted Hardie**: Yeah. I have perhaps

[01:18:51] **Hannes Tschofenig**: one clarification question with regard to web you hear me? Soft. Soft. Put it closer. Yeah. Yeah. Is a server send event on WebSocket in the in the scope here? Are they are they covered by HTTP or no?

[01:19:11] **David Schinazi**: No. That's not part of HTTP currently. Well, shit. Martin's getting up to answer. I mean, he's gonna say something smart, I'm sure.

[01:19:22] **Hannes Tschofenig**: Oh, no. I didn't in the same bag, the the quick streams as covered by that or or not?

[01:19:30] **David Schinazi**: Those are specific to HTTP versions, whereas here, we're just taking the HTTP semantics and flipping them around is how I think about it, at least.

[01:19:39] **Martin Thompson**: So so the answer is that if you if you buy HTTP, you get the whole thing. All of it. WebSockets, web

[01:19:45] **Hannes Tschofenig**: transport, web quick, blah blah blah blah blah. So it's easy to to list the RLC, which are covered by that in the charter explicitly.

[01:19:54] **David Schinazi**: I don't think that necessarily makes sense because we keep publishing new ones every other day. Like, there's a new thing over HTTP very, often. Yeah. Mhmm. Do you wanna oh, I guess

[01:20:10] **Hannes Tschofenig**: Okay. Ben?

[01:20:13] **Ben**: Hi. On the yeah. That slide. What is an origin constraint? Sorry. I was in another meeting.

[01:20:23] **Hannes Tschofenig**: Did you hear what he said? He the and the out of scope slides.

[01:20:28] **Martin Thompson**: Sorry.

[01:20:28] **David Schinazi**: Were you you were asking on the deliverables slide or on the out of scope slide?

[01:20:33] **Ben**: Deliverables, what is an origin constraint?

[01:20:38] **Yaroslav Rosomakho**: I I can try to respond to that. The origin the idea of origin constraint is that there there must be constraint what kind of origin a worker can claim. So that

[01:20:49] **Michael**: So it is

[01:20:50] **Ben**: it is a constraint related to one or more origins. I'm asking because I think there will be use cases where people want to constrain to fractions of an origin.

[01:20:59] **Yaroslav Rosomakho**: Probably, but that's essentially maybe clarification of what authorization implies in this case.

[01:21:08] **Ben**: It's not just authorization. It's also routing where you potentially imagine multiple workers each claiming a fraction of an origin, and now queries need to be routed to the right worker. I think that should be out of scope. I think it's very valuable. I think it should be out of scope. I think we should, like, write that down.

[01:21:30] **Hannes Tschofenig**: Okay. Thank you. Okay.

[01:21:34] **Lucas Pardue**: Lucas Pardue, kinda thinking out loud on the deliverable front. Kind of reads like it's all versions of HTTP that are in scope for this. And in my experience, say in WebTransport, we ended up breaking out the actual protocol documents from the overview of the high level design that was common to all of them and kind of deferring some of the decision about which versions to support in practical because we need to understand who the implementers are in the room and and who want all of the versions or a subset of them. So I just wondered, like, do do we wanna embed in the deliverable right now a commitment to all of those? The which documents they will land in? I don't care. You can figure that one out later. But I I couldn't remember if we said there are people in with use cases that would want HP one, two, and three.

[01:22:30] **David Schinazi**: Alright. Not to wordsmith too hard, but it says to existing HTTP versions, not to all existing version HTTP versions. But we we maybe we clarify this because I agree. It's possible that we leave h one on the side of the road if no one wants to use it.

[01:22:47] **Lucas Pardue**: It's not not something to face plant on now, but just thinking out loud.

[01:22:50] **David Schinazi**: Yeah. No. No. Thanks. We can

[01:22:51] **Hannes Tschofenig**: we can improve that text for sure. The issue is yeah.

[01:22:55] **David Schinazi**: Okay.

[01:22:56] **Hannes Tschofenig**: Uh-huh. Issues? Good.

[01:23:00] **Ben**: Yeah. I I Go ahead. On the HTTP version topic, I interpreted that differently because in my view, the the h HTTP is the protocol that the client is speaking to the proxy. It has a version. The thing we're doing here is a to be determined new thing that may have no relation to any existing HTTP transport and should be compatible with any HTTP version that the client is speaking to the proxy.

[01:23:32] **Hannes Tschofenig**: Okay. Into that yeah. That's that's a good interpretation. We don't want to constrain the communication between the client and the proxy, because we are talking about the leg here. Okay. We need to jump to the

[01:23:55] **Martin Thompson**: Jonathan.

[01:24:02] **Jonathan Lennox**: John, like, just to repeat again something I said in the chat. I thought I think the question of fractional origin should be neither in nor out of scope, but rather something the working group can decide. I don't think it should be decided in the charter one way or the other.

[01:24:15] **Hannes Tschofenig**: Okay. I see some support for your statement, Jonathan. So it would be like one of our previous items. What was that? Forwarded. Okay. Go to the next slide on out of scope. We finally get there. So, those were three items that we had in discussions. We fought those were came up and we explicitly thought that we should really sort of like keep that out of the charter, namely developing transport mechanism for protocol other than HTTP specification of usage specific signalling or policy frameworks, and the last one, developing locator mechanisms for server discovery. Any fingers that comes

[01:25:17] **David Schinazi**: And I filed an issue to add a bullet for changing HTTP semantics as out of scope, as Mark suggested.

[01:25:26] **Mike Blanche**: Mike? Thanks. That support, Mark's suggestion, definitely not to change HTTP. The last one, just for my clarification, that means the only discovery that's gonna be done is once the connection has been made, discovering that the other end can reverse the connection. Right? There's not there's no there's gonna be no discovery like Dawn off is looking at doing and that sort of stuff. Right?

[01:25:51] **David Schinazi**: That's right. We're not gonna have a registry of servers that support this.

[01:25:55] **Mike Blanche**: Yeah. I don't know if there's a better way of wording that to be clear. Maybe it's just me being dumb. Thank you.

[01:26:04] **Mike Bishop**: Mike Bishop, again, not with a hat. I think here we might want to given that we have transport layer servers and HCP servers being different endpoints in this connection, we might wanna specify which server we're talking about.

[01:26:21] **David Schinazi**: Alright. I'll I'll file an issue for that. I'll I'll file an issue for that. That's a good point.

[01:26:31] **Hannes Tschofenig**: Let us catch up a little bit on the do do you have that?

[01:26:35] **David Schinazi**: And then this is the the last one.

[01:26:37] **Hannes Tschofenig**: Yeah. But we have Ted, weren't you just on the Okay. Ken.

[01:26:44] **Kent Watsen**: Tagging on to Martin's comment about how this is just all h t p semantics. With v three and I think also v two, the connection through the proxy, you know, from the client to the worker, it's an end to end connection. So the encryption happens. It's tunneled through the proxy. Right?

[01:27:06] **David Schinazi**: No. Okay.

[01:27:07] **Hannes Tschofenig**: No. No.

[01:27:08] **Kent Watsen**: Alright. Never mind. Okay.

[01:27:12] **David Schinazi**: Just in terms of how HTTP hop by hop works. It's kind of routed hop hop by hop. Okay.

[01:27:23] **Hannes Tschofenig**: Milestones. The milestones are a little bit fussy at that point because we have to guess on how long it would take to come up with one or more of these specifications. So we have two examples already. So but I would assume that it would take at least a year to get those to probably a year is unrealistic. Like, from all let's say or probably I'll not say anything. Mike has suggestion here.

[01:28:00] **Mike Bishop**: This time with a hat on. I don't mind giving you undated milestones. Please don't waste time on trying to guess your

[01:28:07] **David Schinazi**: Perfect.

[01:28:07] **Hannes Tschofenig**: Okay. Like that. Like that. It's like looking at the crystal ball. I know this is not a management type of style, but okay. Liaison, obvious thing. The BTDH working group will coordinate closely with the HTTP working group to ensure architectural alignment with existing and future versions of HTTP?

[01:28:29] **Ted Hardie**: Ted Hardy. I think it would be polite at least to liaison with that the w three c tag that you're going to do the work and get their input at periods periodic.

[01:28:38] **Hannes Tschofenig**: That's a

[01:28:39] **Ted Hardie**: good Good point. Intervals through throughout. As I I realize we're not planning on changing HTTP semantics, and I think making that very clear in the first liaison to them would be really good news. But because this will change some of the capabilities of the web, they would probably like to know about it and to think about it.

[01:28:59] **Hannes Tschofenig**: Yep. Add it as an issue.

[01:29:01] **Magnus Westerlund**: Magnus. Magnus Magnus Westlin, Ericsson. Question on the out of scope things on this first bullet there. Is it transport mechanism or actually transport layer or transport layer protocol mechanism you it's ruling out the scope for other protocols than HTTP.

[01:29:23] **Hannes Tschofenig**: What what so do you have something or you maybe you

[01:29:27] **David Schinazi**: I I if I'm understanding you correctly, I think our intent here was we are not gonna reinvent a new TCP or a new QUIC. So maybe we should say or also, we're not gonna do work to reverse another application protocol. So maybe we can tweak that wording to be more clear about that.

[01:29:46] **Magnus Westerlund**: Because otherwise, you use transport layer protocol mechanism for the positive work you're gonna do. So I was just wondering. So it seems to be a little in in.

[01:29:56] **David Schinazi**: Yeah. No. That that that's that's good feedback. We'll tweak it.

[01:30:00] **Hannes Tschofenig**: Ben Ben, I skipped you. Sorry. Go ahead.

[01:30:07] **Ben**: Hi. So sorry. Again, I missed part of this meeting, but one thing that isn't clear to me from the charter is how we are thinking about identity. In my view, there are basically two ways to think about identity in PTTH. In one way, the identity is essentially proprietary. So a worker connects to the proxy and says, hi. I'm account number whatever on this CDN and authenticates itself using essentially private authentication flows within the account scope of the CDN. And the other identity mode is essentially public identity where the worker connects to the CDN and says, hi. Here's a certificate through, like, the web PKI that proves that I am a particular origin. So I'll request for that origin forward them to me because that's me. I I think that we should say something about identity here. I would propose something like that's out of scope to define a, like, new global identity system? I

[01:31:29] **Hannes Tschofenig**: have as many of you know, I've, like, chaired the OS working group for the eighteen years or so. And every time I hear identity and people wanting to define identity, it scares the heck out of me, because I've been through that journey many times. It might be difficult to write something meaningful there, but if you want to give it a try, Ben, you're welcome. Because you you just just pointed out that it's actually complicated on, different parties where you have, the CBN case, we have different customers. They need to somehow be addressed in this authorisation decision. There's the origin question and so on and so on. So, it may sound easier than it actually is to write something meaningful without raising more questions. But go ahead. We put it into the issue list. Alright. Jonathan.

[01:32:34] **Jonathan Lennox**: John Lennox again. Yeah. I maybe this is obvious, but I kind of wanna say we're not gonna specify any of the things we don't the ITF doesn't specify for reverse proxies, like how it gets your your your certain pry its private key for your domain or, you know, how you choose which one to use or anything like that. You know? All that stuff which we already don't specify, we continue to not specify for this either. Maybe that's obvious. We don't need to say it. But

[01:33:08] **Lucas Pardue**: Lucas, pardon again. So I'm gonna think aloud again, but try and keep it within the constraints of this slide, which is safer for QUIC. Like, we don't wanna do other changes. I get it. That's cool. I would agree with that. But one of the the so called killer features of QUIC are things like connection migration and multipath. And those have certain constraints on which role can do what. And already, we're seeing in Quik some discussion about people kind of saying, wouldn't it be nice if the the other role could have some of the capabilities of the other thing? And as attractive as that might be, it could be a huge distraction. So for example, a server, whatever the server here would be, would be allowed to initiate a migration to the other thing. As I think especially in the deployment architectures, we might want something like multi path would be attractive because you want service reliability, say, two hot paths with redundancy, etcetera. I don't want to go into any of that. And I think maybe it should be classes out of scope, but not blocking in that. If people wanna go away and do that thing, could, and that they need to figure out the mapping for all of this stuff. Does that make sense?

[01:34:26] **David Schinazi**: Yeah. I would say based on Magnus's comment, we are gonna add an out of scope bullet point for developing transport layer protocols. What I'm hearing from you is developing transport layer protocols or changes to them are all out of scope here. And if the quick working group wants to do something that plays really nicely with potato, then we're great. But that would be then over there.

[01:34:49] **Lucas Pardue**: Definitely for the first iteration of this work. Like, let's keep it as focused as possible and inspire ourselves to go and do crazy shit later on.

[01:35:01] **David Schinazi**: Alright. I think we can go to the both questions.

[01:35:04] **Hannes Tschofenig**: Okay. I think we drained the queue.

[01:35:17] **David Schinazi**: Okay. So, we're gonna ask these questions. Let me put the first one in the show of hands tool. So,

[01:35:25] **Hannes Tschofenig**: we followed that suggestion. I think that was actually a good idea. I hope that you all have a much better understanding now about the scope of the work and the problem we are trying to solve here. You would be able to answer the question, the first question, hopefully, after this debate and after the use case presentations and now after I read the chart next to you? Do you want to read the question? Yes. So, reading that question. So, is the problem space sufficiently well understood? Say yes, no or no opinion if you slept.

[01:36:11] **David Schinazi**: I see Marco in the queue.

[01:36:15] **Marco**: Yeah. Just a quick clarifying question on the first one. So I feel like we still have this open question of whether we want this bidirectional or not. So putting that aside are we putting that aside to answer this question, or is that part of this question?

[01:36:33] **David Schinazi**: So our intent is to does it make putting push that aside for chartering for it to become a decision that is made by the working group once it is formed. Okay. Great. Thanks. Good. Should we we're we're gonna close it, I think. Please jump in if you haven't yet. And we're gonna invite since there are two noes, please come to the mic and say more about why you don't think this is well understood. We'd love to hear your thoughts and opinions.

[01:37:14] **Hannes Tschofenig**: Of course, only if you want.

[01:37:17] **Austin Wright**: Hello. Austin Wright, partial content enthusiast. I mean, I don't my concern isn't I don't think that's a roadblock by any stretch of the imagination, but it it's there's the logical extension of this is, like, can we have a hub or reverse proxy that connects to a user agent? And then the user agent makes requests to the gateway hub reverse proxy thing. And then we have you know? And from there, we can talk about reverse caches and all of these other things. I don't think we've thought to that extent yet. I'm sure there's not that's not gonna be a problem once we think it out, but I'm thinking about those sorts of problems right now.

[01:38:09] **David Schinazi**: Cool. Thanks. And I think this is exactly the kind of thing that people will be able to build with this and HTTP semantics once it exists.

[01:38:20] **Hannes Tschofenig**: Okay. So, here are the numbers. 43 yeses. We had three no and five no opinion. Okay. We move on to the next question. Namely, is there a problem worth solving? So, is there even something there that we should be tackling? Give you a few more seconds. Okay. I think we cut it here.

[01:39:11] **David Schinazi**: Okay,

[01:39:18] **Hannes Tschofenig**: let's stop it here. The result is we have 43, 44 yes, one no and seven persons with no opinion. And the last one

[01:39:31] **Martin Thompson**: The

[01:39:37] **Hannes Tschofenig**: next one is, of course, an important one. Even if the problem is worthwhile to solve, is this actually the right place to do so? So, the question is, is the IDF the right place to solve this problem? Give me a few more seconds here. Okay, let's stop here. We have 54 yes, zero no, and two with no opinion. And then, the last one, the last question on our list is, is this proposed charter the right basis or the right foundation to form an ITF working group? Of course, given the discussion we just had, we have to sort of do various tweaks and iterations here. So, assume that those would be successful. So, it's more a directional thing rather than the completely final draft text. But, Martin, you have a

[01:40:58] **Martin Thompson**: I was just going say, I've put a pull request up that I think captures most of the discussion already. So, anyone who wants to join, it's in the chat.

[01:41:05] **Hannes Tschofenig**: Is that AI driven or what? This is so fast.

[01:41:12] **Martin Thompson**: It it involved a lot of the use of the delete key. So I think

[01:41:22] **Hannes Tschofenig**: Okay. Yeah. Okay.

[01:41:27] **David Schinazi**: It a bit more time.

[01:41:27] **Hannes Tschofenig**: Yeah. Let's give you a few seconds. We can pull the trigger here. So, we have 29 yes, noes, no and eight with eight persons with no opinion. How are we doing time wise?

[01:41:56] **David Schinazi**: We have some time left, but with the great American idiom, quit while you're ahead, We're gonna invite our responsible AD to come share his thoughts.

[01:42:09] **Mike Bishop**: Thanks. So I think they're pretty strong signal there with the lean toward yes, so that's encouraging. I do have to note that the number of people who said yes or really anything on that last question is markedly smaller than the people who responded to the first two. And I'm curious whether there are people who felt like they weren't ready to give an opinion on that or just what was going on there? That could certainly be a certainly be an explanation. The comment was they were busy reading Martin's PR. I

[01:42:56] **Hannes Tschofenig**: maybe another question we could ask, which is always interesting, is a show of hands on who plans to either review, actively participate, like in discussions, or plans to even write documents or contribute to documents or implement or deploy. But, I lump them all together just to see if you are just here because it's cooler inside than in some of the other rooms? The question is, Carl? So, this is the final potato, it looks like, after all that work.

[01:43:50] **Mike Bishop**: The potato with a few sprouts.

[01:43:51] **Hannes Tschofenig**: Okay. So if you if you made a small mistake. No.

[01:43:56] **David Schinazi**: It's that's supposed to be a potato emoji, but it didn't it doesn't render.

[01:44:21] **Mike Bishop**: Yeah. On in the mobile version, it does show the emoji.

[01:44:25] **Hannes Tschofenig**: So On the mobile version, it shows it? Yes. That's fantastic. I'm not sure what no opinion means here, but that's the the the sleeping crowd. But

[01:44:41] **Jana Iyengar**: I'll just say, Hannes, that this is this question is so broad.

[01:44:45] **Hannes Tschofenig**: Well, it's but still

[01:44:46] **Jana Iyengar**: it gives us to say no to it. I mean, I do wanna discuss, but I don't wanna deploy it. Well I'm gonna say yes. But discussion is basically being in this

[01:44:53] **Hannes Tschofenig**: I I want to so I have been in groups where people say, it would be fantastic if someone does that work, solve that problem. In fact, I shared one of those groups, but then nobody actually wants to work on it. Like, this is this is not artificial.

[01:45:06] **Jana Iyengar**: No. I completely no. I completely agree on Yeah. People putting in time and working on it. I think we you should ask that question. This question may be too broad on the first couple. Like, you know

[01:45:19] **Hannes Tschofenig**: Yeah. It's it's too premature to say deploy because we we you don't know even what to deploy. But Or

[01:45:26] **Jana Iyengar**: or even yeah. If if if the question is specifically even forget Okay. Thinking that, maybe you may wanna just ask and be very clear about the fact that you want people to do active work Active. Yeah. On the documents or on the implementations. Yeah. And I think that's

[01:45:41] **Hannes Tschofenig**: yeah. The Don't forget to deploy. So you don't need to make promises to deploy any of this, which you haven't seen yet. Good point.

[01:45:53] **Kazuho Oku**: I interpret it as no opinion, as I don't know yet. Maybe. Okay.

[01:46:03] **Hannes Tschofenig**: So, yeah, would you like to actively participate in this in this proposed group?

[01:46:28] **David Schinazi**: I'm seeing a slide request from Chloe. Is that intentional? I'll just decline it then.

[01:46:39] **Hannes Tschofenig**: No, no. We don't share stuff from random people on the Internet. Okay. 19 people who would like to or who consider to participate, I think that's a pretty good number. 20 now, after I said that. Mike, some famous last words here? Perfect. All

[01:47:13] **David Schinazi**: right. In that case, thanks, everyone. We'll take Martin's PR, have Eckers bot review it and merge it. And

[01:47:23] **Jana Iyengar**: Now that we have time, let me recommend that instead of showing a potato with spuds as the end of the work, show vodka. It's a lot more attractive.

[01:47:34] **Hannes Tschofenig**: Wait. What did he say?

[01:47:36] **Kent Watsen**: Oh. Oh.

[01:47:38] **Jana Iyengar**: I mean, a potato with spuds is not that exciting. Vodka's a lot better.

[01:47:45] **David Schinazi**: All right. Thanks everyone and have a great rest of your day. Join my mailing list if you haven't already.

[01:47:55] **Hannes Tschofenig**: We should make a picture. Oh,

[01:47:56] **David Schinazi**: yeah. We do.

[01:47:58] **Hannes Tschofenig**: Put the potato on there.

[01:48:00] **David Schinazi**: On the This one. Thing.

[01:48:01] **Hannes Tschofenig**: Yeah. Yeah. Yarosav, take a picture of us. Potato picture. Like

[01:48:07] **David Schinazi**: the last

[01:48:07] **Kazuho Oku**: time. Yeah.

[01:48:18] **Hannes Tschofenig**: Button in the front. This one. This this one. Yeah. Mike, stand behind us. It looks, more

[01:48:31] **David Schinazi**: authoritative. Yeah. Look

[01:48:35] **Hannes Tschofenig**: like look like she's yeah.

[01:48:45] **Martin Duke**: Awesome. Thanks. Alright.

[01:48:47] **Hannes Tschofenig**: Thank you.

[01:48:47] **Yaroslav Rosomakho**: Thanks.

[01:48:55] **Hannes Tschofenig**: I I know you you have been. What the heck is going on? What are these Yeah. These crazy guys doing?

[01:49:06] **David Schinazi**: Yeah. It was my job to do it after the World Cup final, but the game lasted way longer than I expected, and I got to my hotel room and collapsed.

[01:49:14] **Hannes Tschofenig**: That's what happened.

[01:49:15] **David Schinazi**: So that's the

[01:49:16] **Martin Duke**: reason. Yes.

[01:49:19] **Hannes Tschofenig**: It was good. But thanks to

[01:49:21] **David Schinazi**: I I blame you, Lionel Messi. No.

[01:49:23] **Yaroslav Rosomakho**: Okay. It makes a lot of work.

[01:49:25] **David Schinazi**: And we can I I assume you can blame the itchy key workshop for not doing it after

[01:49:31] **Hannes Tschofenig**: the first provider on Tuesday?

[01:49:34] **David Schinazi**: Oh, there was

[01:49:36] **Hannes Tschofenig**: I did not.

[01:49:37] **Martin Thompson**: Tuesday and ten.

[01:49:38] **Hannes Tschofenig**: Oh, sorry.

[01:49:39] **David Schinazi**: What was that email to?

[01:49:43] **Hannes Tschofenig**: It's possible that

[01:49:44] **David Schinazi**: I haven't moved my sometimes when it goes to aliases, like something dash chairs, that I guess filtered into a folder that I don't check very