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

["Martin Thomson" <[e-mail]>]

As before, we're still in the process of reviewing the changes, but I think that all of these are staged in one way or other.

The complete set of outstanding changes to this document are in progress, so they are either in our working copy:
  https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md
or they are in open pull requests that affect that document:
  https://github.com/quicwg/base-drafts/pulls?q=is%3Apr+is%3Aopen+label%3A-transport

Regarding the use of title case, the edits changed "During" to "during" and "using" to "Using".  I just want to confirm that the former was deliberate.  As a preposition, during makes sense; though I'm less certain about "Address Validation [U]sing Retry Packets" (Section 8.1.2).

Answers to queries inline.  Updates for the documents are mostly done now and I expect to provide updates for RFCs-to-be 8999 through 9001 this week.

On Tue, Apr 27, 2021, at 17:39, [e-mail] wrote:
> 1) <!-- [rfced] Please insert any keywords (beyond those that appear 
> in the title) for use on https://www.rfc-editor.org/search -->

transport, protocol

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

I've proposed an edit to refer to the specific section, but that meant changing the previous sentence to refer more specifically also.

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

This text has strong agreement; whatever people might think about the name (that it was previously an acronym, or that it has expansions), it's use in this document is strictly as a name.

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

This change was made in our copy a couple of days after the version you received.  We'll provide a version with superscripts.  (Changes to xml2rfc were required to get the rendering right, but it should be good now.)

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

These are good suggestions; I've staged them.

> 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" 

These are good suggestions; I've staged them.

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

I've proposed a change here, but we're still working through this one.
 
> 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. -->

That's good; the nesting here is awkward, but this is a minimal change that should help.

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

"S1" is correct (and yes, the client generates the value, which is unusual).  To avoid the risk of misinterpretation I've add a brief clarification.

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

This sentence is badly worded I think.  I've tried to reorganize a little and will propose something different.

> To enable 0-RTT, endpoints store the values of the server transport parameters with any session tickets it receives on the connection.  Endpoints also store any information required by the application protocol or cryptographic handshake; see {{Section 4.6 of QUIC-TLS}}.  The values of stored transport parameters are used when attempting 0-RTT using the session tickets.

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

Yes, this is correct (though we dropped "the" on the basis that it was no longer singular).

 > 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?

Sounds good.  Staged.

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

Much clearer, thanks.

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

Done and thanks.

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

Yes, that wasn't very good.  We went with:

> * Connection close signals, including packets that contain CONNECTION_CLOSE frames, are not sent again when packet loss is detected. Resending these signals is described in {{termination}}.


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

Went with:

> A new frame is sent if a packet 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.

Very good, thanks.

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

Section 5.2 is correct.  We are not referring to text on packet injection in RFC 8085, but text on handling ICMP messages.  (The specific text being referenced is "Applications SHOULD appropriately validate the payload of ICMP messages [...]")


> 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?

It was Item 7.  Thanks for clarifying.

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

That is correct.  Thanks.

> 21) <!-- [rfced] Table 4: Will "2Bit" be clear to readers?  

I've changed to 2MSB (though this is risky as I did not also also capitalize "most significant bits" in the preceding text; MSB is in the abbreviation list at https://www.rfc-editor.org/materials/abbrev.expansion.txt  so I figure that this is safe enough).

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

The first removed mention of the sample values; so I restored that.  Other than that, this is good.

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

Ah, the distinction was that the full value is necessary to *complete* the process, even though the full value is not available at the start of the process.

Changed the last sentence to:

> Recovering the full packet number is necessary to successfully complete the removal of 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?

This can remain "two additional fields" as the Packet Payload piece can be moved to a different section.

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

Going with:

> This does not provide confidentiality or integrity against attackers that can observe packets, but it does prevent attackers that cannot observe packets from spoofing Initial 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. -->

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.

> 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?

The ECN people might consider this to be sacreligious, but I changed all instances of this to ECN-CE.  ECN documents might use the shorthand "CE", but this isn't an ECN document and the extra qualification is probably best.

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

Yes, that wasn't great.  Going with:

> Loss or reordering can cause an endpoint to receive a MAX_STREAMS frame with a lower stream limit than was previously received. 


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

Going with the more succinct:

> QUIC aims to constrain $type of attacker capabilities as follows:

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

This isn't two separate items, it's really just one:

> It is also assumed that an attacker has the resources necessary to affect NAT state. In particular, an attacker can cause an endpoint to lose its NAT binding and then obtain the same port for use with its own traffic.

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

Yeah, it's "uses", but as that is unclear, we can concentrate on the request for registration:

> New requests for codepoints from QUIC registries SHOULD [...]

> 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"?

Yeah, either would do.  I'll send a note to IANA.

> 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?

I've opened an issue to track this one.  It looks like we missed this one.

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

Yes, good call.

> 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"? 

Yes, "range" is better.

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

Yes, thanks for doing that.  We had that in our copy, but we didn't get that to you.

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

Done.


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

Ah, the Web rots so fast.

I don't think that the longer URL will go away so easily:
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit?usp=sharing


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

It's commentary, so we can afford to be correct.

> 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"?)

Going with:

> From the "unknown" state, successful validation of the ECN counts an ACK frame (see [...]) 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.

You chose the options we had decided on, but we failed to be consistent on.  Thanks for that.

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

Thanks.  Same problem as above.

> 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")

The form without spaces is what we settled on (fixed as part of our change to use <sup> throughout).

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

Went with the former -- "form".

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

-tls was correct; I've corrected those that I found.
 
>  stateless reset / Stateless Reset (e.g., "sends a Stateless Reset",
>    "sends a stateless reset", "Stateless Reset packets", "stateless
>    reset packets")

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.

>  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,") -->

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