Skip to main content

Applicability of the QUIC Transport Protocol
draft-ietf-quic-applicability-18

Revision differences

Document history

Date Rev. By Action
2024-01-26
18 Gunter Van de Velde Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review
2024-01-26
18 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-09-21
18 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-08-25
18 (System) RFC Editor state changed to AUTH48
2022-08-18
18 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-07-19
18 (System) IANA Action state changed to No IANA Actions from In Progress
2022-07-15
18 (System) RFC Editor state changed to EDIT
2022-07-15
18 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-07-15
18 (System) Announcement was received by RFC Editor
2022-07-15
18 (System) IANA Action state changed to In Progress
2022-07-15
18 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-07-15
18 Cindy Morgan IESG has approved the document
2022-07-15
18 Cindy Morgan Closed "Approve" ballot
2022-07-15
18 Cindy Morgan Ballot approval text was generated
2022-07-15
18 Zaheduzzaman Sarker IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-07-15
18 Mirja Kühlewind New version available: draft-ietf-quic-applicability-18.txt
2022-07-15
18 Jenny Bui Forced post of submission
2022-07-15
18 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2022-07-15
18 Mirja Kühlewind Uploaded new revision
2022-07-11
17 Mirja Kühlewind New version available: draft-ietf-quic-applicability-17.txt
2022-07-11
17 (System) New version approved
2022-07-11
17 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2022-07-11
17 Mirja Kühlewind Uploaded new revision
2022-04-22
16 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events': Document has finished IESG processing
2022-04-22
16 Barry Leiba Assignment of request for Last Call review by ARTART to Gonzalo Salgueiro was marked no-response
2022-04-21
16 Martin Duke
[Ballot comment]
11.2 “ QUIC requires that endpoints generate fresh connection IDs for use on new network paths.”

This is ambiguously phrased and ignores NAT …
[Ballot comment]
11.2 “ QUIC requires that endpoints generate fresh connection IDs for use on new network paths.”

This is ambiguously phrased and ignores NAT rebinding. I suggest

“If QUIC endpoints do not issue fresh connection IDs, then clients cannot reduce the linkability of address migration by using them.”

11.3. Note that “retry service” has been renamed to “retry offload” and now has its own draft separate from QUIC-LB: draft-duke-quic-retry-offload (soon to be -ietf-)

14. This entire section appears to be a duplicate of section 5 of the version negotiation draft. I suggest the authors verify that the latter has all the relevant information, and then replace this section with a reference to the VN draft.
2022-04-21
16 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2022-04-21
16 (System) Removed all action holders (IESG state changed)
2022-04-21
16 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2022-04-21
16 Cindy Morgan Changed consensus to Yes from Unknown
2022-04-20
16 Paul Wouters
[Ballot comment]
Thanks for writing this document, I believe it is important for application developers to understand if or when they should adopt QUIC versus …
[Ballot comment]
Thanks for writing this document, I believe it is important for application developers to understand if or when they should adopt QUIC versus HTTP over TCP with TLS. (Although after reading the document, I feel for application developers who think they need to support or use QUIC instead of using it via HTTP/3)

Some comments:

  A fallback to TCP and TLS exposes control information to modification
  and manipulation in the network.

This sentence is a bit tricky to read and could use a rewrite. But I'm also not sure of the meaning. I understand that with TCP you can send RST packets to kill it, and with UDP you cannot. But with UDP you can also send equivalent to RST packets. For instance I have observed responses to UDP based IKEv2 packets causing IKEv2 communication to completely fail (where the MITM replies before the real target). Does QUIC really prevent all of this, because that is what the sentence seems to suggest by pointing out specific flaws in the "fallback option" to QUIC.

    Further, downgrades to older TLS versions

I would probably use "Additionally" instead of "Further" here. Or we can compromise on "furthermore" :)

I am not sure if ALPN leakage would qualify as "significantly weaker cryptographic protection". I don't see much multiplexing usin ALPN, so the port number is still kind of a dead giveaway for the application being used anyway.

  Section 3.5 of
  [RFC8085] further discusses keep-alive intervals for UDP: it requires
  a minimum value of 15 seconds, but recommends larger values, or
  omitting keep-alive entirely.

The paragraph is warning about NAT mappings and idleness. It then feels contradicting to see some context apparently recommends not doing keep-alives entirely. Why is this part being brought up here? When would an application with QUIC not use keep-alives?  When no NAT is detected? (Does QUIC have an indication of that to begin with, like IKEv2 does?). But when reading the next paragraph it became clear keep-alives might not be needed if one can depend on the QUIC connection ID. Maybe a better lead into the next paragraph would be better?

