Date: Thu, 13 Dec 2018 14:45:44 -0800
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab34286406ff3e21647610c21648b8befb9ba95d4792cf00000001182aa31892a169ce174c6329@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2164/review/184895292@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2164@github.com>
References: <quicwg/base-drafts/pull/2164@github.com>
Subject: Re: [quicwg/base-drafts] Ekr editorial 17 3 (#2164)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c12e11832205_c833facfe2d45c01100b";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ULFB7Ofvrn8FGq51bi9eV6-gVbk>


----==_mimepart_5c12e11832205_c833facfe2d45c01100b
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

mikkelfj commented on this pull request.



> @@ -1533,12 +1533,15 @@ Once a client has received an acknowledgment for a Handshake packet it MAY send
 smaller datagrams.  Sending padded datagrams ensures that the server is not
 overly constrained by the amplification restriction.
 
-In order to prevent a handshake deadlock as a result of the server being unable
-to send, clients SHOULD send a packet upon a handshake timeout, as described in
-{{QUIC-RECOVERY}}.  If the client has no data to retransmit and does not have
-Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least
-1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake
-packet.
+Packet loss, e.g., of the server's Handshake packet, can cause a
+situation in which the server cannot send becaus of the

```suggestion
situation in which the server cannot send because of the
```

> @@ -1616,7 +1619,8 @@ Token field of its Initial packet.
 A token allows a server to correlate activity between the connection where the
 token was issued and any connection where it is used.  Clients that want to
 break continuity of identity with a server MAY discard tokens provided using the
-NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded.
+NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded
+during connection establishment (they will not be used with new connections).
 

How about a positive: A token obtained in a Retry packet must be used immediately during the connection attempt and cannot be used in subsequent connection attempts.

> @@ -1679,9 +1683,10 @@ peer from a new local address.  In path validation, endpoints test reachability
 between a specific local address and a specific peer address, where an address
 is the two-tuple of IP address and port.
 
-Path validation tests that packets can be both sent to and received from a peer
-on the path.  Importantly, it validates that the packets received from the
-migrating endpoint do not carry a spoofed source address.
+Path validation tests that packets (PATH_CHALLENGE) can be both sent
+to and received (PATH_RESPONSE) from a peer on the path.  Importantly,
+it validates that the packets received from the migrating endpoint do
+not carry a spoofed source address.
 

But that isn't exactly true since MITM can spoof the source address of these packets if it can guess the packet content (as you pointed out).

> @@ -1716,8 +1721,9 @@ loss.  An endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it
 would an Initial packet, ensuring that connection migration is no more load on a
 new path than establishing a new connection.
 
-The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
-can associate the peer's response with the causative PATH_CHALLENGE.
+The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame
+so that it can associate the peer's response with the causative

```suggestion
so that it can associate the peer's response with the corresponding
```

> @@ -1737,27 +1743,26 @@ to the same remote address from which the PATH_CHALLENGE was received.
 
 ## Successful Path Validation
 
-A new address is considered valid when a PATH_RESPONSE frame is received
-containing data that was sent in a previous PATH_CHALLENGE. Receipt of an
-acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
-validation, since the acknowledgment can be spoofed by a malicious peer.
+A new address is considered valid when A PATH_RESPONSE frame is received
+that meets the following criteria:
+
+- It contains that was sent in a previous PATH_CHALLENGE. Receipt of an

```suggestion
- It contains the data that was sent in a previous PATH_CHALLENGE. Receipt of an
```

>  
-For path validation to be successful, a PATH_RESPONSE frame MUST be received
-from the same remote address to which the corresponding PATH_CHALLENGE was
-sent. If a PATH_RESPONSE frame is received from a different remote address than
-the one to which the PATH_CHALLENGE was sent, path validation is considered to
-have failed, even if the data matches that sent in the PATH_CHALLENGE.
+- It is from the same remote address as that to which the
+  corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is

It was received from the remote address that the corresponding PATH_CHALLENGE was sent to.

>  
-For path validation to be successful, a PATH_RESPONSE frame MUST be received
-from the same remote address to which the corresponding PATH_CHALLENGE was
-sent. If a PATH_RESPONSE frame is received from a different remote address than
-the one to which the PATH_CHALLENGE was sent, path validation is considered to
-have failed, even if the data matches that sent in the PATH_CHALLENGE.
+- It is from the same remote address as that to which the
+  corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is
+  received from a different remote address than the one to which the
+  PATH_CHALLENGE was sent, path validation is considered to have failed,
+  even if the data matches that sent in the PATH_CHALLENGE.

```suggestion
  even if the PATH_RESPONSE data matches the PATH_CHALLENGE data.
```

>  
-If a PATH_RESPONSE frame is received on a different local address than the one
-from which the PATH_CHALLENGE was sent, path validation is not considered to be
-successful, even if the data matches the PATH_CHALLENGE.  This doesn't result in
-path validation failure, as it might be a result of a forwarded packet (see
-{{off-path-forward}}) or misrouting.
+Note that receipt on a different local address doesn't result in path

```suggestion
Note that receipt on a different local address does not result in path
```

> @@ -2338,14 +2345,15 @@ of the packet header.  The remainder of the first byte and an arbitrary
 number of random bytes following it are set to unpredictable values.  The last
 16 bytes of the datagram contain a Stateless Reset Token.
 
-A stateless reset will be interpreted by a recipient as a packet with a short
-header.  For the packet to appear as valid, the Random Bits field needs to
-include at least 182 bits of random or unpredictable values (or 24 bytes, less
-the two fixed bits).  This is intended to allow for a destination connection ID
-of the maximum length permitted, with a minimal packet number, and payload.  The
-Stateless Reset Token corresponds to the minimum expansion of the packet
-protection AEAD.  More random bytes might be necessary if the endpoint could
-have negotiated a packet protection scheme with a larger minimum AEAD expansion.
+A stateless reset will be interpreted by a recipient as a packet with
+a short header.  For the packet to appear as valid, the Random Bits
+field needs to include at least 182 bits of data (or 24 bytes, less
+the two fixed bits). This is intended to allow for a destination

```suggestion
the two fixed bits). This is intended to allow for a Destination
```

> @@ -2338,14 +2345,15 @@ of the packet header.  The remainder of the first byte and an arbitrary
 number of random bytes following it are set to unpredictable values.  The last
 16 bytes of the datagram contain a Stateless Reset Token.
 
-A stateless reset will be interpreted by a recipient as a packet with a short
-header.  For the packet to appear as valid, the Random Bits field needs to
-include at least 182 bits of random or unpredictable values (or 24 bytes, less
-the two fixed bits).  This is intended to allow for a destination connection ID
-of the maximum length permitted, with a minimal packet number, and payload.  The
-Stateless Reset Token corresponds to the minimum expansion of the packet
-protection AEAD.  More random bytes might be necessary if the endpoint could
-have negotiated a packet protection scheme with a larger minimum AEAD expansion.
+A stateless reset will be interpreted by a recipient as a packet with
+a short header.  For the packet to appear as valid, the Random Bits
+field needs to include at least 182 bits of data (or 24 bytes, less
+the two fixed bits). This is intended to allow for a destination
+connection ID of the maximum length permitted, with a minimal packet

```suggestion
Connection ID of the maximum length permitted, with a minimal packet
```

> @@ -4931,10 +4943,10 @@ Frame Type:
 
 Reason Phrase Length:
 
-: A variable-length integer specifying the length of the reason phrase in bytes.
-  Note that a CONNECTION_CLOSE frame cannot be split between packets, so in
-  practice any limits on packet size will also limit the space available for a
-  reason phrase.
+: A variable-length integer specifying the length of the reason phrase
+  in bytes.  Because CONNECTION_CLOSE frame cannot be split between

```suggestion
  in bytes.  Because a CONNECTION_CLOSE frame cannot be split between
```

-- 
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/2164#pullrequestreview-184895292
----==_mimepart_5c12e11832205_c833facfe2d45c01100b
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p><b>@mikkelfj</b> commented on this pull request.</p>=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241582505">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -1533,12 +1533,15 @@ Once a client has =
received an acknowledgment for a Handshake packet it MAY send=0D
 smaller datagrams.  Sending padded datagrams ensures that the server is =
not=0D
 overly constrained by the amplification restriction.=0D
 =0D
-In order to prevent a handshake deadlock as a result of the server being=
 unable=0D
-to send, clients SHOULD send a packet upon a handshake timeout, as descr=
ibed in=0D
-{{QUIC-RECOVERY}}.  If the client has no data to retransmit and does not=
 have=0D
-Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at=
 least=0D
-1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshak=
e=0D
-packet.=0D
+Packet loss, e.g., of the server&#39;s Handshake packet, can cause a=0D
+situation in which the server cannot send becaus of the=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-situation in which the server cannot send bec=
aus of the=0D
+situation in which the server cannot send because of the=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241584218">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -1616,7 +1619,8 @@ Token field of its I=
nitial packet.=0D
 A token allows a server to correlate activity between the connection whe=
re the=0D
 token was issued and any connection where it is used.  Clients that want=
 to=0D
 break continuity of identity with a server MAY discard tokens provided u=
sing the=0D
-NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded=
.=0D
+NEW_TOKEN frame.  Tokens obtained in Retry packets MUST NOT be discarded=
=0D
+during connection establishment (they will not be used with new connecti=
ons).=0D
 =0D
</pre>=0D
<p>How about a positive: A token obtained in a Retry packet must be used =
immediately during the connection attempt and cannot be used in subsequen=
t connection attempts.</p>=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241584830">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -1679,9 +1683,10 @@ peer from a new loc=
al address.  In path validation, endpoints test reachability=0D
 between a specific local address and a specific peer address, where an a=
ddress=0D
 is the two-tuple of IP address and port.=0D
 =0D
-Path validation tests that packets can be both sent to and received from=
 a peer=0D
-on the path.  Importantly, it validates that the packets received from t=
he=0D
-migrating endpoint do not carry a spoofed source address.=0D
+Path validation tests that packets (PATH_CHALLENGE) can be both sent=0D
+to and received (PATH_RESPONSE) from a peer on the path.  Importantly,=0D=

+it validates that the packets received from the migrating endpoint do=0D=

+not carry a spoofed source address.=0D
 =0D
</pre>=0D
<p>But that isn't exactly true since MITM can spoof the source address of=
 these packets if it can guess the packet content (as you pointed out).</=
p>=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241585389">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -1716,8 +1721,9 @@ loss.  An endpoint S=
HOULD NOT send a PATH_CHALLENGE more frequently than it=0D
 would an Initial packet, ensuring that connection migration is no more l=
oad on a=0D
 new path than establishing a new connection.=0D
 =0D
-The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so=
 that it=0D
-can associate the peer&#39;s response with the causative PATH_CHALLENGE.=
=0D
+The endpoint MUST use unpredictable data in every PATH_CHALLENGE frame=0D=

+so that it can associate the peer&#39;s response with the causative=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-so that it can associate the peer's response =
with the causative=0D
+so that it can associate the peer's response with the corresponding=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241585863">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -1737,27 +1743,26 @@ to the same remote=
 address from which the PATH_CHALLENGE was received.=0D
 =0D
 ## Successful Path Validation=0D
 =0D
-A new address is considered valid when a PATH_RESPONSE frame is received=
=0D
-containing data that was sent in a previous PATH_CHALLENGE. Receipt of a=
n=0D
-acknowledgment for a packet containing a PATH_CHALLENGE frame is not ade=
quate=0D
-validation, since the acknowledgment can be spoofed by a malicious peer.=
=0D
+A new address is considered valid when A PATH_RESPONSE frame is received=
=0D
+that meets the following criteria:=0D
+=0D
+- It contains that was sent in a previous PATH_CHALLENGE. Receipt of an=0D=

</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-- It contains that was sent in a previous PAT=
H_CHALLENGE. Receipt of an=0D
+- It contains the data that was sent in a previous PATH_CHALLENGE. Recei=
pt of an=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241586553">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt;  =0D
-For path validation to be successful, a PATH_RESPONSE frame MUST be rece=
ived=0D
-from the same remote address to which the corresponding PATH_CHALLENGE w=
as=0D
-sent. If a PATH_RESPONSE frame is received from a different remote addre=
ss than=0D
-the one to which the PATH_CHALLENGE was sent, path validation is conside=
red to=0D
-have failed, even if the data matches that sent in the PATH_CHALLENGE.=0D=

+- It is from the same remote address as that to which the=0D
+  corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is=0D
</pre>=0D
<p>It was received from the remote address that the corresponding PATH_CH=
ALLENGE was sent to.</p>=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241586761">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt;  =0D
-For path validation to be successful, a PATH_RESPONSE frame MUST be rece=
ived=0D
-from the same remote address to which the corresponding PATH_CHALLENGE w=
as=0D
-sent. If a PATH_RESPONSE frame is received from a different remote addre=
ss than=0D
-the one to which the PATH_CHALLENGE was sent, path validation is conside=
red to=0D
-have failed, even if the data matches that sent in the PATH_CHALLENGE.=0D=

+- It is from the same remote address as that to which the=0D
+  corresponding PATH_CHALLENGE was sent. If a PATH_RESPONSE frame is=0D
+  received from a different remote address than the one to which the=0D
+  PATH_CHALLENGE was sent, path validation is considered to have failed,=
=0D
+  even if the data matches that sent in the PATH_CHALLENGE.=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-  even if the data matches that sent in the P=
ATH_CHALLENGE.=0D
+  even if the PATH_RESPONSE data matches the PATH_CHALLENGE data.=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241587535">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt;  =0D
-If a PATH_RESPONSE frame is received on a different local address than t=
he one=0D
-from which the PATH_CHALLENGE was sent, path validation is not considere=
d to be=0D
-successful, even if the data matches the PATH_CHALLENGE.  This doesn&#39=
;t result in=0D
-path validation failure, as it might be a result of a forwarded packet (=
see=0D
-{{off-path-forward}}) or misrouting.=0D
+Note that receipt on a different local address doesn&#39;t result in pat=
h=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-Note that receipt on a different local addres=
s doesn't result in path=0D
+Note that receipt on a different local address does not result in path=0D=

</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241588625">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -2338,14 +2345,15 @@ of the packet head=
er.  The remainder of the first byte and an arbitrary=0D
 number of random bytes following it are set to unpredictable values.  Th=
e last=0D
 16 bytes of the datagram contain a Stateless Reset Token.=0D
 =0D
-A stateless reset will be interpreted by a recipient as a packet with a =
short=0D
-header.  For the packet to appear as valid, the Random Bits field needs =
to=0D
-include at least 182 bits of random or unpredictable values (or 24 bytes=
, less=0D
-the two fixed bits).  This is intended to allow for a destination connec=
tion ID=0D
-of the maximum length permitted, with a minimal packet number, and paylo=
ad.  The=0D
-Stateless Reset Token corresponds to the minimum expansion of the packet=
=0D
-protection AEAD.  More random bytes might be necessary if the endpoint c=
ould=0D
-have negotiated a packet protection scheme with a larger minimum AEAD ex=
pansion.=0D
+A stateless reset will be interpreted by a recipient as a packet with=0D=

+a short header.  For the packet to appear as valid, the Random Bits=0D
+field needs to include at least 182 bits of data (or 24 bytes, less=0D
+the two fixed bits). This is intended to allow for a destination=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-the two fixed bits). This is intended to allo=
w for a destination=0D
+the two fixed bits). This is intended to allow for a Destination=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241588722">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -2338,14 +2345,15 @@ of the packet head=
er.  The remainder of the first byte and an arbitrary=0D
 number of random bytes following it are set to unpredictable values.  Th=
