Re: [C430] AUTH48 [LB]: RFC 9000 <draft-ietf-quic-transport-34.txt> NOW AVAILABLE

[[e-mail]]

Authors,

While reviewing this document during AUTH48, please resolve 
(as necessary) the following questions, which are also in the 
XML file.

1) <!-- [rfced] Please insert any keywords (beyond those that appear 
in the title) for use on https://www.rfc-editor.org/search -->


2) <!-- [rfced] Section 1:  RFC 9002 <draft-ietf-quic-recovery> 
discusses several algorithms. Will readers readily know which 
algorithm this sentence refers to?

Original:
 An exemplary
 congestion control algorithm is also described in [QUIC-RECOVERY]. -->


3) <!-- [rfced] Section 1.2:  Because <https://goo.gl/dMVtFi> appeared
to identify "QUIC" as an acronym ("Quick UDP Internet Connections"),
should this sentence be rephrased?

Original:
 QUIC:  The transport protocol described by this document.  QUIC is a
    name, not an acronym.

Possibly:
 QUIC:  The transport protocol described by this document.  QUIC is
    normally considered a name and not an acronym. -->


4) <!-- [rfced] Sections 2.1 and subsequent:  Would you like to use
superscripts for the "2^" values (e.g., 2^62-1)?  Examples of
superscripting can be seen in
<https://www.rfc-editor.org/rfc/rfc8966.pdf> and
<https://www.rfc-editor.org/rfc/rfc8966.html>; search for instances
of "modulo 2".  Please note that the superscripting will only appear
in the .pdf and .html files. -->


5) <!-- [rfced] Section 4.1:  "FLOW_CONTROL_ERROR" is not mentioned
again until Section 17.2.3.  Please confirm that this citation is
correct and will be clear to readers.

We have the same question regarding "FINAL_SIZE_ERROR error; see
Section 11" and "STREAM_LIMIT_ERROR (Section 11)".

If the intent is to point to error handling, would it help to
rephrase these sentences?

Original:
 A receiver MUST close the connection with a FLOW_CONTROL_ERROR error
 (Section 11) if the sender violates the advertised connection or
 stream data limits.
...
 If a
 RESET_STREAM or STREAM frame is received indicating a change in the
 final size for the stream, an endpoint SHOULD respond with a
 FINAL_SIZE_ERROR error; see Section 11.
...
 An endpoint
 that receives a frame with a stream ID exceeding the limit it has
 sent MUST treat this as a connection error of type STREAM_LIMIT_ERROR
 (Section 11).

Possibly:
 A receiver MUST close the connection with an error of type
 FLOW_CONTROL_ERROR if the sender violates the advertised
 connection or stream data limits; see Section 11 for details
 on error handling.
...
 If a
 RESET_STREAM or STREAM frame is received indicating a change in the
 final size for the stream, an endpoint SHOULD respond with an error
 of type FINAL_SIZE_ERROR; see Section 11 for details on error
 handling.
...
 An endpoint
 that receives a frame with a stream ID exceeding the limit it has
 sent MUST treat this as a connection error of type
 STREAM_LIMIT_ERROR; see Section 11 for details on error handling. -->


6) <!-- [rfced] Section 4.6:  We see that "<tt>" was used for two other
inline equations.  Would you like to apply "<tt>" to this equation as
well?

Also, please confirm that "max_stream" should not be "max_streams" as
used in the next paragraph and that "initial_stream_id_for_type"
should not be "initial_max_stream_id" as originally listed in the
Change Log (Appendix B.25).

Original:
 Only streams with a stream ID less than (max_stream * 4 +
 initial_stream_id_for_type) can be opened; see Table 1. -->


7) <!-- [rfced] Section 5.1.2:  Should "active_connection_id limit" be
"active_connection_id_limit" or "active connection ID limit" here?
We ask because this is the only instance of
"active_connection_id limit" that we see in this document.

Original:
 An endpoint SHOULD allow
 for sending and tracking a number of RETIRE_CONNECTION_ID frames of
 at least twice the active_connection_id limit. -->


8) <!-- [rfced] Section 5.2.1:  We had trouble parsing this sentence.
If the suggested text is not correct, please clarify.

Original:
 Packets that do not match an existing
 connection, based on Destination Connection ID or, if this value is
 zero-length, local IP address and port, are discarded.