Section 7 talks about acknowledgment strategy, but it is not actually giving any examples of what the application can do. Since it is kind of a transport layer property and not an application layer property, it is unclear how an application [developer] can replace the "TCP like ack every other packet" functionality. Are there QUIC options to consider that do this? If so, why not mention those here?

  The assumption that an application can be
  identified in the network based on the port number is less true today
  due to encapsulation, mechanisms for dynamic port assignments, and
  NATs.

NATs don't hide the destination port which traditionally identifies the application, so it feels wrong to add it to this list. It is true more and more applications use port 443 (and HTTPS) but we don't see traditional applications (eg IMAP, SMTP) move to port 443 either. The mechanisms for dynamic port assignments themselves also seem to be on their way out. Is there anything but NFS still using portmap/rpc dynamic ports (is it still using that even, since people hardcoded it to 2049 years ago anyway)

Section 8.1 talks about "Services might block source ports" and then lists a bunch. But contacting a service should really happen from an ephemeral source port, which would be as per RFC 6335 suggestion the range 49152–65535. None of the examples in this section come from these ports, so it feels like if one picks proper ephemeral ports, there is no relevant blocking issue at all that this section talks about. Perhaps that is the advise this section should give?

    In the limit where connection migration in a server pool is rare

In the limit? Is that supposed to be "In the case" ?
2022-04-20
16 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2022-04-20
16 Roman Danyliw
[Ballot comment]
Thank you to Chris Lonvick for the SECDIR review.

Section 2.
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols …
[Ballot comment]
Thank you to Chris Lonvick for the SECDIR review.

Section 2.
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided. 

Consider if fallback needs to be the default behavior of applications. For example:

Specifically, support for fallback to insecure protocols or to weaker versions of the secure protocol needs to be evaluated on a per-application basis.

Section 2.  Typo. s/a application/an application/

Section 3.2.  Typo. s/mobilty/mobility/

Section 14.  Typo. s/negotation/negotiation/
2022-04-20
16 Roman Danyliw Ballot comment text updated for Roman Danyliw
2022-04-20
16 Roman Danyliw
[Ballot comment]
Thank you to Chris Lonvick for the SECDIR review.

Section 2.
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols …
[Ballot comment]
Thank you to Chris Lonvick for the SECDIR review.

Section 2.
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided. 

Consider if fallback needs to be the default behavior of applications. For example:

Specifically, support for fallback to insecure protocols or to weaker version of the secure protocol needs to be evaluated on a per-application basis.

Section 2.  Typo. s/a application/an application/

Section 3.2.  Typo. s/mobilty/mobility/

Section 14.  Typo. s/negotation/negotiation/
2022-04-20
16 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-04-20
16 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.  I think that these sorts of documents are incredibly helpful and important for end users who are considering …
[Ballot comment]
Hi,

Thanks for this document.  I think that these sorts of documents are incredibly helpful and important for end users who are considering how to use IETF technology.

I found the document to be well written, and only had a few minor comments/questions:

1.
    If a QUIC receiver has opened the maximum allowed concurrent streams,
  and the sender indicates that more streams are needed, it does not
  automatically lead to an increase of the maximum number of streams by
  the receiver.  Therefore, an application can use the maximum number
  of allowed, currently open, and currently used streams when
  determining how to map data to streams.

I was wondering whether "can use" is right here, or whether this should be "must use", given that the client cannot necessarily control how many streams are available.


7.  Acknowledgment Efficiency

  QUIC version 1 without extensions uses an acknowledgment strategy
  adopted from TCP Section 13.2 of [QUIC]).
 
Nit: This doesn't quite scan/read easily.


9.  Connection Migration

  QUIC supports connection migration by the client.  If an IP address
  changes, a QUIC endpoint can still associate packets with an existing
 
For clarity, perhaps: If an IP address changes => If the client IP address changes?

Thanks,
Rob
2022-04-20
16 Robert Wilton [Ballot Position Update] New position, Yes, has been recorded for Robert Wilton
2022-04-20
16 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-04-19
16 Erik Kline
[Ballot comment]
# Internet AD comments for {draft-ietf-quic-applicability-16}
CC @ekline

## Nits

### S2

* s/a application/an application/

### S3.2

* s/and to …
[Ballot comment]
# Internet AD comments for {draft-ietf-quic-applicability-16}
CC @ekline

## Nits

### S2

* s/a application/an application/

### S3.2

* s/and to unacceptable/and unacceptable/, I think

### S4

