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 |