Suggested:
 Packets that do not match an existing
 connection - based on Destination Connection ID or, if this value is
 zero length, local IP address and port - are discarded. -->


9) <!-- [rfced] Section 7.3: We could not see how "S1" (as opposed to "C1")
relates to the server side in Figures 7 and 8. Please confirm that the 
"S1"s are correct.  
 
Original:  
When the handshake does not include a Retry (Figure 7), the server  
sets original_destination_connection_id to "S1" and  
initial_source_connection_id to "S3". In this case, the server does  
not include a retry_source_connection_id transport parameter.  
 
When the handshake includes a Retry (Figure 8), the server sets  
original_destination_connection_id to "S1",  
retry_source_connection_id to "S2", and initial_source_connection_id  
to "S3". --> 


10) <!-- [rfced] Section 7.4.1:  Should "value" be "values" in this
sentence, or should "apply them" be "apply it"?

Original:
 To
 enable 0-RTT, endpoints store the value of the server transport
 parameters from a connection and apply them to any 0-RTT packets that
 are sent in subsequent connections to that peer that use a session
 ticket issued on that connection. -->


11) <!-- [rfced] Section 7.4.1:  Should "default value is" be "default
values are" in this sentence?  We ask because of this note in the
original Change Log:
 *  Transport parameters for 0-RTT are either remembered from before,
    or assume default values (#126)

Original:
 The client
 MUST use the server's new values in the handshake instead; if the
 server does not provide new values, the default value is used.

Perhaps:
 The client
 MUST use the server's new values in the handshake instead; if the
 server does not provide new values, the default values are used. -->


12) <!-- [rfced] Section 9.5:  RFC 4941 has been obsoleted by RFC 8981
("Temporary Address Extensions for Stateless Address
Autoconfiguration in IPv6").  Because this citation appears to be
general in nature, may we cite and list RFC 8981 instead?

Original:
 A client might wish to reduce linkability by switching to a new
 connection ID, source UDP port, or IP address (see [RFC4941]) when
 sending traffic after a period of inactivity.
...
 [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
            Extensions for Stateless Address Autoconfiguration in
            IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
            <https://www.rfc-editor.org/info/rfc4941>.

Possibly:
 A client might wish to reduce linkability by switching to a new
 connection ID, source UDP port, or IP address (see [RFC8981]) when
 sending traffic after a period of inactivity.
...
 [RFC8981]  Gont, F., Krishnan, S., Narten, T., and R. Draves,
            "Temporary Address Extensions for Stateless Address
            Autoconfiguration in IPv6", RFC 8981,
            DOI 10.17487/RFC8981, February 2021,
            <https://www.rfc-editor.org/info/rfc8981>. -->


13) <!-- [rfced] Section 10.2.1:  We found "for each packet in
Section 12.3" difficult to follow.  We updated as noted below.
Please let us know if this is incorrect.

Original:
 Note:  Allowing retransmission of a closing packet is an exception to
    the requirement that a new packet number be used for each packet
    in Section 12.3.

Currently:
   Note: Allowing retransmission of a closing packet is an
   exception to the requirement that a new packet number be used
   for each packet; see Section 12.3. -->


14) <!-- [rfced] Table 3:  Would you like to remove the spaces around the
dashes for the ranges, as was done in Table 4?

Original:
 0x02 - 0x03
...
 0x08 - 0x0f

etc.

Possibly:
 0x02-0x03
...
 0x08-0x0f

etc. -->


15) <!-- [rfced] Section 13.3:  Are some words missing from this
sentence?  If the suggested text is not correct, please clarify
"not sent again when packet loss is detected, but as described in
Section 10".

Original:
 *  Connection close signals, including packets that contain
    CONNECTION_CLOSE frames, are not sent again when packet loss is
    detected, but as described in Section 10.

Suggested:
 *  Connection close signals, including packets that contain
    CONNECTION_CLOSE frames, are not sent again when packet loss is
    detected; see Section 10. -->


16) <!-- [rfced] Section 13.3:  This sentence has a subject-verb
agreement issue.  Should "if packets containing" be "if the packet
containing", or should "is lost" be "are lost"?

Original:
 New
 frames are sent if packets containing the most recent frame for a
 scope is lost, but only while the endpoint is blocked on the
 corresponding limit. -->


