[quicwg/base-drafts] conflicting advice how to handle Retire Prior To (#3195)

Marten Seemann <notifications@github.com> Wed, 06 November 2019 10: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 []) by ietfa.amsl.com (Postfix) with ESMTP id 66BC81200C7 for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 02:47:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0ksdRSTRrry5 for <quic-issues@ietfa.amsl.com>; Wed, 6 Nov 2019 02:47:54 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B53B1200B5 for <quic-issues@ietf.org>; Wed, 6 Nov 2019 02:47:54 -0800 (PST)
Received: from github-lowworker-19d82f6.ac4-iad.github.net (github-lowworker-19d82f6.ac4-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 833CA8C0928 for <quic-issues@ietf.org>; Wed, 6 Nov 2019 02:47:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573037273; bh=LP60vkcx490crBJePSV3isPJNCt6B2/xTX/lPbex53A=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=n0LI5dc17pjJJDy3aYB5NWxQvK23oUSQtOs19hMoObkhFKJY7pE/AGWga4xRUG+37 9hLLTQ3RbfSexNLHWNQS1isMLATeRh9VW3orbLaGMpWiE0+xP9spUrXKSXnLkC5wc4 LsGjj+8imuEtNh1B903zT7l9qIamFHd5h7jKGopg=
Date: Wed, 06 Nov 2019 02:47:53 -0800
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZERTZN4HFVYDPADSV3Z7LVTEVBNHHB5ZQDTM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3195@github.com>
Subject: [quicwg/base-drafts] conflicting advice how to handle Retire Prior To (#3195)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc2a4d974ce0_30053fd00d6cd960829fd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/le9dzjmDiB5c7kUbyp75ztw4M34>
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, 06 Nov 2019 10:47:56 -0000

In the section talking about Connection IDs (section 5.1.2) it says:
> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.

In the description of the NEW_CONNECTION_ID frame (section 19.15) it says:
> The Retire Prior To field is a request for the peer to retire all connection IDs with a sequence number less than the specified value. [...] The peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.

So it's not clear if you just SHOULD or if you MUST send the RETIRE_CONNECTION_ID frame.

As an editorial remark, I find the existing text a bit hard to understand, since it's spread over these two sections. Maybe it would be easier to keep the frame description relatively short, and move more of the logic into the section that describes how CIDs are used and retired. 

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: