QUIC
charter-ietf-quic-04

[Ballot comment]
Paragraph 3
>    * Maintenance and evolution of the QUIC base specifications that
>      describe its invariants, core transport mechanisms, security and
>      privacy properties, loss detection and recovery, congestion control,
>      version and extension negotiation, etc. This includes the
>      specification of new versions of QUIC.
>
>    * Maintenance and evolution of the existing QUIC extensions
>      specified by the WG.

This area of work seems to conflate maintenance and specification of a new version of QUIC, when they are two different tasks with their own set of milestones. Ideally, they should be broken out as two separate areas of work.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 5
> ations that have adopted QUIC as a transport. 2. The second area of work is
>                                  ^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"transport".

"QUIC", paragraph 1
> ion control schemes may fall under the the third area of work. The QUIC WG o
>                                    ^^^^^^^
Possible typo: you repeated a word.

[Ballot comment]
Paragraph 3
>    * Maintenance and evolution of the QUIC base specifications that
>      describe its invariants, core transport mechanisms, security and
>      privacy properties, loss detection and recovery, congestion control,
>      version and extension negotiation, etc. This includes the
>      specification of new versions of QUIC.
>
>    * Maintenance and evolution of the existing QUIC extensions
>      specified by the WG.

This area of work seems to conflate maintenance and evolution, when they are two different tasks with their own set of milestones. Ideally, they should be broken out as two separate areas of work.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 5
> ations that have adopted QUIC as a transport. 2. The second area of work is
>                                  ^^^^^^^^^^^
Uncountable nouns are usually not used with an indefinite article. Use simply
"transport".

"QUIC", paragraph 1
> ion control schemes may fall under the the third area of work. The QUIC WG o
>                                    ^^^^^^^
Possible typo: you repeated a word.

[Ballot comment]
Would it possibly to state the intended publication status for `The WG may also publish specifications to publicly document deployed proprietary extensions` ? I think that it is vastly different to document in an informational I-D (like ISE stream) proprietary extensions as opposed to a proposed standard for the same proprietary extensions. I hope that this is the former, but let's be specific in the charter.

[Ballot comment]
Would it possibly to state the intended publication status for `The WG may also publish specifications to publicly document deployed proprietary extensions` ? I think that it is vastly different to document in an informational I-D (like ISE stream) a proprietary extension as opposed to a proposed standard for the same proprietary extensions. I hope that this is the former, but let's be specific in the charter.

[Ballot comment]
While I think it is good to have a QUIC WG as focus point, through the charter text I don't see any actual planned work other than being ready for work if it would come to pass. Is there anything being worked on right now?

[Ballot comment]
I remain slightly skeptical that this new item belongs in the QUIC WG itself, but the right people are there and I'm not the RAD, so I won't object.

Considering that the QUIC WG has shipped both QUICv1 and QUICv2, it might be worth generalizing the first line.

[Ballot comment]
Hi all,

I used [1] to review the charter changes. Please find below some comments:

# Any plan to update the deployment considerations?

As I see item#2 touched as well, I have the following questions:

## I wonder whether the WG has considered to do a refresh of RFC 9312 to reflect more deployment experience.

## The load-balancer item was promised to be sent to the IESG back to 2021. Are there specific issues with this spec? I see the doc is still active, wonder whether there is a target publication date for this one?

## Given the various foo-over-QUIC out there, developing some guidance for the authors of such documents would be helpful. Not sure if that was considered by the WG.

# Consider adding a milestone for the new Item#4, in particular.

# nits

## HTTP WG was concluded; consider updating to httpbis

CURRENT:
  The QUIC WG originated HTTP/3, the mapping of HTTP to QUIC, and the
  QPACK header compression scheme. These specifications are now
  maintained in the HTTP WG.

## Better flow

I would move this text to be under item#3, with some minor edits:

OLD:
  Defining new congestion control schemes is explicitly out of scope for
  the WG. However, new QUIC extensions that support development and
  experimentation with new congestion control schemes may fall under the
  third work area.

NEW:
  Defining new congestion control schemes is explicitly out of scope for
  the WG. However, new QUIC extensions that support development and
  experimentation with new congestion control schemes is within scope.

Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-03.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-quic%2Fwithmilestones-03-02.txt&difftype=--hwdiff

[Ballot comment]
With the added words about ‘informational’ for the work item 2 in -03, the charter is now more defined and less vague about the intended status of the documents. We know that a charter is a contract between the WG and the IETF community, i.e., everything must be detailed even in fine print. Thanks for this change.

I will update my ballot into NoObj *but* think as well to add “ps” status when the charter is about “specifications” to be 100% accurate.

[Ballot block]
Let's be clear and accurate in defining the intended status of the work items. E.g., I guess that items 1, 3, 4 will produce documents with an intended status of proposed standards while item 2 will be about informational.

Easy to write in the text :-)

[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.