17) <!-- [rfced] Section 13.4:  For ease of the reader, we expanded "ECT"
as "ECN-Capable Transport".  Please let us know if this is incorrect.

(Also, we removed the expansion of "ECN" here, because "ECN" was just
used two and four pages earlier (Pages 94 and 96 of the original
approved document; this sentence is on the original Page 98).)

Original:
 ECN allows an
 endpoint to set an ECT codepoint in the ECN field of an IP packet.

Currently:
 ECN allows an
 endpoint to set an ECN-Capable Transport (ECT) codepoint in the ECN
 field of an IP packet. -->


18) <!-- [rfced] Section 14.2.1:  We see packet/data injection discussed
in Section 5.1 of [RFC8085] but not in Section 5.2 of [RFC8085].
Please confirm that this citation is correct and will be clear to
readers.

Original:
 QUIC endpoints using PMTUD SHOULD validate ICMP messages to protect
 from packet injection as specified in [RFC8201] and Section 5.2 of
 [RFC8085]. -->


19) <!-- [rfced] Section 14.4:  [DPLPMTUD] does not have a Bullet 7 in
the bullet list in its Section 3, but the numbered list that precedes
it has an item numbered "7".  Should this sentence refer to "Item 7
in Section 3 of [DPLPMTUD]" (if referring to the seventh item in the
numbered list), "Bullet 6 in Section 3 of [DPLPMTUD]" (where Bullet 6
is the "When to probe" bullet at the end of Section 3 of [DPLPMTUD]),
or something else?

Original:
 Loss of
 a QUIC packet that is carried in a PMTU probe is therefore not a
 reliable indication of congestion and SHOULD NOT trigger a congestion
 control reaction; see Section 3, Bullet 7 of [DPLPMTUD]. -->


20) <!-- [rfced] Section 15:  The "That is, ..." sentence is a fragment.
We updated accordingly.  If this update is incorrect, please let us
know what "That is," refers to.

Original:
 Versions that follow the pattern 0x?a?a?a?a are reserved for use in
 forcing version negotiation to be exercised.  That is, any version
 number where the low four bits of all bytes is 1010 (in binary).

Currently:
 Versions that follow the pattern 0x?a?a?a?a are reserved for use in
 forcing version negotiation to be exercised - that is, any version
 number where the low four bits of all bytes is 1010 (in binary). -->


21) <!-- [rfced] Table 4: Will "2Bit" be clear to readers?  
 
Original:  
| 2Bit | Length | Usable Bits | Range | -->  


22) <!-- [rfced] Sections 16 and 17.1:  Appendices A.1 and A.2 appear to
only show one example each.  We updated these sentences accordingly.
If these updates are incorrect, please let us know how the text can
be updated for clarity.

Original:
 Examples and a sample decoding algorithm are shown in Appendix A.1.
...
 Pseudocode
 and examples for packet number encoding can be found in Appendix A.2.

Currently:
 An example of a decoding algorithm is shown in Appendix A.1.
...
 Pseudocode
 and an example for packet number encoding can be found in
 Appendix A.2. -->


23) <!-- [rfced] The first sentence seems to conflict with the last sentence, i.e., remove packet protection before recovering the full packet number, but you have to recover the full packet number in order to remove packet protection.  Please review and let us know if this is correct. 

Original:
   At a receiver, protection of the packet number is removed prior to
   recovering the full packet number.  The full packet number is then
   reconstructed based on the number of significant bits present, the
   value of those bits, and the largest packet number received in a
   successfully authenticated packet.  Recovering the full packet number
   is necessary to successfully remove packet protection.
-->


24) <!-- [rfced] Section 17.2.2:  We found this sentence confusing
because (1) three fields are listed after it and (2) Figure 31 and
the text after it show that NEW_TOKEN frames also contain a Token
Length field and a Token field.  Will this sentence be clear to
readers?

Original:
 The first byte contains the
 Reserved and Packet Number Length bits; see also Section 17.2.
 Between the Source Connection ID and Length fields, there are two
 additional fields specific to the Initial packet.

 Token Length:  A variable-length integer specifying the length of the
    Token field, in bytes.  This value is zero if no token is present.
    Initial packets sent by the server MUST set the Token Length field
    to zero; clients that receive an Initial packet with a non-zero
    Token Length field MUST either discard the packet or generate a
    connection error of type PROTOCOL_VIOLATION.

 Token:  The value of the token that was previously provided in a
    Retry packet or NEW_TOKEN frame; see Section 8.1.

 Packet Payload:  The payload of the packet. -->