e last=0D
 16 bytes of the datagram contain a Stateless Reset Token.=0D
 =0D
-A stateless reset will be interpreted by a recipient as a packet with a =
short=0D
-header.  For the packet to appear as valid, the Random Bits field needs =
to=0D
-include at least 182 bits of random or unpredictable values (or 24 bytes=
, less=0D
-the two fixed bits).  This is intended to allow for a destination connec=
tion ID=0D
-of the maximum length permitted, with a minimal packet number, and paylo=
ad.  The=0D
-Stateless Reset Token corresponds to the minimum expansion of the packet=
=0D
-protection AEAD.  More random bytes might be necessary if the endpoint c=
ould=0D
-have negotiated a packet protection scheme with a larger minimum AEAD ex=
pansion.=0D
+A stateless reset will be interpreted by a recipient as a packet with=0D=

+a short header.  For the packet to appear as valid, the Random Bits=0D
+field needs to include at least 182 bits of data (or 24 bytes, less=0D
+the two fixed bits). This is intended to allow for a destination=0D
+connection ID of the maximum length permitted, with a minimal packet=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-connection ID of the maximum length permitted=
, with a minimal packet=0D
+Connection ID of the maximum length permitted, with a minimal packet=0D
</pre>=0D
=0D
=0D
<hr>=0D
=0D
<p>In <a href=3D"https://github.com/quicwg/base-drafts/pull/2164#discussi=
on_r241589569">draft-ietf-quic-transport.md</a>:</p>=0D
<pre style=3D'color:#555'>&gt; @@ -4931,10 +4943,10 @@ Frame Type:=0D
 =0D
 Reason Phrase Length:=0D
 =0D
