John Scudder's No Objection on draft-ietf-quic-datagram-08: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Wed, 02 February 2022 02:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CDF3A1DB3; Tue, 1 Feb 2022 18:47:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-quic-datagram@ietf.org, quic-chairs@ietf.org, quic@ietf.org, lucaspardue.24.7@gmail.com, lucaspardue.24.7@gmail.com
Subject: John Scudder's No Objection on draft-ietf-quic-datagram-08: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <164377006133.14133.15026373492275979222@ietfa.amsl.com>
Date: Tue, 01 Feb 2022 18:47:42 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/_JO2x8OEAguNa9s9FZIcjwuyfMU>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 02 Feb 2022 02:47:42 -0000
John Scudder has entered the following ballot position for draft-ietf-quic-datagram-08: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a rank QUIC neophyte my ability to offer serious technical review of this document is limited at best. However I do have a few questions that (in the best case) might reveal lacunae that experts overlooked but which trip up a neophyte, or (in the worst case) only my own ignorance. 1. In the Motivation section you write, * Applications that open both a reliable TLS stream and an unreliable DTLS flow to the same peer can benefit by sharing a single handshake and authentication context between a reliable QUIC stream and flow of unreliable QUIC datagrams. This can reduce the latency required for handshakes. This threw me off, considering that in the previous section (Introduction) you point to UDP/DTLS as a prior way of providing a similar service. In the quotation above it seems as though you’re using them synonymously… or something. TBH, I just don’t follow what the quoted text is getting at. :-( I do get (in a general way) that QUIC makes use of (parts of?) TLS, but that doesn’t allow me to make sense of it. 2. You’re inconsistent about whether DATAGRAM frames have a type, singular, or types, plural. Plural seems right to me, but read on. In §3, you refer to “the DATAGRAM frame types”, plural. But then in §4 you say that the LSB of “the DATAGRAM frame type” (singular) “is the LEN bit”. Seems to me you should make up your mind: either you have two types, 0x30 and 0x31, whose semantics differ with respect to the Length field, OR you have a single type and a flag. Really I think you have two types (witness the IANA allocation: two, not one) and the characterization of the LSB as a flag is just a distraction, I would remove it. Clearly that doesn’t prevent an implementor from taking advantage of the structure if they want to, but I think it would clean up some awkwardness in the prose. 3. Further to that, in Section 4 you say, The DATAGRAM frame type takes the form 0b0011000X (or the values 0x30 and 0x31). It took me an embarrassingly long time to recognize that the first form you list means “binary 0011000x, where x indicates ‘don’t care’”. I suppose maybe I was slow because we use hex notation all the time in our document set, and binary notation exceedingly seldom in my experience. Possibly I am the only person who will stumble on this. But possibly not. In any case if you were to clean up my “is it one type, or two” complaint by collapsing the waveform to “it’s two”, this problem would also go away. 4. In Section 5 you say, When a QUIC endpoint receives a valid DATAGRAM frame, it SHOULD deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory. Isn’t the final clause in the category of “well, duh”? I mean, is there a situation in which a QUIC endpoint is *not* able to process the frame or *not* able to store the contents in memory, but still might be expected to deliver the data to the application? Seems like that’d be a “no”. I mean, the remark does no real harm, but why bother stating the obvious?
- John Scudder's No Objection on draft-ietf-quic-da… John Scudder via Datatracker
- Re: John Scudder's No Objection on draft-ietf-qui… Zaheduzzaman Sarker
- Re: John Scudder's No Objection on draft-ietf-qui… John Scudder
- Re: John Scudder's No Objection on draft-ietf-qui… Tommy Pauly
- Re: John Scudder's No Objection on draft-ietf-qui… John Scudder