IETF Logo Mail Archive

Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)

Mike Bishop <notifications@github.com> Wed, 11 December 2019 19:47 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 3017F120052 for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 11:47:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 kby4wchSsygD for <quic-issues@ietfa.amsl.com>; Wed, 11 Dec 2019 11:47:36 -0800 (PST)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC62E120058 for <quic-issues@ietf.org>; Wed, 11 Dec 2019 11:47:36 -0800 (PST)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id E12FA6E01F5 for <quic-issues@ietf.org>; Wed, 11 Dec 2019 11:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576093655; bh=66fNINSwRfLCmcyGbirNUBGK4w7jlul2ue5kGPUY1IQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1KOrft8nWzK5QpA2Peut3FRtfn1Y7+zQqjHqoE2uuv66gAFfObSFYwHbd4ZIny3rm nEOj+5PXYFPmcCJcWkc9k8xvVwLL5frpyV6D6dkM/wL9ulhwYzuUbAczEWTlYKemjE lyQEMpqgdSqxOm9cmhLBOXl9Tl18QTm/JVUJxWGk=
Date: Wed, 11 Dec 2019 11:47:35 -0800
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYPUYPFAFZVHGI45B537Z5FPEVBNHHB72WFIM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3294/564703289@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3294@github.com>
References: <quicwg/base-drafts/issues/3294@github.com>
Subject: Re: [quicwg/base-drafts] Make transport parameter ID and length varint (#3294)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df147d7d281e_50fb3feac78cd95c4572c3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/K-HoalUZ8XGZ0I-bH2Ir4ucnT_0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 11 Dec 2019 19:47:38 -0000

I understood the feedback in Cupertino as being to decouple the questions, not to reject any of them outright.  The PR mixed several changes, and it was hard to discuss the combined PR effectively.

Fundamentally, this seems to be a case of design reflecting a coding pattern.  If your pattern is that the QUIC layer generates a binary structure, hands the opaque blob to TLS and says "this is the payload of extension foo," then it makes total sense to varint everything, because it's part of QUIC.

If your coding pattern is that the transport parameters are a known structure and TLS is handed a key-value store that it knows how to serialize, then it makes total sense to TLSPL everything, because it's part of TLS.

On the whole, the first pattern seems more likely to me, but fundamentally we're shipping a code architecture choice here.

-- 
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/3294#issuecomment-564703289

v2.23.0 | Report a Bug | By Email