* s/they are assigned Section 6/they are assigned; see Section 6/, perhaps
2022-04-19
16 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2022-04-19
16 Lars Eggert
[Ballot comment]
The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Thanks to Maria Ines Robles for their …
[Ballot comment]
The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Thanks to Maria Ines Robles for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/869_aZXxcQCMeZGDSfN-E1JyjrU).

-------------------------------------------------------------------------------

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.

Section 14, paragraph 1, nit:
-    QUIC version 1 does not specify a version negotation mechanism in the
+    QUIC version 1 does not specify a version negotiation mechanism in the
+                                                  +

Document references draft-ietf-quic-datagram, but that has been published as
RFC9221.

Document references draft-ietf-quic-manageability-15, but -16 is the latest
available revision.

Reference [RFC5077] to RFC5077, which was obsoleted by RFC8446 (this may be on
purpose).

Paragraph 1938, nit:
> ols needs to be avoided. In general, a application that implements fallback
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Paragraph 2371, nit:
> lishment is qualitatively different than one that does not from the point of
>                                    ^^^^
Did you mean "different from"? "Different than" is often considered colloquial
style.

Paragraph 5804, nit:
>  opened and closed they are consumed and the cumulative total is incremented
>                                    ^^^^
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

Paragraph 5822, nit:
> increased using the MAX_STREAMS frame but there is no mechanism to reduce lim
>                                      ^^^^
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

Paragraph 6727, nit:
> e an error code space that is independent from QUIC or other applications (s
>                              ^^^^^^^^^^^^^^^^
The usual collocation for "independent" is "of", not "from". Did you mean
"independent of"?

Paragraph 10802, nit:
> nd using QUIC. Further, migration to an new address exposes a linkage between
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".
2022-04-19
16 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-04-19
16 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. Such a document is important for developers / operators wanting to use the new …
[Ballot comment]
Thank you for the work put into this document. Such a document is important for developers / operators wanting to use the new transport.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Matt Joras for the shepherd's write-up including the WG consensus and the intended status.

I hope that this helps to improve the document,

Regards,

-éric

Should there be a section about temporary address extension for IPv6 addresses RFC 8981 (as some OS can be very aggressive in changing to the next IPv6 address) ? Or is it 'just' a case of NAT rebinding ? If the latter, then one sentence in the introduction could be useful.

What is the recommendation for these addresses, should the application keep always the first address as long as it is valid ? or should it switch to a new one ?

## Section 2

"permits traversal of network middleboxes (including NAT)" could perhaps be refined as TCP also traverse NAT, perhaps something such as "using a new IP protocol would have issue with network middleboxes (Internet ossification)" ?

## Section 4.4 (and some others)

Sometimes the text is a little unclear on which part of the "application using QUIC" is discussed: the transport layer or the application layer in the "application" ? Unsure whether it is only me having this confusion though and I have no real suggestion on how to clarify things.

## Section 5

For the last paragraph, should a reference to a TAPS API/parameter be given ? (if it exists of course)
2022-04-19
16 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-04-12
16 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2022-04-12
16 Cindy Morgan Placed on agenda for telechat - 2022-04-21
2022-04-11
16 Zaheduzzaman Sarker Ballot has been issued
2022-04-11
16 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2022-04-11
16 Zaheduzzaman Sarker Created "Approve" ballot
2022-04-11
16 Zaheduzzaman Sarker IESG state changed to IESG Evaluation from Waiting for Writeup
2022-04-11
16 Zaheduzzaman Sarker Ballot writeup was changed
2022-04-06
16 Brian Trammell New version available: draft-ietf-quic-applicability-16.txt
2022-04-06
16 (System) New version approved
2022-04-06
16 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2022-04-06
16 Brian Trammell Uploaded new revision
2022-03-07
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2022-03-07
15 Brian Trammell New version available: draft-ietf-quic-applicability-15.txt
2022-03-07
15 (System) New version approved
2022-03-07
15 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2022-03-07
15 Brian Trammell Uploaded new revision
2022-02-12
14 Chris Lonvick Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list.
2022-02-07
14 Ines Robles Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Ines Robles. Sent review to list.
2022-02-07
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-02-04
14 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2022-02-04
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-quic-applicability-14, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-quic-applicability-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2022-01-28
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2022-01-28
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Chris Lonvick
2022-01-28
14 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2022-01-28
14 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2022-01-28
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2022-01-28
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2022-01-25
14 Barry Leiba Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro
2022-01-25
14 Barry Leiba Request for Last Call review by ARTART is assigned to Gonzalo Salgueiro
2022-01-24
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-01-24
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-02-07):

From: The IESG
To: IETF-Announce
CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-quic-applicability@ietf.org, matt.joras@gmail.com, quic-chairs@ietf.org, quic@ietf.org …
The following Last Call announcement was sent out (ends 2022-02-07):

