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

[Lynne Bartholomew <[e-mail]>]

Hi, Martin.  Thank you for updating this document!

We have some additional questions for you:

* Regarding this question and your reply:
26) 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.

MT:  Yes, this should be capitalized, but I notice that there's another mistake in there.  It's not limited to "client Initial" packets as we require expansion of most Initial packets now.

We did not see any other related changes.  Was the mistake resolved?

= = = = = = = = = = = =

* Regarding this update to Table 7 (changing "Invalid Token received"
to "Invalid token received"):  
0x0b 	INVALID_TOKEN 	Invalid token received

Please confirm that this is as desired.  We ask because we see
the following in Section 20.1, which seems to indicate that "token"
means "Token field":

 INVALID_TOKEN (0x0b):  A server received a client Initial that
      contained an invalid Token field.

<https://www.iana.org/assignments/quic/> has "Invalid Token received"

Perhaps the entry in Table 7 and on the IANA page should say
"Invalid Token field received"?

= = = = = = = = = = = =

* Should "The length of the packet number field is encoded"
be "The length of the Packet Number field is encoded"?
It appears that several earlier instances of "packet number field"
were changed to "Packet Number field" in the latest copy.

= = = = = = = = = = = =

* Regarding this item:

stateless reset / Stateless Reset (e.g., "sends a Stateless Reset",
  "sends a stateless reset", "Stateless Reset packets", "stateless
  reset packets")
- - -
MT:  When referring to the concept, it's lowercase "stateless reset".  When referring to the thing that is sent (a datagram, not a packet), it's title case "Stateless Reset".  This makes it a little fiddly.

I've also gone through a removed "packet" from all instances of "Stateless Reset packet" as these are not packets.
- - -

We still see 9 instances of "Stateless Reset [packet][packets]"; should these be "Stateless Reset[s]"?

= = = = = = = = = = = =

* Regarding this item:
  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,")
- - -
MT:  Yes, that is indeed unfortunate.  We were extraordinarily inconsistent there.  As above, I've gone with "stateless reset token" as a concept and "Stateless Reset Token field" to refer to a specific field (which appears only rarely).
- - -

Should "a different Stateless Reset Token or a different sequence number" be "a different stateless reset
token or a different sequence number" or "a different Stateless Reset Token field or a different Sequence Number field"?
(For the most part, "stateless reset token" where used generally has been lowercased in the latest copy.)

= = = = = = = = = = = =

* The latest copy reintroduces a run-on sentence corrected previously:

   An endpoint cannot determine the Source Connection ID from a packet
   with a short header, therefore it cannot set the Destination
   Connection ID in the Stateless Reset.

May we restore the correction (which was "... with a short header; therefore, it ..."?

= = = = = = = = = = = =

* We tried to change "and Section 5.2 of [RFC8085]" to "and Section 5.2 of [BCP145]", as done elsewhere.
However, we received the following error:

Error: Expected the target of an <xref> with a section= attribute to be a <reference>, found <referencegroup>
Not creating output file due to errors (see above)
Unable to complete processing rfc9000.xml

We verified that this is an error related to a section-number citation for a reference entry that uses "<referencegroup>" and will report it shortly.

In the meantime, please advise as to how to make this citation string consistent in this document.

= = = = = = = = = = = =

* We see that in this document, the title of RFC 9001 has been changed to "Using Transport Layer Security (TLS) to Secure QUIC".
However, it has not been changed in the latest copies of RFC 9001 itself or in RFC 9002.
Please advise re. your preference for this cluster.


We have posted your latest files, in their various forms, here:

   https://www.rfc-editor.org/authors/rfc9000.txt
   https://www.rfc-editor.org/authors/rfc9000.pdf
   https://www.rfc-editor.org/authors/rfc9000.html
   https://www.rfc-editor.org/authors/rfc9000.xml
   https://www.rfc-editor.org/authors/rfc9000-diff.html
   https://www.rfc-editor.org/authors/rfc9000-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9000-lastdiff.html
   https://www.rfc-editor.org/authors/rfc9000-lastrfcdiff.html

   https://www.rfc-editor.org/authors/rfc9000-xmldiff1.html
   https://www.rfc-editor.org/authors/rfc9000-xmldiff2.html


Thanks again!

RFC Editor/lb

> On May 2, 2021, at 11:32 PM, Martin Thomson <[e-mail]> wrote:
> 
> On Wed, Apr 28, 2021, at 05:40, Lynne Bartholomew wrote:
>> Hi, Jana and Martin.
>> 
>> Please note that we have added the following two items to our question 
>> 41)b) below:
>> 
>> Largest Acknowledged / largest acknowledged (RFC-to-be 9001 has one instance of
>>  "Largest Acknowledged field", and RFC-to-be 9002 uses the lowercase form)
> 
> I've taken a look at this and have made a few changes to either "L A field" or "l a" (the concept) as appropriate.
> 
>> stream ID / Stream ID (in running text, e.g., "a stream ID", "a Stream ID")
>>  (When not specifically referring to the Stream ID field, the
>>   lowercase form appears to be more common)
> 
> Yeah, "stream ID" is correct and we had a few capitals sneak in there.  I've corrected these.
> 
> 
>> Thank you!
>> 
>> RFC Editor/lb
>> 
>> 
>>> On Apr 27, 2021, at 12:39 AM, rfc-editor--- via C430 <[e-mail]> wrote:
>>> 
>>> 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"
>> 
>> Largest Acknowledged / largest acknowledged (RFC-to-be 9001 has one instance of
>>  "Largest Acknowledged field", and RFC-to-be 9002 uses the lowercase form)
>>> 
>>> 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,")
>> 
>> stream ID / Stream ID (in running text, e.g., "a stream ID", "a Stream ID")
>>  (When not specifically referring to the Stream ID field, the
>>   lowercase form appears to be more common)
>>> -->
>>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>>> -- 
>>> C430 mailing list
>>> [e-mail]
>>> https://www.rfc-editor.org/mailman/listinfo/c430
>> 
>> 
>