Subject: [quicwg/base-drafts] Ekr wglc comments (#3856)

From: ekr <[email-masked]>
Date: Tue, 07 Jul 2020 19:24:44 -0700

Hopefully some minor editorial changes.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3856

-- Commit Summary --

  * Clarify opaque
  * Clarify gthe ? in the encoding language
  * Don&#39;t say that unidirectional is a long message. That just confuses things
  * Clarify the example of stream IDs
  * Clarify the stream ID limits. Remove redundancy
  * You actually don&#39;t know definitively how many bytes were sent
  * early data -&gt; 0-RTT data
  * Fix description of the results of Version Negotiation. Remind me why this isn&#39;t called Version Error...
  * You don&#39;t change SCID on later packets
  * Clarify impact of on-path spoofing
  * Clarify awkward text around preferred connection
  * Tiny wording change
  * Retry packets don&#39;t use keys derived from the handshake
  * One follows the guidance
  * Remove commas, this is a restrictive clause
  * includes -&gt; included
  * Clarify which field

-- File Changes --

    M draft-ietf-quic-transport.md (110)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3856.patch
https://github.com/quicwg/base-drafts/pull/3856.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jul 2020 21:25:43 -0700

@martinthomson commented on this pull request.

There are a couple of conflicts here with other work, but this is generally OK.

> +To remedy this issue, a RESET_STREAM frame ({{frame-reset-stream}})
+includes the final size of data sent on the stream.  On receiving a
+RESET_STREAM frame, a receiver knows how many bytes the sender claims
+were sent on that stream before the RESET_STREAM frame, and the
+receiver MUST use the final size of the stream to account for all
+bytes sent on the stream in its connection level flow controller.

I think that this is just removing a single word, but the reflow makes it hard to parse.

C-u 8 0 M-x set-fill-column

Or install editorconfig.

> +- if 0-RTT data is supported, embed application-controlled data in the TLS
   resumption ticket sent to the client; and
-- if Early Data is supported, retrieve application-controlled data from the
-  client's resumption ticket and enable rejecting Early Data based on that
+- if 0-RTT data is supported, retrieve application-controlled data from the
+  client's resumption ticket and enable rejecting 0-RTT data based on that
   information.

I think that we need to get @MikeBishop to fight this out.

> @@ -1527,12 +1530,13 @@ Connection ID is chosen by the recipient of the packet and is used to provide
 consistent routing; the Source Connection ID is used to set the Destination
 Connection ID used by the peer.
 
-During the handshake, packets with the long header ({{long-header}}) are used to
-establish the connection IDs in each direction. Each endpoint uses the Source
-Connection ID field to specify the connection ID that is used in the Destination
-Connection ID field of packets being sent to them. Upon receiving a packet, each
-endpoint sets the Destination Connection ID it sends to match the value of the
-Source Connection ID that it receives.
+During the handshake, packets with the long header ({{long-header}})
+are used to establish the connection IDs in each direction. Each
+endpoint uses the Source Connection ID field to specify the connection
+ID that is used in the Destination Connection ID field of packets
+being sent to them. Upon receiving the first packet from the peer,

Again, this seems to be just one change.

Should this be "first Initial" instead.

> +Once the handshake is confirmed, the client SHOULD select one of the two values
+preferred addresses provided by the server and initiate path validation (see

Redundancy here:

```suggestion
Once the handshake is confirmed, the client SHOULD select one of the two
preferred addresses provided by the server and initiate path validation (see
```

> +and its state is discarded when it remains idle for longer than either
+
+the minimum of

See #3847.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#pullrequestreview-444402212

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 05:26:23 -0700

@ekr commented on this pull request.

Yes, that's the change. Of course, you could also have decided to use a fill column that emacs already had :)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r451504707

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 05:27:05 -0700

I'm fine with Early Data but it was undefined, so this seemed like the easiest fix. But a defn. would work too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r451505072

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 05:27:20 -0700

yes, I think first Initial

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r451505221

---

From: ekr <[email-masked]>
Date: Wed, 08 Jul 2020 05:28:10 -0700

This is what the text already said, but I think its confusing. My suggestion is "values for preferred address provided by the server

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r451505706

---

From: Mike Bishop <[email-masked]>
Date: Thu, 09 Jul 2020 10:26:03 -0700

@MikeBishop commented on this pull request.

It doesn't help that RFC 8446 uses "0-RTT Data" and "Early Data" almost equal numbers of times.  We should have picked one and stuck to it.  Ah well -- we can do the same thing RFC 8446 does and put ("Early Data") as a synonym after the first mention of 0-RTT.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r452376027

---

From: ekr <[email-masked]>
Date: Thu, 09 Jul 2020 10:33:17 -0700

> It doesn't help that RFC 8446 uses "0-RTT Data" and "Early Data" almost equal numbers of times.

Happy to be of service

> Ah well -- we can do the same thing RFC 8446 does and put ("Early Data") as a synonym after the first mention of 0-RTT.

That would be fine. I'm really fine with any resolution here that is clear.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#discussion_r452380167

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jul 2020 15:52:57 -0700

Closed #3856 via #3901.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3856#event-3546211292