From: The IESG
To: IETF-Announce
CC: Zaheduzzaman.Sarker@ericsson.com, draft-ietf-quic-applicability@ietf.org, matt.joras@gmail.com, quic-chairs@ietf.org, quic@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability of the QUIC Transport Protocol) to Informational RFC


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'Applicability of the QUIC Transport Protocol'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-02-07. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document discusses the applicability of the QUIC transport
  protocol, focusing on caveats impacting application protocol
  development and deployment over QUIC.  Its intended audience is
  designers of application protocol mappings to QUIC, and implementors
  of these application protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/



No IPR declarations have been submitted directly on this I-D.




2022-01-24
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-01-24
14 Zaheduzzaman Sarker Last call was requested
2022-01-24
14 Zaheduzzaman Sarker Last call announcement was generated
2022-01-24
14 Zaheduzzaman Sarker Ballot approval text was generated
2022-01-24
14 Zaheduzzaman Sarker Ballot writeup was generated
2022-01-24
14 Zaheduzzaman Sarker IESG state changed to Last Call Requested from AD Evaluation
2022-01-21
14 Brian Trammell New version available: draft-ietf-quic-applicability-14.txt
2022-01-21
14 (System) New version approved
2022-01-21
14 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2022-01-21
14 Brian Trammell Uploaded new revision
2021-11-24
13 (System) Changed action holders to Zaheduzzaman Sarker (IESG state changed)
2021-11-24
13 Zaheduzzaman Sarker IESG state changed to AD Evaluation from Publication Requested
2021-10-06
13 Matt Joras
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document discusses applicability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  Its intended audience is those interested in understanding and developing new applications which use QUIC as their underlying transport protocol.

Working Group Summary:

This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes and non-HTTP applications running over QUIC.

Document Quality:

This document is informational and meant for application developers and deployers. There has been extensive feedback on the contents from implementers, QUIC deployments, and researchers. We believe it to be high quality information about QUIC for application developers.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Matt Joras is the document shepherd, Zahed Sarker the AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
I don't believe so.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
There are no IPR disclosures require for this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has received a wide diversity of review from implementers, deployers of QUIC, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
4 non-ascii characters, outdated references to documents now published as RFCs.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A
2021-10-06
13 Matt Joras Responsible AD changed to Zaheduzzaman Sarker
2021-10-06
13 Matt Joras IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2021-10-06
13 Matt Joras IESG state changed to Publication Requested from I-D Exists
2021-10-06
13 Matt Joras IESG process started in state Publication Requested
2021-10-06
13 Matt Joras Tag Doc Shepherd Follow-up Underway cleared.
2021-10-04
13 Lucas Pardue
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Informational. This is the proper type as this document is not a standard and is quite literally informational we'd like the Internet community to know about.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document discusses applicability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic.  Its intended audience is those interested in understanding and developing new applications which use QUIC as their underlying transport protocol.

Working Group Summary:

This document has been reviewed and contributed to by many participants in the QUIC WG, including those from companies with major QUIC deployments and operators of networks with significant QUIC traffic volumes and non-HTTP applications running over QUIC.

Document Quality:

This document is informational and meant for application developers and deployers. There has been extensive feedback on the contents from implementers, QUIC deployments, and researchers. We believe it to be high quality information about QUIC for application developers.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?
Matt Joras is the document shepherd, Zahed Sarker the AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
I have reviewed the document several times both as an indivudal in the WG and now as a shepherd in its current form. I believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No, it has gone through several reviews and we have a wide diversity of perspectives in the feedback so far.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
I don't believe so.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
No specific concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
There are no IPR disclosures require for this document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
It has received a wide diversity of review from implementers, deployers of QUIC, and researchers. There have been two WGLCs, where feedback from the first was integrated, thus the consensus is good though the engagement has overall been less than the original QUIC documents.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
4 non-ascii characters, outdated references to documents now published as RFCs.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

