QUIC
charter-ietf-quic-03

[Ballot comment]
Paragraph 5, comment:
>      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
>      applications and higher-layer protocols (simply called as "application
>      protocols" in the rest of this charter) that have adopted QUIC as a
>      transport.

This paragraph should be "outdented", i.e., shifted one level to the left, since
it applies to everything under (1) and not just the second bullet item. (See the
indentation on
https://github.com/quicwg/wg-materials/blob/main/charter/charter.md but please
note that that doesn't have the most recent text changes yet.)

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Paragraph 6, nit:
-      applications and higher-layer protocols (simply called as "application
                                                              ---
+      applications and higher-layer protocols (simply called "application

[Ballot comment]
      * 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.

This is a proposal for a new QUIC WG charter to enable QUIC WG to continue evolve and maintain the QUIC protocol. It is a significant change from the previous veyr targeted charter to somewhat more open charter that allows the WG to adopt work that has sufficient interest without additional recharters.

Initiating recharter targeted to continued operation after first set of core specifications have started. This is also driven to enable some extensions as well as starting work on QLOG.

[Ballot comment]
I agree with Adam.

The "Note that consensus is required both for changes to the current protocol
mechanisms and retention of current mechanisms. In particular, because
something is in the initial document set does not imply that there is consensus
around the feature or around how it is specified" might be stale at this point.

[Ballot comment]
I note that the paragraph that previously ruled partial reliability and FEC out of scope has been removed. Are these mechanisms to be considered in-scope in this new version of the charter? I would suggest that it should say so explicitly, if such is the intention.

Initial proposal for a recharter version of the QUIC WG to support extension work related to version negotiation, load balancers and datagram. Some additional clean ups have also been performed.

[Ballot comment]
"The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, in line with RFC 7258."

The way this is phrased makes it sound like RFC 7258 is about protocol impact on network management, which isn't the case. I would suggest dropping "in line with RFC 7258." Alternatively, you could say something like:

"The QUIC
protocol need not be defined to enable each of these abilities, or
enable them in the same way as they are enabled by TCP when used
with TLS 1.3, but the working group must consider the impact of the
protocol on network management practices, reflecting the tensions described in RFC 7258."

[Ballot comment]
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.

[Ballot comment]
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.

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.

[Ballot comment]
Thanks for addressing my block.

Two minor points.
1. I thought that the "QUIC Applicability Statement" deliverable was called "QUIC Applicability and Manageability Statement" in a previous charter. That would be more appropriate.
2. "The working group will consider deployment and manageability considerations for the protocol." Will consider ... considerations. I could leave with it, but will consider ... implications might be better

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot block]
Disclaimer: I come late to the game (back from vacation) and I haven't had the chance to review QUIC as much as I wanted/needed.

What about the operational aspects (as Joel mentioned in his COMMENT)?
I would like to DISCUSS this point during the telechat.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.