QUIC
charter-ietf-quic-03

Regarding the sentence:

  The third focus area will describe mappings between specific applications???
  semantics and the transport facilities of QUIC.

I think I am Ok with something like:

  The third focus area will describe mappings between specific application protocols
  and the transport facilities of QUIC.

Or perhaps:

  The third focus area will describe how specific application protocols
  can use the transport facilities of QUIC.

What is the status of these PRs? https://github.com/IETF-QUIC/Charter/pulls

Thanks for this. This is important work, and clearly needs to go ahead. I found the charter well written.

Editorial:

There was an odd character somewhere between "applications" and "semantics" below.
Shows up as ??? for me in the data tracker.

> The third focus area will describe mappings between specific applications???
> semantics and the transport facilities of QUIC. The first mapping will be a

Thanks for the addition of the specific manageability considerations. I think that they make the charter stronger and provide a framewaork for the necessary discussion.  really supportive of the current form.

Was

While I don't think this is by any means fatal I, thing it's unfortunate that the third and fourth areas address transport considerations but not really the managability of flows. e.g. interactions with flow based sampling and reporting, firewall/load-balancer l4 interaction (on the state side) and so on as an area of consideration.

I think this is ready for external review. Discussing operational and mangament aspects in the wg groups is important. However, I don't have a strong opinion if this needs to be mentioned in the charter or not, as long as there is nothing in the charter that prohibits this discussion in the wg.

I agree that this is useful and important work and should go ahead. 
I'm fine that my questions are answered as chartering proceeds,
i.e. please don't hold up external evaluation to answer these.

1) I think it'd be good to set a target of having QUIC be as close
as possible to TLS1.3 for application data protection. While it
may not be possible for them to be identical, the closer they
are the more we can leverage the analysis work for TLS1.3. If
that is a good goal, then maybe mentioning it in the 
charter would also be good.

2) I think it'd be good to have a deliverable that helps people
know when and how to use QUIC. I'd be particularly keen that
that covers when it is/is-not safe to use 0RTT data, as I think
that might be a pitfall for some protocols that use QUIC and
helping folks avoid that pitfall would be good. I'm not sure
if there'd be energy for that though, but if there were, I 
think such a document could be quite useful.