Ballot for charter-ietf-quic
Yes
No Objection
Note: This ballot was opened for revision 02-01 and is now closed.
Ballot question: "Is this charter ready for external review?"
* Maintenance and evolution of the QUIC base specifications that describe its invariants, core transport mechanisms, security and privacy, loss detection and recovery, congestion control, version and extension negotiation, etc. This includes the specification of new versions of QUIC. nit: the list structure is not parallel -- "security and privacy" are abstract/generic concepts but the rest of the list are properties of the QUIC base specification. I think adding "properties" would help. WG adoption of work items falling into this first area of work needs to be strongly motivated by existing or ongoing production deployments of QUIC at scale, and needs to carefully consider its impact on the diverse set of applications that have adopted QUIC as a transport. While I expect a diverse set of such applications in the near future, I'm not entirely sure how accurate the statement is right now. The WG produced HTTP/3, of course, but in terms of items adopted by IETF WGs I see only DNS and MASQUE; there are many other individual drafts but I don't know if that qualifies for "applications that have adopted" QUIC. Specifications describing how new or existing application protocols use the QUIC transport layer need not be specified in the QUIC WG, although they can. The QUIC WG will collaborate with other groups that define such application protocols that intend to use QUIC. New mappings might require QUIC extensions and it may be efficient to define these alongside the mapping specifications. nit: this seems to be the first time we talk about (application protocol) "mappings" (onto QUIC), so a couple more words of introduction might be in order.