25) <!-- [rfced] Section 17.2.2:  "This protection ... provides some
level of protection" reads oddly.  If the suggested text is not
correct, is there a better way to rephrase this text?

Original:
 This protection does not
 provide confidentiality or integrity against attackers that can
 observe packets, but provides some level of protection against
 attackers that cannot observe packets.

Suggested:
 This functionality does not
 provide confidentiality or integrity against attackers that can
 observe packets, but it provides some level of protection against
 attackers that cannot observe packets. -->


26) <!-- [rfced] Section 19.1:  Does "an initial client packet" have the
same meaning as "a client Initial" as used elsewhere in this document
or a different meaning?

Original:
 Padding can be used to
 increase an initial client packet to the minimum required size, or to
 provide protection against traffic analysis for protected packets. -->


27) <!-- [rfced] Section 19.3.2:  Are "CE Count" (Section 13.4.1 and
this section) and "ECN-CE Count" (Section 13.4.2.1 and Figure 27)
the same thing or different things?

Original:
 On receiving an IP packet with an ECT(0), ECT(1) or CE codepoint, an
 ECN-enabled endpoint accesses the ECN field and increases the
 corresponding ECT(0), ECT(1), or CE count.
...
 ECN validation also fails if the sum of the increase in ECT(0) and
 ECN-CE counts is less than the number of newly acknowledged packets
 that were originally sent with an ECT(0) marking.  Similarly, ECN
 validation fails if the sum of the increases to ECT(1) and ECN-CE
 counts is less than the number of newly acknowledged packets sent
 with an ECT(1) marking.  These checks can detect remarking of ECN-CE
 markings by the network.
...
 It is therefore possible for the total increase in ECT(0),
 ECT(1), and ECN-CE counts to be greater than the number of packets
 that are newly acknowledged by an ACK frame.
...
 ECN Counts {
   ECT0 Count (i),
   ECT1 Count (i),
   ECN-CE Count (i),
 }

                      Figure 27: ECN Count Format
...
 CE Count:  A variable-length integer representing the total number of
    packets received with the CE codepoint in the packet number space
    of the ACK frame. -->


28) <!-- [rfced] Section 19.11:  This sentence does not parse.  Are some
words missing, or should "frame to be received that state" be "frame
to be received that indicates"?

Original:
 Loss or reordering can cause a MAX_STREAMS frame to be received that
 state a lower stream limit than an endpoint has previously received.
 MAX_STREAMS frames that do not increase the stream limit MUST be
 ignored. -->


29) <!-- [rfced] Please consider whether the intro text should 
be updated - perhaps "aims to address the following"? 

Original:
   In the presence of an on-path attacker, QUIC aims to provide the
   following properties:

   1.  An on-path attacker can prevent use of a path for a connection,
       causing the connection to fail if it cannot use a different path
       that does not contain the attacker.  This can be achieved by
       dropping all packets, modifying them so that they fail to
       decrypt, or other methods.
-->


30) <!-- [rfced] Section 21.1.3.2:  We had trouble parsing this sentence.
If the suggested text is not correct, please clarify.

Original:
 It is also assumed that an attacker has the resources necessary to
 affect NAT state, potentially both causing an endpoint to lose its
 NAT binding, and an attacker to obtain the same port for use with its
 traffic.

Suggested:
 It is also assumed that an attacker has the resources necessary to
 affect NAT state, potentially (1) causing an endpoint to lose its
 NAT binding and (2) causing the attacker to obtain the same port for
 use with its traffic. -->


31) <!-- [rfced] Section 22.1.2:  Please confirm that "New uses" (and not
"New users" or perhaps "New implementations") is correct here.

Original:
 New uses of codepoints from QUIC registries SHOULD use a randomly
 selected codepoint that excludes both existing allocations and the
 first unallocated codepoint in the selected space. -->


32) <!-- [rfced] Section 22.2:  We see the lowercase form "version
negotiation" elsewhere in this document, when used generally.
Should "reserved for Version Negotiation" be "reserved for Version
Negotiation packets" or "reserved for version negotiation"?

Original:
 The
 codepoint of 0x00000000 is permanently reserved; the note for this
 codepoint [shall] indicate[s] that this version is reserved for
 Version Negotiation. -->


