Re: Éric Vyncke's No Objection on draft-ietf-quic-transport-33: (with COMMENT)
Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 06 January 2021 04:00 UTC
Return-Path: <lucaspardue.24.7@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE20D3A0BEB; Tue, 5 Jan 2021 20:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7_x_g7H2fXZO; Tue, 5 Jan 2021 20:00:36 -0800 (PST)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3A1F3A0BEE; Tue, 5 Jan 2021 20:00:35 -0800 (PST)
Received: by mail-ed1-x52c.google.com with SMTP id y24so3095996edt.10; Tue, 05 Jan 2021 20:00:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZvLtUjUUhOL1k6J+T+F1ziTXW8X4NThOrQ+dbS4tmk=; b=vfeLvSzJAS20VFphu964+yNqeBWB63teZE+2wJBLD5nYZavH4478WcGEveNfYvXmA2 TezKyQselCSpPYMkeEBLK6YYylEDBkgL4rkbdXLRner2QlqO3p0TswETXadeSeB9OHG3 udOGdFT1ssTJBPVjzLznsxUp4pwdNAw0frCaPmWFX4mzYcCffbyKhgwwUKVctSkBAFAm gGaHx06JqXCBiY7NiRQb54fYWdE5fMhX8CKhcaSyB1nCeuuw1FyCz/K1vaazyy87+8EQ M+jnMHFuKtdwsGs7drQI5I3kJjchyA1s6gOyEAx/uf4Px/6tVlEQ/JUUlZhxmVDPXn+3 khGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZvLtUjUUhOL1k6J+T+F1ziTXW8X4NThOrQ+dbS4tmk=; b=dr8XSTZ9fEocBTynI16Guk37PADoHT5xf70ak6TvFu3mQOqQMhLIaMLMYa7iV9JSA9 SKuAyWuOLqLdYcDvmItViAWWvJ7//pcOP8FdNjJEuBl3KlheV6a+QOBKLOLyaUnd1smM YhMYlJ9ruLL0TFSscomDgGKQxQ2O9NQOO5u6HZksAhDDEcoibm6r6xzo2QcHCuBjZtbC tWHGGHtbv37VwM1R/YOFov3ngbNcBTpGImoGS8bm0i3pPIlj5AXkcPH7zvc6gErasw5q rGrH64hnZztEdp9O/RPZZ6Yjzfj/i3OMAFlwTEU/oM1DKQUCdi/ZPjzbQKULJcVhPERH TqqQ==
X-Gm-Message-State: AOAM533fMZS3168QG5lDt9hHj1aMsKToQIA74hbVcLc/az0ZPNteg/TA mbNWw8gLhGQ4UU9EtVuBj9tDSHSKtQu7DrE8qStls1vFImjzJw==
X-Google-Smtp-Source: ABdhPJx9IZxYGIPWcPX1895sXtagY6JaxynSzyRs194vhhBOD0ik/Jx2xgHQxT0zToryeolu9sAwPYUHXteVMZhPFxk=
X-Received: by 2002:aa7:dcd0:: with SMTP id w16mr2620914edu.229.1609905634572; Tue, 05 Jan 2021 20:00:34 -0800 (PST)
MIME-Version: 1.0
References: <160984514294.16831.9541196598331741661@ietfa.amsl.com>
In-Reply-To: <160984514294.16831.9541196598331741661@ietfa.amsl.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 06 Jan 2021 04:00:23 +0000
Message-ID: <CALGR9obsCX9t9WV=Z0MxT072nB2vpGp4G+gjJCkf-QQ=A5NUYw@mail.gmail.com>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-quic-transport-33: (with COMMENT)
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-quic-transport@ietf.org, WG Chairs <quic-chairs@ietf.org>, QUIC WG <quic@ietf.org>, Lars Eggert <lars@eggert.org>, volz@cisco.com
Content-Type: multipart/alternative; boundary="000000000000787c9205b8335d02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2PRwCVGon0r3aaKEhx2wHJRpYOw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2021 04:00:39 -0000
Hi Éric, Thanks for the review. I've captured your comments as issues on the QUIC WG GItHub repository. Links to each are provided as in-line responses. I apologize for spelling your name with a 'k' not a 'c'. I've realized this only at the end of the issue-making process. I was so focused on getting the accent correct I missed that part. I'll get this fixed up soon. On Tue, Jan 5, 2021 at 11:12 AM Éric Vyncke via Datatracker < noreply@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-quic-transport-33: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this long but easy to read document. It is > clearly a major change for the Internet. > > Special thanks to Bernie Volz for his internet directorate review. > > I support Erik Kline's comments about sections 9.6.3 (interaction of NAT64 > and > preferred address) and 14.1 (IPv6 extension headers). > > Please bear with some comments from a non-transport oriented person... I > have > yet to review QUIC-RECOVERY so I will assume for now that packet loss by > the > network (such as RED) will also reduce the "QUIC congestion window". > > NB: I still wonder why QUIC is in upper case if it is a name and not an > acronym > ;-) > > Please find below some non-blocking COMMENT points (but replies would be > appreciated), and some nits. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > -- Section 1 -- > "QUIC packets are carried in UDP datagrams ([UDP]) to better facilitate > deployment in existing systems and networks.", this is an assumption > presented > as a fact without citing any reference... This does not seem too good to > me. > https://github.com/quicwg/base-drafts/issues/4524 > -- Section 2.2 -- > "an endpoint MAY treat receipt of different data at > the same offset within a stream as a connection error of type > PROTOCOL_VIOLATION." > > Should it be a SHOULD or even a MUST rather than a MAY ? Even if streams > are > protected, isn't it a security issue to allow overwrite of a stream ? Esp > when > the endpoints could deliver out-of-order to the application ? > https://github.com/quicwg/base-drafts/issues/4525 > -- Section 3.1 (and others) -- > It would have been nice to use the SVG alternate graphic format for such an > fundamental document ;-) > https://github.com/quicwg/base-drafts/issues/4526 > -- Section 4.2 and others -- > The specification is rather vague about the behavior (no default timer, no > default "window", nothing said about increasing the credit, ...) and > leaves a > lot to implantations. Is it an issue or is it described in QUIC-RECOVERY ? > https://github.com/quicwg/base-drafts/issues/4527 > -- Section 5.1 -- > It would be nice for the reader to explain the rationale for having > multiple > connection IDs for the same connection. > https://github.com/quicwg/base-drafts/issues/4528 > -- Section 7 -- > Please state before that QUIC version 0x00000001 is the version specified > by > the document or use "This version of QUIC" rather than "Version 0x00000001 > of > QUIC" > > https://github.com/quicwg/base-drafts/issues/4529 -- Section 8.1 -- > Out of curiosity, why selecting a UDP payload of at least 1200 octets? I > would > assume that 1232 would have worked as well (1280 IPv6 MTU - 40 IPv6 header > - 8 > UDP header). Of course, 1200 is a nicer number ;-) > https://github.com/quicwg/base-drafts/issues/4530 > -- Section 9 (and also 9.4 and possibly others) -- > Please also consider adding another reason for an endpoint to change its > IPv6 > address due to RFC 4941 ("privacy extensions for IPv6 addresses") and not > only > NAT ;-) > https://github.com/quicwg/base-drafts/issues/4531 > -- Section 9.1 -- > Can this mechanism also be used not only when changing of IP address but > also > of IP version ? > > Did the QUIC WG/authors consider using happy eyeball (RFC 8305) to probe > whether IPvfoo could become better than IPvbar regularly during a QUIC > connection (using the preferred addresses) ? > https://github.com/quicwg/base-drafts/issues/4532 > -- Section 9.7 -- > Why a SHOULD for the use of a hash, IMHO a good pseudo-random number would > also > work (as explained in RFC 6437). > https://github.com/quicwg/base-drafts/issues/4533 > -- Section 13 -- > Should the text provide a forward reference to section 14 (datagram size) ? > https://github.com/quicwg/base-drafts/issues/4534 > -- Section 14.1 -- > This padding on the initial packets is quite a smart technique ;-) > https://github.com/quicwg/base-drafts/issues/4535 > -- Section 17.2.1 -- > I find a little weird that the "unused" field have a SHOULD setting for the > MSB... Suggest to keep the F bit apart and use a 6-bit "unused" field. > https://github.com/quicwg/base-drafts/issues/4536 > -- Section 18.2 -- > I am not a transport expert, so, I can be wrong but usually, rather than > using > "::.0", "[::]:0" is used. > https://github.com/quicwg/base-drafts/issues/4537 > -- Section 19.2 -- > Suggest to also mention "keeping NAT binding states alive" as a use case > for > PING. > https://github.com/quicwg/base-drafts/issues/4538 > == NITS == > > -- Section 1 -- > In "QUIC authenticates all packets and encrypts as much as is practical." > it is > a little unclear to me whether the 'as much' applies only to 'encrypts' or > also > on 'authenticates'. Or is it clear for an English-native speaker (that I am > not). > https://github.com/quicwg/base-drafts/issues/4539 > -- Section 1.3 -- > Rather than using "described by ?" why not using the letter 'l' (as in > length) > rather than a '?'. It is confusing at first sight. > https://github.com/quicwg/base-drafts/issues/4540 > -- Section 4.5 -- > "the final size is the number of bytes sent" is slightly ambiguous as it > could > either be the number of bytes sent by the application or sent as UDP > payload. > The rest of the paragraph kind of answers the question though. > https://github.com/quicwg/base-drafts/issues/4541 > -- Section 5.2.2 -- > "If a server receives a packet that indicates an unsupported version but is > large enough to initiate a new connection" it is unclear what is the > subject of > "is"... > https://github.com/quicwg/base-drafts/issues/4542 > -- Section 6.3 -- > The use of "0x?a?a?a?a" with undefined syntax brings only question marks > in the > reader's mind => suggest to remove "0x?a?a?a?a" but keep the forward > pointer to > section 15. > https://github.com/quicwg/base-drafts/issues/4543 > -- Section 8.2 -- > Why using "two-tuple" rather than the simpler "pair" ? > https://github.com/quicwg/base-drafts/issues/4544 > -- Section 23.1 -- > Why using the anchor [IPv4] rather than [RFC791] ? Just curious... > https://github.com/quicwg/base-drafts/issues/4545 Cheers, Lucas On behalf of QUIC WG Chairs
- Éric Vyncke's No Objection on draft-ietf-quic-tra… Éric Vyncke via Datatracker
- Re: Éric Vyncke's No Objection on draft-ietf-quic… Lucas Pardue