IETF Logo Mail Archive

Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

Kazuho Oku <notifications@github.com> Fri, 26 October 2018 01:11 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 7D53B130E08 for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 18:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 LzmA4eUvM-sD for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 18:11:33 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794431294D7 for <quic-issues@ietf.org>; Thu, 25 Oct 2018 18:11:33 -0700 (PDT)
Date: Thu, 25 Oct 2018 18:11:32 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540516292; bh=Wqplc/vkX16d8rSiCpXqUaPpx5EeqfHTjbqDm67+yq8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IWGJ+WepyiIF+FgsLvhxOkFHxP+t/1S24vo/W99q35JqfZnQP2xtfbZz3Grf2/4M4 ih9LMp+PhdAHR5bzlPG2ClVk+QEK785TtTH8VplBVTBNRhdUdzFuTbMa1TeA0+/z28 5fKmtN3bKOefxnK4o4TS5JpMXeIb24kOQspC4Dmc=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5592f9b4d66d47c6c2a2b76c1696baa34a3ab24692cf0000000117ea2bc492a169ce1640b1a8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1901/c433254302@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1901@github.com>
References: <quicwg/base-drafts/pull/1901@github.com>
Subject: Re: [quicwg/base-drafts] Compatible version upgrade (#1901)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bd269c47432e_75fd3f915c6d45c01074e0"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/dSgnfaNF7bpSCULHGkKKmPm0fyU>
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: Fri, 26 Oct 2018 01:11:35 -0000

@martinthomson:
> Relying on grouping might work, but it's probably more complicated than necessary. Maybe something simpler again. Two lists:
> (snip)

Exactly. I agree that using two lists is the most intuitive way to send two groups of versions.

Two minor things that we might want to clarify:
* Does the version number included in the packet header need to appear in supported_versions? If we are to allow omitting it we should be clear about that.
* Is the server allowed to perform a compatible version upgrade against a version included in unsupported_versions? This could happen during the upgrade process of a server cluster. My slight preference goes to allowing that, because that simplifies the design by making the server the sole entity that detects version downgrade. But people might have different opinions.

-- 
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/1901#issuecomment-433254302

v2.23.0 | Report a Bug | By Email