Re: [quicwg/base-drafts] Restructure document (#411)
mirjak <notifications@github.com> Thu, 16 August 2018 16:07 UTC
Return-Path: <noreply@github.com>
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 579C0130DD5 for <quic-issues@ietfa.amsl.com>; Thu, 16 Aug 2018 09:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 g6e6WcxZRfwm for <quic-issues@ietfa.amsl.com>; Thu, 16 Aug 2018 09:07:31 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063B0130DCD for <quic-issues@ietf.org>; Thu, 16 Aug 2018 09:07:30 -0700 (PDT)
Date: Thu, 16 Aug 2018 09:07:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1534435650; bh=3qfZKBZjbqlNIyEZ39lXA4d3B+WlfYyhWFtI+nMjZLs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=12Hm+Wr6hqGzzh3AOK5LoW2UH14H9rwhOpumN/ypmLvCqWSa65nVcrTxggNL09cKa U/o0jXiDB3RUh7MTh9ybXoR6a7MZ1poN3iRypfZGf0G8rD7OcjxgUqEH+epn63R7XT ky5U+BhdAQEW9iVSXN+H5TfwHnMv0s/DgNRO/aAg=
From: mirjak <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab136dd7832f32c79bfd10d20370c46cdabb8cdabb92cf00000001178d634292a169ce0cd5d91f@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/411/413598713@github.com>
In-Reply-To: <quicwg/base-drafts/issues/411@github.com>
References: <quicwg/base-drafts/issues/411@github.com>
Subject: Re: [quicwg/base-drafts] Restructure document (#411)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b75a14237a9_15603f84a3ad45b4627078"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mirjak
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/VjVsgI2sLj5XZqnfAuS_OeOW4CY>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 16:07:33 -0000
I did a fully review of transport-14 and can confirm that the current organization is not super great as a lot of concepts you need to understand the details are explained too late in the doc. Also I noticed that the QUIC overview section was removed on -11. I agree that the text in that section was not great but I think it would help a reader, who is not familar with quic, a lot to have a (non-normative) section first explaining the main concepts (multiplexing/streams/frames, how encryption works/session resumption, reliability/packet numbers, maybe also flow control, migration, and versioning). Here are a bunch of micro re-org suggestions based on -14 (however I agree with the general stuture @martinthomson prposes above which at minimim would mean to move section 8 much earlier in the doc): - section 5 (Frames and Frame Type) should be merged with section 7 (Frame Types and Format): I guess the intention was to provide the reader a full list with all frame types early on. That was actually rather confusing than helpful. I think it is okay to just provide a reference to the respective section later in the doc whenever a frame type is mention that was not introduced yet. - I would recommend to merge the text in section 6.6.3 (New Transports Paramters) just in the intro text of section 6.6. (Transport Paramter) - Section 6.7 (Stateless Retry) needs to show up earlier in section 6 because it is mentioned in previous subsections. - Most text in the intro part of section 6.9 (Proof of Source Address Validation) sounds like it should rather be in the security considerations section... - Section 6.11.5 (Privacy Implications of Connection Migration) really seems to belong in the secuirty considerations instead. - I would recommend to have section 6.12.4.2 (Calculating a Stateless Rest Token) before section 6.13.4.1 (Detecting a Stateless Reset). - Depending on the final order I think there is some text in section 9 that belongs in section 7.20. I think in any case section 7.20 should also talk about the meaning of the last two bits. I would recommend to talk about the bit encoding only in section 7.20 and just introduce the concepts of bi/uni-direction and server/client-initiated in section 9. - I would recommend to have the section on sending and receiving data (9.5) before the state diagrams are introduced. - Order of section 10 (Flow Control) seemed completely random to me. Also not quite an issue on document structure directly, but definitely related and should probably be cleaned up together, is that there are a couple of duplicted normative statements, e.g. sec 7.8. (MAX_STREAM_ID Frame) "Loss or reordering can mean that a MAX_STREAM_ID frame can be received which states a lower stream limit than the client has previously received. MAX_STREAM_ID frames which do not increase the maximum stream ID MUST be ignored." sec 9.4 (Stream Concurrency) "A receiver cannot renege on an advertisement; that is, once a receiver advertises a stream ID via a MAX_STREAM_ID frame, advertising a smaller maximum ID has no effect. A sender MUST ignore any MAX_STREAM_ID frame that does not increase the maximum stream ID." sec 10 (Flow Control) "A receiver MAY advertise a larger offset at any point by sending MAX_DATA or MAX_STREAM_DATA frames. A receiver cannot renege on an advertisement; that is, once a receiver advertises an offset, advertising a smaller offset has no effect. A sender MUST therefore ignore any MAX_DATA or MAX_STREAM_DATA frames that do not increase flow control limits." These normative statements do all say the same thing but are worded slightly different. To avoid any ambiguity, I would recommend to state these things normatively only once. There are a few more of these kind of cases... -- 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/issues/411#issuecomment-413598713
- Re: [quicwg/base-drafts] Restructure document (#4… Martin Thomson
- [quicwg/base-drafts] Restructure document (#411) Martin Thomson
- Re: [quicwg/base-drafts] Restructure document (#4… mirjak
- Re: [quicwg/base-drafts] Restructure document (#4… Martin Thomson
- Re: [quicwg/base-drafts] Restructure document (#4… Martin Thomson
- Re: [quicwg/base-drafts] Restructure document (#4… ianswett
- Re: [quicwg/base-drafts] Restructure document (#4… mirjak
- Re: [quicwg/base-drafts] Restructure document (#4… Brian Trammell
- Re: [quicwg/base-drafts] Restructure document (#4… Martin Thomson
- Re: [quicwg/base-drafts] Restructure document (#4… Martin Thomson