Subject: Re: [quicwg/base-drafts] Apply the 3x amplification-limit to migration too (#4264)

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Nov 2020 13:58:50 -0800

So those are both performance optimizations that come at the cost of potentially sending more data toward an unverified address.  We exempt the client from address validation when it migrates, but that doesn't mean we need to recommend that it send a whole bunch.

I'd rather not include these as recommendations.

-- 
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/4264#issuecomment-720158145

---

From: martinduke <[email-masked]>
Date: Sun, 01 Nov 2020 14:39:44 -0800

> So those are both performance optimizations that come at the cost of potentially sending more data toward an unverified address. 

How so? The server's address is verified, and that's where the client would be sending this.

-- 
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/4264#issuecomment-720162997

---

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Nov 2020 14:41:58 -0800

That is not the case for a preferred address.  It's possible - if unlikely - that the change in source address means a change in destination also.

-- 
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/4264#issuecomment-720163247

---

From: martinduke <[email-masked]>
Date: Sun, 01 Nov 2020 14:47:31 -0800

I would be happy to exempt SPA from these recommendations, as I didn't
realize we were even including them as "migration".

On Sun, Nov 1, 2020 at 2:41 PM Martin Thomson <[email-masked]>
wrote:

> That is not the case for a preferred address. It's possible - if unlikely
> - that the change in source address means a change in destination also.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/4264#issuecomment-720163247>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AF2EYEKVEBIFA4KLODP4YTDSNXP3DANCNFSM4TBWJLNA>
> .
>

-- 
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/4264#issuecomment-720163864

---

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Nov 2020 14:55:10 -0800

Even there, I think that it is a fine performance optimization, but not something I would want to recommend.

-- 
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/4264#issuecomment-720164719

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 01 Nov 2020 15:30:33 -0800

@martinduke 
> 1.    "After a long idle period, clients SHOULD send at least one, and ideally at least three, full size datagrams in its first transmission in case a NAT rebinding forces the server to validate the path and MTU."
> 2. "When migrating to a new address on a path that has not already been validated by both endpoints, a client SHOULD send at least one, and ideally at least three, full size datagrams to allow fast MTU validation and use of the entire congestion window."

I too think that these recommendations are unnecessary.

Firstly, IMO it is unbalanced to recommend to sending three full-sized datagrams in these cases, when clients are expected to send only one full-sized datagram when creating a new connection.

Secondly, when the client migrates to an unvalidated path, we already require them to send a full-sized datagram containing PATH_CHALLENGE.

Thirdly, it is not a good idea for clients idle for a long time then elicit NAT rebinding. Rather, endpoints should be exchanging packets periodically, so that the NAT entry persists. Otherwise, the path from the server to the client gets lost. Therefore, I think that there's no reason to specify optimizations regarding how a client should recover from NAT rebinding.

-- 
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/4264#issuecomment-720169188

---

From: Nick Banks <[email-masked]>
Date: Sun, 01 Nov 2020 16:04:18 -0800

Personally, I side with @martinduke more on the topic of recommending these behaviors as ways to improve migration scenarios. They don't have to be frames as explicit recommendations, but could just be mentioned as ways to improve things.

> Firstly, IMO it is unbalanced to recommend to sending three full-sized datagrams in these cases, when clients are expected to send only one full-sized datagram when creating a new connection.

I agree it's unbalanced, but for both larger server certificate scenarios and 0-RTT scenarios it _might_ actually make sense to recommend similar client behavior for the handshake.

> Secondly, when the client migrates to an unvalidated path, we already require them to send a full-sized datagram containing PATH_CHALLENGE.

I'm not sure I understand the point here. Are you saying that because we require 1 full packet, we shouldn't recommend 3?

> Thirdly, it is not a good idea for clients idle for a long time then elicit NAT rebinding. Rather, endpoints should be exchanging packets periodically, so that the NAT entry persists. Otherwise, th…

As far as I understand, if the server's infrastructure can survive NAT rebindings, there is no such recommendation to avoid them. Why waste the keep alives if you don't need to receive any packet from the server? Therefore, when the client does end up sending after idle (which might result in rebinding) why not account for the possibility of NAT rebinding and send a bit more?

Again, we don't need to recommend these behaviors. They can just be mentioned as possible solutions to bottlenecks that may arise from migration.

-- 
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/4264#issuecomment-720174103

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 01 Nov 2020 16:20:17 -0800

@nibanks Regarding the first two points, I think we should rather not start designing the protocol by discussing how much data clients should send when establishing a connection.

Regarding the last point, I think your point is that the optimization might matter when the server knows that it is not going to send any data until it receives something from the client, because otherwise the server will trying to keep the connection open. To paraphrase, the optimization depends on the application protocol, and how that application protocol is used. Another point to remember is that this optimization is unnecessary when NAT rebinding only changes the port number, and if the server does not revalidate the path when only the port number changes.

IIUC, these points together lead to the conclusion that the optimization covers a niche that might or might not be possible depending on application behavior.

-- 
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/4264#issuecomment-720176658

---

From: Nick Banks <[email-masked]>
Date: Sun, 01 Nov 2020 16:28:40 -0800

> Another point to remember is that this optimization is unnecessary when NAT rebinding only changes the port number, and if the server does not revalidate the path when only the port number changes.

@kazuho as far I understand (please correct me if I'm wrong) amplification protection still applied to migration as a result of port-only NAT rebinding. We're just saying that in this case, the server can't pad it's PATH_CHALLENGES, so PMTU validation doesn't happen along with address validation. The only other exception we make for port-only NAT rebinding is not requiring congestion control reset, though, as @martinduke already mentioned the idleness that goes along with this scenario _should_ trigger that reset anyways.

-- 
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/4264#issuecomment-720178275

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 03 Nov 2020 15:17:53 -0800

@nibanks Ah thanks. That's true (though I do think that the server does not have to be restricted to 3x when the client unintentionally migrates to a different port, assuming that the server does path validation). Anyways, I think my other point still holds, that the optimization is a niche that relies on the properties of an application protocol, and therefore that there is no strong necessity to explain.

-- 
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/4264#issuecomment-721424454

---

From: Nick Banks <[email-masked]>
Date: Tue, 03 Nov 2020 15:37:44 -0800

> though I do think that the server does not have to be restricted to 3x when the client unintentionally migrates to a different port, assuming that the server does path validation

This is not clear to me from the PR. I'm personally fine with making an exception for this, but it should be called out in the PR, otherwise I will assume no such exception.

-- 
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/4264#issuecomment-721430755

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 03 Nov 2020 15:53:04 -0800

@nibanks While I think that a server does not have to be restricted under certain circumstances, trying to describe the conditions is going to be tricky. Moreover, we have had the restriction for quite some time; this PR is merely changing that restriction from 2 MTU per RTT to 3x of the bytes received. Therefore, I think that a new issue is needed if we are going to discuss when a server does not have to be restricted. That said, I would prefer not to (re)open that discussion; I think we have discussed it in the past.

-- 
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/4264#issuecomment-721435411

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 03 Nov 2020 16:34:56 -0800

Can we move the discussion here to the issue, please?

-- 
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/4264#issuecomment-721447401

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 03 Nov 2020 17:47:31 -0800

@janaiyengar commented on this pull request.

> @@ -1894,8 +1894,14 @@ use the server to send more data toward the victim than it would be able to send
 on its own.
 
 The primary defense against amplification attack is verifying that an endpoint

This should be "the peer" instead of "an endpoint", since the context here is that this endpoint is doing the validation.

> +is able to receive packets at the transport address that it claims.  An endpoint
+that responds to packets received from a new address limits the data it sends to
+that address until the peer address is validated.  Prior to validating the
+peer's address, endpoints MUST NOT send datagrams toward that address whose
+total payload exceeds three times the amount of data received from that address.
+This limit on the size of responses is known as the anti-amplification limit.

```suggestion
is able to receive packets at the transport address that it claims. Therefore,
on receiving packets from a new address that is not yet validated, an endpoint
MUST limit the amount of data it sends to the unvalidated address to three times
the amount of data received from that address. This limit on the size of
responses is known as the anti-amplification limit.
```

> +If an endpoint is unable to expand the datagram payload to 1200 bytes, no
+padding is necessary.  However, this means that the path MTU will not be

```suggestion
When an endpoint is unable to expand the datagram size to 1200 bytes due to
the anti-amplification limit, the path MTU will not be
```

> +if it is constrained by an anti-amplification limit.  This will only occur if
+the PATH_CHALLENGE was not sent in an expanded datagram.

```suggestion
if the resulting data exceeds the anti-amplification limit.  This is expected
to only occur if the received PATH_CHALLENGE was not sent in an expanded
datagram.
```

> +If the PATH_CHALLENGE frame was sent in a datagram that was not expanded to at
+least 1200 bytes, an endpoint can regard the address as valid for the purposes
+of sending more than three times the amount of data that has been received.
+However, the path MTU is not validated so the endpoint MUST initiate another
+path validation to verify that the path MTU is sufficient.

```suggestion
If the PATH_CHALLENGE frame that resulted in successful path validation was sent
in a datagram that was not expanded to at least 1200 bytes, the endpoint can
regard the address as valid for the purposes of sending more than three times
the amount of data that has been received. However, the endpoint MUST initiate
another path validation with an expanded datagram to verify that the path
supports required MTU.
```

> +is validated, servers MUST NOT send more data on the path than three times the
+number of bytes received on the path; see {{address-validation}}.

```suggestion
is validated, servers MUST limit data sent on the path to three times the
number of bytes received on the path; see {{address-validation}}.
```

> +send.  Endpoints cannot send data toward an unvalidated address in excesss of
+three times the data received from that address.

```suggestion
send.  Endpoints cannot send data toward an unvalidated address in excess of
three times the data received from that address.
```

> +: The three times anti-amplification limit only applies when sending in
+  response to packets received from an unvalidated address. The
+  anti-amplification limit does not apply to clients that establish a new
+  connection or when path migration is initiated.

```suggestion
: The anti-amplification limit only applies when an endpoint responds to packets
  received from an unvalidated address. The anti-amplification limit does not
  apply to clients when establishing a new connection or when initiating path
  migration.
```

-- 
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/4264#pullrequestreview-522984330

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 18:24:08 -0800

@martinthomson pushed 1 commit.

fb033df77a488b9dba18ec17d324715b941cea69  Jana's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/8c0c1f9fc9352eb96ca64f333574d5e14d91f4dd..fb033df77a488b9dba18ec17d324715b941cea69

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 20:42:14 -0800

f930b24dc92c27e27ecaffbeb1b4156b950d1ac8  sssss

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/fb033df77a488b9dba18ec17d324715b941cea69..f930b24dc92c27e27ecaffbeb1b4156b950d1ac8

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 20:42:42 -0800

46bef9ece7eb31f7ea2c21ab16ac6809ee5c7ea6  MUST limit

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/f930b24dc92c27e27ecaffbeb1b4156b950d1ac8..46bef9ece7eb31f7ea2c21ab16ac6809ee5c7ea6

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 20:47:12 -0800

@martinthomson pushed 42 commits.

5218286342445db502825c524a7dc2b839b3588b  Cite the notation section the first time it is used
1d2a727c1dd9fcde74eb917b1606ee4f0af97cb3  Describe inputs to the packet number algorithm
9c9e2869b69d6c7ebe0d4db1dd0a1c0004d41b78  Maximum datagram size of 1200 is a requirement
15d7eb45d5e52e47948efb16ba18408e5e7f53e9  Glue
ba727d62f53ea32b0b8ab9d1063802d31b06e180  Yes, it's bytes
25a7e511aecb2f0aaed3f6cd026ad7ef3a0119f1  Padding non-HOWTO
a69bd0ee0ae0c7e5543c152deb6721d0e91dc52d  Explain what the bitfield references mean
1c6b7a39f7a24bb470377f19e66326edde6d30c9  Moer txt
09997e339e54a11812fb954b68ce7e82b739ef51  Tweak framing of frames table
3cd4a6956b97a81736a367959e8fd40ecb934294  is/are potato/tomato
48c4251af3625a60266e4b6740cfc86d60d28cd7  Tweaked suggestion
4b07ec2f4518af101c4501e6a370e633ee904d33  Define stateless reset token
9bcb4467de99c8816f95e5723a412a78570d7b78  Mike's suggestions
a3c64237d1b8009e903b4d57a5585178e6f3345b  polish
af48a3d1465e6dcdf370a9fb97494cc2f4d12356  Stop using initial timeout
a51f8e9406bed1e4067ddf74adaae9d6f809e0d5  Remove formula with confusing variables
284cebd5fbe87b68e727292f95108c0d609e71b2  initial RTO comparison
4fbb339594a07993a49a8f2e39d16bf03dc92e44  Add a definition for "frame"
a6031307451a4563fa89d64faa60597a70e9611c  Mike's suggestions, tweaked
b630470da763255aab2f1403780947b96aa1165d  s/veyed/tained/
598a39ddf750d5b766b744183186681769099b7e  Packets and datagrams and packets
3abb3550658fcf6613b342b48c3da54079245c99  Packet number encoding in appendix, move examples
10310405803667cd0d6a0d0e1d9d738eadd396e5  Expand example
9a50d2325c154d70cd15c364fc878557a538169e  Apply suggestions from code review
afd5ac1f3346bdbb40432833d68e7db975b8aea6  Less python, more handwaving
71c778f40102f71968a73a784923329efd2cc1c9  period
cc684115ded084d0d4c3a2a1c66792c51bb4470a  Truncatencode
da88b361fc3c17d18345227283b895b465db6c25  Restore the comment in the original text
f03ef8f19120268de085d0a6a3e54ade96f13047  VarInt decoding pseudocode
fe4dd1b3d32c5e163b77c175f1bc7ebf47f3e1ff  Apply suggestions from code review
daa679df4326653d1ea69bf31eefc9af69835745  Add comments
f7f62c43b6ff62f60c885cc48ffcdc2456a031b5  Lars's comment
3eeeae99a1fb47373c504c35ac0bbd189f8fb82d  Expand for clarity
53ae7aebabf16b15da219c6437917fdcf7044ee0  Move spin bit explanation to beginning of section
c4e3d6df4bed21af62cdd5ae9bcb78e8a7e0b686  Move overview to be first subsection
ea17765dd7d15b2a5b02749350e50a170db9894e  Intro to Security Considerations
235072d159bd898170d7f17e1782a9e81c15c1ba  Martin's suggested intro, tweaked
16659516319cdbd43067e68faf7a10b6667a381d  Establish normative force more directly.
e6140bb7a3406ed815b4bbe8f2b49c7bbf725d41  Add pseudocode intro
caf1e121fea36c39ca2c73e94c110799dfe7dce5  Reorder pseudocode sections
2860a6b2987ea22f67b1a8bd9768c49d81ea6f08  plural
7808d2d27b65fc87cf8efac0071267c7943b3760  Wrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/46bef9ece7eb31f7ea2c21ab16ac6809ee5c7ea6..7808d2d27b65fc87cf8efac0071267c7943b3760

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 20:50:17 -0800

@martinthomson pushed 2 commits.

fb253e978fc614de238f2f599460d130b271007a  Merge branch 'master' into migration-amplification
66b7c2a40813602f33eb180160311f0595ed1a15  Merge branch 'master' into migration-amplification

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/7808d2d27b65fc87cf8efac0071267c7943b3760..66b7c2a40813602f33eb180160311f0595ed1a15

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Nov 2020 20:52:36 -0800

593d5527ff8f12dbe741dff6f3a72e901751da58  Reword and use addresses, not paths

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/66b7c2a40813602f33eb180160311f0595ed1a15..593d5527ff8f12dbe741dff6f3a72e901751da58

---

From: David Schinazi <[email-masked]>
Date: Wed, 04 Nov 2020 11:42:32 -0800

@DavidSchinazi approved this pull request.

-- 
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/4264#pullrequestreview-523680040

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 04 Nov 2020 17:46:56 -0800

One point that seems to have been lost is the addition of an error code earlier. I think adding an error code for NO_VIABLE_PATH is a good idea.

-- 
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/4264#issuecomment-722072872

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 14:38:10 -0800

@martinthomson pushed 4 commits.

4769dbea68fe7bfdc70a70d64f141f58f0a4c7f3  Add an error code for when the path fails
352797227bdd9e6228c296707c97aeff4abc8e00  moar
2ffb2abe1ad95f333f7d1b52d125644760fc06c0  Fewer words = good
bbc0711e5fc4c8bda1be34b52b5a99e68defd284  Merge pull request #4331 from quicwg/no-viable-path

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/593d5527ff8f12dbe741dff6f3a72e901751da58..bbc0711e5fc4c8bda1be34b52b5a99e68defd284

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 05 Nov 2020 15:13:36 -0800

@kazuho approved this pull request.

-- 
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/4264#pullrequestreview-524745378

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 05 Nov 2020 18:45:56 -0800

@janaiyengar approved this pull request.

One nit, but LGTM. Thanks for working through this patiently, @martinthomson 

> @@ -2311,7 +2311,10 @@ When an endpoint abandons path validation, it determines that the path is
 unusable.  This does not necessarily imply a failure of the connection -
 endpoints can continue sending packets over other paths as appropriate.  If no
 paths are available, an endpoint can wait for a new path to become available or
-close the connection.
+close the connection.  An endpoint that has no valid network path to its peer
+MAY signal this using the NO_VIABLE_PATH connection error, noting that this is
+only possible if the network path exists but does not support the required
+MTU {{datagram-size}}.

```suggestion
MTU ({{datagram-size}}).
```

-- 
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/4264#pullrequestreview-524820575

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Nov 2020 18:47:59 -0800

54f48ce601be4c5b8be2af72db380f58a4b7aca3  use parentheses for adjunct citations

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/bbc0711e5fc4c8bda1be34b52b5a99e68defd284..54f48ce601be4c5b8be2af72db380f58a4b7aca3

---

From: ianswett <[email-masked]>
Date: Fri, 13 Nov 2020 09:56:50 -0800

@ianswett commented on this pull request.

> @@ -2686,9 +2709,9 @@ might also occur because the client's access network used a different NAT
 binding for the server's preferred address.
 
 Servers SHOULD initiate path validation to the client's new address upon

This entire paragraph doesn't seem very specific to "Interaction of Client Migration and Preferred Address"

I think it'd be better to reference the section and not put these normative statements here, since they are so general.

-- 
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/4264#pullrequestreview-530284446

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Nov 2020 19:04:12 -0800

@martinthomson commented on this pull request.

Agreed.

-- 
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/4264#discussion_r523876072

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 Nov 2020 19:04:21 -0800

fae20ab16577e27c7391cbac865242bf4b7b8737  A section reference is all we really need here.

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/54f48ce601be4c5b8be2af72db380f58a4b7aca3..fae20ab16577e27c7391cbac865242bf4b7b8737

---

From: ianswett <[email-masked]>
Date: Sun, 15 Nov 2020 21:23:48 -0800

@ianswett approved this pull request.

-- 
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/4264#pullrequestreview-530925067

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 Nov 2020 21:31:19 -0800

-- 
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/4264#pullrequestreview-530926970

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 Nov 2020 21:38:20 -0800

@martinthomson: you might need to rebase your branch to resolve conflicts.

-- 
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/4264#issuecomment-727746825

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 Nov 2020 15:10:26 -0800

3e5b0fd79e99bc1dfef884234b2699240ced1a3a  Merge branch 'master' into migration-amplification

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4264/files/fae20ab16577e27c7391cbac865242bf4b7b8737..3e5b0fd79e99bc1dfef884234b2699240ced1a3a

---

From: ianswett <[email-masked]>
Date: Mon, 16 Nov 2020 15:18:31 -0800

Follow-up Q: Is this SHOULD specific to "Interaction of Client Migration and Preferred Address" or more general?  It seems more general, but I don't have a strong opinion.

-- 
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/4264#discussion_r524734912