[quicwg/base-drafts] Move/duplicate no server migration text (#4063)

ekr <notifications@github.com> Mon, 31 August 2020 16:27 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 D38393A1759 for <quic-issues@ietfa.amsl.com>; Mon, 31 Aug 2020 09:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 P7_KygTLez5N for <quic-issues@ietfa.amsl.com>; Mon, 31 Aug 2020 09:27:02 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383C93A1754 for <quic-issues@ietf.org>; Mon, 31 Aug 2020 09:27:02 -0700 (PDT)
Received: from github-lowworker-cd7bc13.ac4-iad.github.net (github-lowworker-cd7bc13.ac4-iad.github.net [10.52.25.102]) by smtp.github.com (Postfix) with ESMTP id 83CDB90002C for <quic-issues@ietf.org>; Mon, 31 Aug 2020 09:27:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1598891221; bh=smwp83yYI172m2JqEKpN+nVBUokyZPfpaUoN7Ya1utY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=SsiHBh1lNRsAC7HL8PKcIW4hboszJx0EmH9/G3QM0U+ErWXQkuLgVPeCkHQTka20k jW7Z3dHW+olrlcGgCi1lJgSpPqoyg6LZP5AjNSG5b0vLkP8PfUmcO5q31PYQtqntdu lIo/IHSECJWl51E+GsHC9EjCQGkyogFJ4ZJPVHJ0=
Date: Mon, 31 Aug 2020 09:27:01 -0700
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4I5SZXX3LPUB34AFN5LEC5LEVBNHHCSFTCVQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4063@github.com>
Subject: [quicwg/base-drafts] Move/duplicate no server migration text (#4063)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f4d24d574e47_649319647287f9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/mV4-78gGecRwjJ__m7OaxDfGTT0>
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: Mon, 31 Aug 2020 16:27:04 -0000

9.6 says:

   Migrating a connection to a new server address mid-connection is left
   for future work.  If a client receives packets from a new server
   address not indicated by the preferred_address transport parameter,
   the client SHOULD discard these packets.

However, this is after several sections which describe how connection migration works generically from either side, including this text in 9.3.

  Receiving a packet from a new peer address containing a non-probing
   frame indicates that the peer has migrated to that address.
   In response to such a packet, an endpoint MUST start sending
   subsequent packets to the new peer address and MUST initiate path
   validation (Section 8.2) to verify the peer's ownership of the
   unvalidated address.

Which is confusing and in fact arguably contradictory. I would propose that we add a sentence to the top of 9.3 that explains that while the text is generic, it actually only applies to servers.


-- 
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/4063