(13) Have all references within this document been identified as either normative or informative?
Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?
No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.
No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).
N/A.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.
N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?
N/A
2021-09-02
13 Brian Trammell New version available: draft-ietf-quic-applicability-13.txt
2021-09-02
13 (System) New version approved
2021-09-02
13 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2021-09-02
13 Brian Trammell Uploaded new revision
2021-07-07
12 Matt Joras Tag Doc Shepherd Follow-up Underway set.
2021-07-07
12 Matt Joras IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-07-07
12 Matt Joras Notification list changed to matt.joras@gmail.com because the document shepherd was set
2021-07-07
12 Matt Joras Document shepherd changed to Matt Joras
2021-06-30
12 Brian Trammell New version available: draft-ietf-quic-applicability-12.txt
2021-06-30
12 (System) New version approved
2021-06-30
12 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2021-06-30
12 Brian Trammell Uploaded new revision
2021-04-21
11 Brian Trammell New version available: draft-ietf-quic-applicability-11.txt
2021-04-21
11 (System) New version approved
2021-04-21
11 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2021-04-21
11 Brian Trammell Uploaded new revision
2021-02-22
10 Mirja Kühlewind New version available: draft-ietf-quic-applicability-10.txt
2021-02-22
10 (System) New version approved
2021-02-22
10 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2021-02-22
10 Mirja Kühlewind Uploaded new revision
2021-02-04
09 Matt Joras IETF WG state changed to In WG Last Call from WG Document
2021-01-22
09 Brian Trammell New version available: draft-ietf-quic-applicability-09.txt
2021-01-22
09 (System) New version approved
2021-01-22
09 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2021-01-22
09 Brian Trammell Uploaded new revision
2021-01-22
09 Brian Trammell Uploaded new revision
2020-11-02
08 Brian Trammell New version available: draft-ietf-quic-applicability-08.txt
2020-11-02
08 (System) New version approved
2020-11-02
08 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2020-11-02
08 Brian Trammell Uploaded new revision
2020-11-02
08 Brian Trammell Uploaded new revision
2020-07-08
07 Brian Trammell New version available: draft-ietf-quic-applicability-07.txt
2020-07-08
07 (System) New version approved
2020-07-08
07 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2020-07-08
07 Brian Trammell Uploaded new revision
2020-07-08
07 Brian Trammell Uploaded new revision
2020-01-06
06 Brian Trammell New version available: draft-ietf-quic-applicability-06.txt
2020-01-06
06 (System) New version approved
2020-01-06
06 (System) Request for posting confirmation emailed to previous authors: Brian Trammell , Mirja Kuehlewind
2020-01-06
06 Brian Trammell Uploaded new revision
2020-01-06
06 Brian Trammell Uploaded new revision
2020-01-06
05 (System) Document has expired
2019-07-05
05 Brian Trammell New version available: draft-ietf-quic-applicability-05.txt
2019-07-05
05 (System) New version approved
2019-07-05
05 (System) Request for posting confirmation emailed to previous authors: Mirja Kuehlewind , Brian Trammell , quic-chairs@ietf.org
2019-07-05
05 Brian Trammell Uploaded new revision
2019-07-05
05 Brian Trammell Uploaded new revision
2019-04-24
04 Brian Trammell New version available: draft-ietf-quic-applicability-04.txt
2019-04-24
04 (System) New version approved
2019-04-24
04 (System) Request for posting confirmation emailed to previous authors: Mirja Kuehlewind , Brian Trammell
2019-04-24
04 Brian Trammell Uploaded new revision
2019-04-24
04 Brian Trammell Uploaded new revision
2018-10-22
03 Brian Trammell New version available: draft-ietf-quic-applicability-03.txt
2018-10-22
03 (System) New version approved
2018-10-22
03 (System) Request for posting confirmation emailed to previous authors: Mirja Kuehlewind , Brian Trammell
2018-10-22
03 Brian Trammell Uploaded new revision
2018-07-02
02 Mirja Kühlewind New version available: draft-ietf-quic-applicability-02.txt
2018-07-02
02 (System) New version approved
2018-07-02
02 (System) Request for posting confirmation emailed to previous authors: Mirja Kuehlewind , Brian Trammell
2018-07-02
02 Mirja Kühlewind Uploaded new revision
2018-04-28
01 (System) Document has expired
2018-02-13
01 Lars Eggert Intended Status changed to Informational from None
2017-10-25
01 Mirja Kühlewind New version available: draft-ietf-quic-applicability-01.txt
2017-10-25
01 (System) New version approved
2017-10-25
01 (System) Request for posting confirmation emailed to previous authors: Mirja Kuehlewind , Brian Trammell
2017-10-25
01 Mirja Kühlewind Uploaded new revision
2017-07-03
00 Lars Eggert This document now replaces draft-kuehlewind-quic-applicability instead of None
2017-07-03
00 Brian Trammell New version available: draft-ietf-quic-applicability-00.txt
2017-07-03
00 (System) WG -00 approved
2017-07-03
00 Brian Trammell Set submitter to "Brian Trammell ", replaces to (none) and sent approval email to group chairs: quic-chairs@ietf.org
2017-07-03
00 Brian Trammell Uploaded new revision