33) <!-- [rfced] Should the "QUIC Transport Parameters" registry 
include a "permanent" range (similar to the "QUIC Versions" 
registry)?  Or are values outside of those marked "provisional"
all considered permanent?

Original:
   Permanent registrations in this registry are assigned using the
   Specification Required policy ([RFC8126]).

IANA site <https://www.iana.org/assignments/quic>: 
provisional                                   Expert Review
provisional registration date field update    First Come First Served
first unassigned codepoint                    Standards Action
values 31 * N + 27 (for integer values of N)  Reserved
-->


34) <!-- [rfced] To align with the IANA registry, should Frame Name
be Frame Type Name?  

   Frame Name:  A short mnemonic for the frame type.
-->


35) <!-- [rfced] It's not clear to us what "region" refers to here. 
Does "region" mean "range" here?  Does this refer to "provisional",
"permanent", and "first unassigned codepoint"? 

Original:
   The "QUIC Transport Error Codes" registry governs a 62-bit space.
   This space is split into three regions that are governed by different
   policies.
-->


36) <!-- [rfced]  IANA provided the following regarding Transport Error Codes: 

   NOTE: with the authors' permission, we've added padding to the values 
   in Table 7 to match other QUIC registries (e.g. 0x00 instead of 0x0) 
   and changed "Received" in that table to "received."

We have added the leading zero and lowercased "received" to match the IANA
registry.  We updated the values mentioned in Section 20.1 as well. 
Please let us know if any updates are needed.  

-->


37) <!-- [rfced] Please review the items marked "Note:" and let us know 
if any should be marked as <aside>.
-->


38) <!-- [rfced] <https://goo.gl/dMVtFi> seems to no longer be available.  
We get "Sorry, the file you have requested has been deleted."  Is this 
info available elsewhere?  

Original:
   [EARLY-DESIGN]
              Roskind, J., "QUIC: Multiplexed Transport Over UDP", 2
              December 2013, <https://goo.gl/dMVtFi>.
-->


39) <!-- [rfced] Figure 46:  Because the rest of this document uses
"least significant" (no hyphen), may we remove the hyphen in this
pseudocode comment?

Original:
 // the num_bytes least-significant bytes.

Suggested:
 // the num_bytes least significant bytes. -->


40) <!-- [rfced] Appendix A.4:  This sentence does not parse; one or more
words appear to be missing.  Please clarify "successful validation of
the ECN counts an ACK frame (see Section 13.4.2.1) causes the".
(Perhaps "the ECN counts in an ACK frame"?)

Original:
 From the "unknown" state, successful validation of the
 ECN counts an ACK frame (see Section 13.4.2.1) causes the ECN state
 for the path to become "capable", unless no marked packet has been
 acknowledged. -->