-: A variable-length integer specifying the length of the reason phrase i=
n bytes.=0D
-  Note that a CONNECTION_CLOSE frame cannot be split between packets, so=
 in=0D
-  practice any limits on packet size will also limit the space available=
 for a=0D
-  reason phrase.=0D
+: A variable-length integer specifying the length of the reason phrase=0D=

+  in bytes.  Because CONNECTION_CLOSE frame cannot be split between=0D
</pre>=0D
=E2=AC=87=EF=B8=8F Suggested change=0D
<pre style=3D"color: #555">-  in bytes.  Because CONNECTION_CLOSE frame c=
annot be split between=0D
+  in bytes.  Because a CONNECTION_CLOSE frame cannot be split between=0D=

</pre>=0D
=0D
=0D
<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/2164#pullrequestreview-184895292">view it on GitHub</=
a>, or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq=
1jcnB0GbXetEu68eFjQTOpIR59uks5u4tiYgaJpZM4ZShYl">mute the thread</a>.<img=
 src=3D"https://github.com/notifications/beacon/AWbkq4E9k1Eb--nV3yihal4Xx=
gx4vJrDks5u4tiYgaJpZM4ZShYl.gif" height=3D"1" width=3D"1" alt=3D"" /></p>=
=0D
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
mikkelfj commented on #2164"}],"action":{"name":"View Pull Request","url"=
:"https://github.com/quicwg/base-drafts/pull/2164#pullrequestreview-18489=
5292"}}}</script>=0D
<script type=3D"application/ld+json">[=0D
{=0D
"@context": "http://schema.org",=0D
"@type": "EmailMessage",=0D
"potentialAction": {=0D
"@type": "ViewAction",=0D
"target": "https://github.com/quicwg/base-drafts/pull/2164#pullrequestrev=
iew-184895292",=0D
"url": "https://github.com/quicwg/base-drafts/pull/2164#pullrequestreview=
-184895292",=0D
"name": "View Pull Request"=0D
},=0D
"description": "View this Pull Request on GitHub",=0D
"publisher": {=0D
"@type": "Organization",=0D
"name": "GitHub",=0D
"url": "https://github.com"=0D
}=0D
}=0D
]</script>=

----==_mimepart_5c12e11832205_c833facfe2d45c01100b--