Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D810130E18 for ; Tue, 4 Dec 2018 16:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.46 X-Spam-Level: X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMa61Kp6s1kS for ; Tue, 4 Dec 2018 16:55:58 -0800 (PST) Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA8B130DC2 for ; Tue, 4 Dec 2018 16:55:58 -0800 (PST) Date: Tue, 04 Dec 2018 16:55:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543971357; bh=CFlZyVtNSmVNTTbGljXboALnvOJJMAHECJlF3VCCWs8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=T858u64n1J2POP2QZV3FVodVsnNwr7ImqH0F81Ct+7CGzJ9LKbpFHUSzpam1iuHQM B532px7BE3DBuWOSLOnkHQ4d1odP2mxdYHpLCJkPEYaVgtKHmXrT2moOe9frF5it03 Rp0t6J1p749NqETlcMVtY7JmLvZes2kFQx+T9zUg= From: janaiyengar Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] First tranche of EKR's editorial pass, through 7.3.2 (#2087) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5c07221dd3a9f_2d653fbc6a4d45c01058ba"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: janaiyengar X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org X-Mailman-Version: 2.1.29 List-Id: Notification list for GitHub issues related to the QUIC WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 00:56:00 -0000 ----==_mimepart_5c07221dd3a9f_2d653fbc6a4d45c01058ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit janaiyengar commented on this pull request. > operating systems and middleboxes. QUIC authenticates all of its headers and -encrypts most of the data it exchanges, including its signaling, to avoid +encrypts most of the data it exchanges -- including its signaling -- to avoid We're using hyphens instead of em-dashes... I used to write em-dashes, but @martinthomson normalized it all to hyphens, so he'll have to explain :-) That said, I think commas seem more appropriate here. Ultimately, I suspect the RFC-Editor will want to say something here. > @@ -383,7 +383,7 @@ data to a peer. ~~~ o | Create Stream (Sending) - | Create Bidirectional Stream (Receiving) + | Remote Creates Bidirectional Stream Change the text below as well, for transition from Ready to Send > that sends a STOP_SENDING frame can ignore the error code carried in any RESET_STREAM frame it receives. If the STOP_SENDING frame is received on a send stream that is already in the -"Data Sent" state, a RESET_STREAM frame MAY still be sent in order to cancel -retransmissions of previously-sent STREAM frames. +"Data Sent" state, an endpoint which wishes to cease retransmission of ```suggestion "Data Sent" state, an endpoint that wishes to cease retransmission of ``` > connection to be delivered to the wrong endpoint. Each endpoint selects connection IDs using an implementation-specific (and perhaps deployment-specific) method which will allow packets with that connection ID to be routed back to the endpoint and identified by the endpoint upon receipt. -Connection IDs MUST NOT contain any information that can be used to correlate +Connection IDs MUST NOT contain any information that can be used by to correlate ```suggestion Connection IDs MUST NOT contain any information that can be used by an external observer to correlate ``` > @@ -1337,7 +1339,8 @@ Source Connection IDs during the handshake. On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the Destination Connection ID for subsequent packets. That means that a client might change the Destination -Connection ID twice during connection establishment. Once a client has received +Connection ID twice during connection establishment, once in response to a +Retry and once in response to the server's Initial. Once a client has received ```suggestion Retry and once in response to the server's Initial packet. Once a client has received ``` > @@ -1377,7 +1380,8 @@ of duplicate transport parameters as a connection error of type TRANSPORT_PARAMETER_ERROR. A server MUST include the original_connection_id transport parameter -({{transport-parameter-definitions}}) if it sent a Retry packet. +({{transport-parameter-definitions}}) if it sent a Retry packet, in +order to enable validation of the Retry, as described in {{packet-retry}}. remove "in order" -- 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/2087#pullrequestreview-181546052 ----==_mimepart_5c07221dd3a9f_2d653fbc6a4d45c01058ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

@janaiyengar commented on this pull request.

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
>  operating systems and middleboxes.  QUIC =
authenticates all of its headers and=0D
-encrypts most of the data it exchanges, including its signaling, to avoi=
d=0D
+encrypts most of the data it exchanges -- including its signaling -- to =
avoid=0D
=0D

We're using hyphens instead of em-dashes... I used to write em-dashes,= but @martinthomson normalized it all to hyphens, so he'll = have to explain :-)

=0D

That said, I think commas seem more appropriate here. Ultimately, I su= spect the RFC-Editor will want to say something here.

=0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -383,7 +383,7 @@ data to a peer.=0D
 ~~~=0D
        o=0D
        | Create Stream (Sending)=0D
-       | Create Bidirectional Stream (Receiving)=0D
+       | Remote Creates Bidirectional Stream=0D
=0D

Change the text below as well, for transition from Ready to Send

=0D= =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
>  that sends a STOP_SENDING frame can ignor=
e the error code carried in any=0D
 RESET_STREAM frame it receives.=0D
 =0D
 If the STOP_SENDING frame is received on a send stream that is already i=
n the=0D
-"Data Sent" state, a RESET_STREAM frame MAY still be sent in o=
rder to cancel=0D
-retransmissions of previously-sent STREAM frames.=0D
+"Data Sent" state, an endpoint which wishes to cease retransmi=
ssion of=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-"Data Sent" state, an endpoint which wishes t=
o cease retransmission of=0D
+"Data Sent" state, an endpoint that wishes to cease retransmission of=0D=
=0D =0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
>  connection to be delivered to the wrong e=
ndpoint.  Each endpoint selects=0D
 connection IDs using an implementation-specific (and perhaps=0D
 deployment-specific) method which will allow packets with that connectio=
n ID to=0D
 be routed back to the endpoint and identified by the endpoint upon recei=
pt.=0D
 =0D
-Connection IDs MUST NOT contain any information that can be used to corr=
elate=0D
+Connection IDs MUST NOT contain any information that can be used by to c=
orrelate=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-Connection IDs MUST NOT contain any informati=
on that can be used by to correlate=0D
+Connection IDs MUST NOT contain any information that can be used by an e=
xternal observer to correlate=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -1337,7 +1339,8 @@ Source Connection ID=
s during the handshake.=0D
 On first receiving an Initial or Retry packet from the server, the clien=
t uses=0D
 the Source Connection ID supplied by the server as the Destination Conne=
ction ID=0D
 for subsequent packets.  That means that a client might change the Desti=
nation=0D
-Connection ID twice during connection establishment.  Once a client has =
received=0D
+Connection ID twice during connection establishment, once in response to=
 a=0D
+Retry and once in response to the server's Initial. Once a client ha=
s received=0D
=0D =E2=AC=87=EF=B8=8F Suggested change=0D 
-Retry and once in response to the server's In=
itial. Once a client has received=0D
+Retry and once in response to the server's Initial packet. Once a client=
 has received=0D
=0D =0D =0D
=0D =0D

In draft-ietf-quic-transport.md:

=0D 
> @@ -1377,7 +1380,8 @@ of duplicate transpo=
rt parameters as a connection error of type=0D
 TRANSPORT_PARAMETER_ERROR.=0D
 =0D
 A server MUST include the original_connection_id transport parameter=0D
-({{transport-parameter-definitions}}) if it sent a Retry packet.=0D
+({{transport-parameter-definitions}}) if it sent a Retry packet, in=0D
+order to enable validation of the Retry, as described in {{packet-retry}=
}.=0D
=0D

remove "in order"

=0D =0D

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on GitHub, or mute the thread.

= =0D =0D = ----==_mimepart_5c07221dd3a9f_2d653fbc6a4d45c01058ba--