19:00-21:00 (UTC)
See this time in your local timezone
Github usage and draft status
Lots of closed issues, but no PRs. Please use PRs to track changes in response to issues.
David: This is me, sorry. I'll be better.
Mirja: Please use PRs so we can see what the change was. Don't close issues until we have agreement. Also, please raise design issues to the mailing list as well.
Mike: Disagree about keeping issues open after PRs merged, but maybe have a changelog so there's visibility?
Chris: Up to the editors, but close issues when the editors think they're addressed.
Mark: Don't spend too much time on process; chairs should decide and make sure to document so we're all on the same page.
Alex: Tried to include reference to the issue in the commit that referenced it. Do we need people besides the editors approving before they merge?
Mirja: Discussion on the issue, ideally including the issue opener.
Eric: Let's move on. We'll add guidelines to the repo.
Mirja: Please add additional editors in this case.
Lucas added as co-author
Datagram-Flow-Id header moved into (renamed) draft-schinazi-masque-h3-datagram draft; adopt it?
Martin Duke: Is datagram an HTTP/3 frame or a QUIC frame?
Lucas: QUIC frame, but draft defines interpretation within HTTP/3.
Martin Thomson: How does the name not conflict with other extensibility?
David Schinazi: Names allow assigning flow IDs to different extensions; registry in doc.
Martin: That's even worse. Will open an issue.
David: Able to interpret this even if you don't know the extension using it.
Martin: What about a parameter called "name"?
Mark: +1, this is pretty byzantine
David, Lucas: Sure.
Ben: Uniqueness doesn't seem required either.
David: Current extensions don't need more than one ID, but we could remove the requirement.
Ekr: Some repeatable and some not is hard to validate. Pick one.
Tommy Pauly: Repeatability issue goes away if we have parameters instead.
Lucas: Want to be able to have parameters for extensions, but there are lots of possibilities.
Mirja: Proposal assumes an extensibility design; let's figure out extensibility first.
Ben: Type-safe-looking parameters is potentially a layering issue.
David: Registry seems to address this today.
Ben: That puts totally different things having to register together.
David: That's why we have registries, right?
Ekr: We have 2^62 flow IDs; why do we need reuse?
David: File an issue if there's not already one.
MT: CONNECT-UDP currently requires declaring flow IDs up-front. Can we use frames for that instead?
Lucas: Similar concept to Tommy's QUIC-Aware Proxying, fixing up the headers subsequently
MT: Many ways to spell this. Doesn't block adoption.
Victor: Concerned about the change of venue, and the fact this document keeps growing new features.
Chris: HTTP and QUIC chairs referred it here.
David: It's an individual draft, I've been changing it as I have ideas. If it's adopted, that changes.
Mirja: Would like to see naming changes incorporated before adoption happens.
Poll for ability to use poll: Yes 21/34 No 1/34 Just here for slides 10/34 Poll for adoption: Yes 21/34 No 1/34 No Answer 12/34
Lucas: Assuming adoption happens, migrate the document first and then open issues. David: Put this in its own repo, so we can migrate the repo to the WG and bring issues along.
MT: Intermediary might route flow IDs easily, but many:1 could get messy
David: Don't over-index on intermediaries; they'll probably be uncommon.
MT: It's an HTTP method; we need to work within the HTTP architecture. Why do we need this?
David: Let's wait for Tommy's presentation for justification.
Alex: Also concerned about many:1 based on implementation experience. Breaks horribly in unexpected ways.
Mark: Why is defining a new URI scheme hard? "https" could work, there's precedent, but a separate URI scheme is clearer
David: A separate URI scheme is interesting for configuring proxies, but this is the reference to the endpoint.
Mark: HTTPS could actually work.
EKR: The semantics here aren't wanting to do HTTPS, they're sending UDP packets. "https" doesn't make sense. Was it a mistake to create a new method if the exception can't be extended? Just do CONNECT and define a header that changes semantics. You'll learn in the response if the proxy doesn't support UDP.
Magnus: Whatever we do here, know how we'll handle IP, other protocols, etc. that we might want to proxy in the future.
MT: New URI scheme is a little hard, because we have to understand what it's conveying. This is just a means to an end; getting through HTTPS. It's ugly, but works.
Tommy: "https" is more right than defining a new URI scheme. But why not use the scheme of whatever the client is trying to reach?
Ben: Using "https" requires updating the definition of that scheme. "udp" is better, or maybe "null".
Need to delimit datagrams on-stream when QUIC DATAGRAM not supported. Now uses sequence of TLVs, possible extensibility point.
EKR: Why do we need this alongside the multiple Flow ID stuff?
David: Have to support fallback to stream when DATAGRAM isn't supported. Would like mechanisms to align, but haven't come up with better option.
Magnus:<...>
Tommy: Can we just Use flow IDs as the identifiers of the chunks?
Flow IDs are negotiated per-hop and requires negotiation on each hop.
MT: Is the intermediary required to do anything if it appears on another method?
David: Remove it if the application of Datagram-Flow-ID to the method is not understood by the intermediary.
Not reviewing for time's sake.
Mirja: Why does this need to be part of the core document and not an extension?
Alex: Doesn't make sense -- it would gut this document to remove it.
Mirja: Not sure we have to require this; there are use-cases for not sending
Alex: Sure, that's something else you can add as an extension; this doesn't preclude other modes as extensions.
Mirja: The requirement is still too strong; everything you want can be an extension.
Eric: Move this to the issue.
Magnus: Is this byte-for-byte or simply conveying information?
Alex: Byte-for-byte should be possible, but other modes are possible.
EKR: Since we're encrypting, there will always be transformation. We should be talking about transferring all the information.
Alex: Yes; if the document doesn't say that, submit a PR.
Open:
Want to improve proxy reuse of 4-tuples, avoid double-encapsulation overhead. Inform proxy of client/server CIDs; if proxy approves, directly forward packets with that CID instead of unwrapping. Proxy has to map CIDs to UDP sockets; can reject in case of conflict/overload. Questions to the list.
Two possible design approaches for IP proxying; requirements doc MUST NOT assume either solution.