41) <!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 Connection ID / connection ID (where used generally; two instances:
   "Each Connection ID", "parameters match received Connection ID
    values.  Including connection ID values ..."

 date field / Date field

 destination connection ID (two instances) / Destination Connection ID
   (We assume that the lowercase instances also refer specifically to
    the Destination Connection ID field; please let us know if this is
    not the case.)

 handshake keys (Section 21.1.1.3) / Handshake keys

 long-header packets (one instance) / long header packet(s)

 Retry Token / Retry token (in running text, where apparently used
   generally and not referring to the field)

 (re)sets (...) to zero / (re)sets (...) to 0

 value of zero / value of 0

 version field / Version field


Quoting was used more often for these state names, so we quoted all
  instances in running text:

 Data Sent state / "Data Sent" state

 Ready state / "Ready" state

 Send state / "Send" state

 Recv state / "Recv" state

 Size Known state / "Size Known" state


b) The following terms or expressions appear to be used
inconsistently in this document.  Please let us know which form is
preferred for each.

 2^62-1 / 2^62 - 1 (e.g., "cannot exceed 2^62-1", "0 to 2^62-1",
   "reaches 2^62 - 1")

 form "31 * N + 27" vs. format "31 * N + 27"

 packet number field / Packet Number field (in running text)
   (draft-ietf-quic-tls uses "Packet Number field" exclusively)

 stateless reset / Stateless Reset (e.g., "sends a Stateless Reset",
   "sends a stateless reset", "Stateless Reset packets", "stateless
   reset packets")

   We also see "Endpoints can send a Stateless Reset (Section 10.3)
   for any packets that cannot be attributed to an existing
   connection.  A stateless reset ..."

 stateless reset token / Stateless Reset Token (e.g., "a stateless
   reset token to be", "a Stateless Reset Token, the", "the stateless
   reset token it is", "the Stateless Reset Token is", "The stateless
   reset token MUST be difficult to guess.  In order to create a
   Stateless Reset Token,") -->


Thank you.

RFC Editor



On Apr 27, 2021, at 12:22 AM, [e-mail] wrote:

*****IMPORTANT*****

Updated 2021/04/27

RFC Author(s):
--------------

Instructions for Completing AUTH48

Your document has now entered AUTH48.  Once it has been reviewed and 
approved by you and all coauthors, it will be published as an RFC.  
If an author is no longer available, there are several remedies 
available as listed in the FAQ (https://www.rfc-editor.org/faq/).

You and you coauthors are responsible for engaging other parties 
(e.g., Contributors or Working Group) as necessary before providing 
your approval.

Planning your review 
---------------------

Please review the following aspects of your document:

*  RFC Editor questions

  Please review and resolve any questions raised by the RFC Editor 
  that have been included in the XML file as comments marked as 
  follows:

  <!-- [rfced] ... -->

  These questions will also be sent in a subsequent email.

*  Changes submitted by coauthors 

  Please ensure that you review any changes submitted by your 
  coauthors.  We assume that if you do not speak up that you 
  agree to changes submitted by your coauthors.

*  Content 

  Please review the full content of the document, as this cannot 
  change once the RFC is published. Please pay particular attention to:
  - IANA considerations updates (if applicable)
  - contact information
  - references

*  Copyright notices and legends

  Please review the copyright notice and legends as defined in
  RFC 5378 and the Trust Legal Provisions 
  (TLP – https://trustee.ietf.org/license-info/).

*  Semantic markup

  Please review the markup in the XML file to ensure that elements of  
  content are correctly tagged.  For example, ensure that <sourcecode> 
  and <artwork> are set correctly.  See details at 
  <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.

*  Formatted output

  Please review the PDF, HTML, and TXT files to ensure that the 
  formatted output, as generated from the markup in the XML file, is 
  reasonable.  Please note that the TXT will have formatting 
  limitations compared to the PDF and HTML.


Submitting changes
------------------

To submit changes, please reply to this email with one of the following, 
using ‘REPLY ALL’ as all the parties CC’ed on this message need to see 
your changes:

An update to the provided XML file
— OR —
An explicit list of changes in this format

Section # (or indicate Global)

OLD:
old text

NEW:
new text

You do not need to reply with both an updated XML file and an explicit 
list of changes, as either form is sufficient.

We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text, 
and technical changes.  Information about stream managers can be found in 
the FAQ.  Editorial changes do not require approval from a stream manager.


Approving for publication
--------------------------

To approve your RFC for publication, please reply to this email s
tating that you approve this RFC for publication.  Please use ‘REPLY ALL’
as all the parties CC’ed on this message need to see your approval.


Files 
-----

The files are available here:
  https://www.rfc-editor.org/authors/rfc9000.xml
  https://www.rfc-editor.org/authors/rfc9000.html
  https://www.rfc-editor.org/authors/rfc9000.pdf
  https://www.rfc-editor.org/authors/rfc9000.txt

Diff file of the text:
  https://www.rfc-editor.org/authors/rfc9000-diff.html

Diff of the XML: 
  https://www.rfc-editor.org/authors/rfc9000-xmldiff1.html

The following file is provided to facilitate creation of your own 
diff files of the XML.  This file is a best effort to capture v3-related format updates only: 
  https://www.rfc-editor.org/authors/rfc9000.form.xml


Tracking progress
-----------------

The details of the AUTH48 status of your document are here:
  https://www.rfc-editor.org/auth48/rfc9000

Please let us know if you have any questions.  

Thank you for your cooperation,

RFC Editor

--------------------------------------
RFC9000 (draft-ietf-quic-transport-34)

Title            : QUIC: A UDP-Based Multiplexed and Secure Transport
Author(s)        : J. Iyengar, Ed., M. Thomson, Ed.
WG Chair(s)      : Lars Eggert, Lucas Pardue, Matt Joras
Area Director(s) : Martin Duke, Zaheduzzaman Sarker