2 Points of First Implementation Draft we might clarify

Patrick McManus <pmcmanus@mozilla.com> Wed, 28 June 2017 20:51 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6971D12EAFB for <quic@ietfa.amsl.com>; Wed, 28 Jun 2017 13:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.735
X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CfHZoKOIBWaR for <quic@ietfa.amsl.com>; Wed, 28 Jun 2017 13:51:13 -0700 (PDT)
Received: from linode64.ducksong.com (www.ducksong.com []) by ietfa.amsl.com (Postfix) with ESMTP id BCDB21270AC for <quic@ietf.org>; Wed, 28 Jun 2017 13:51:13 -0700 (PDT)
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com []) by linode64.ducksong.com (Postfix) with ESMTPSA id 6134F3A019 for <quic@ietf.org>; Wed, 28 Jun 2017 16:51:11 -0400 (EDT)
Received: by mail-qt0-f181.google.com with SMTP id f92so59615077qtb.2 for <quic@ietf.org>; Wed, 28 Jun 2017 13:51:11 -0700 (PDT)
X-Gm-Message-State: AKS2vOzSFuDHzzpxIttxxOoE9bNxyHHDkCT9dM7IxyMbIiVaaeGvJ9qQ vT4Aea29+YdKLzij9S2I5LfPzrMCWw==
X-Received: by with SMTP id i25mr15917037qtf.239.1498683071124; Wed, 28 Jun 2017 13:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 28 Jun 2017 13:51:10 -0700 (PDT)
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 28 Jun 2017 13:51:10 -0700
X-Gmail-Original-Message-ID: <CAOdDvNreiyrk1bpGc5Cu0OXyO1KDGk25USYM7jz5GpXQCdUpfQ@mail.gmail.com>
Message-ID: <CAOdDvNreiyrk1bpGc5Cu0OXyO1KDGk25USYM7jz5GpXQCdUpfQ@mail.gmail.com>
Subject: 2 Points of First Implementation Draft we might clarify
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113b859a15dbe605530b5837"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IYKKbp0eXRV_6XvIDZkLwuBhNcg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 28 Jun 2017 20:51:15 -0000

Hi All - First, its really amazing to see nascent quic implementations
emerging from primordial soup over the last couple of weeks. I can count at
least 5 that have been mentioned on email, chat, or twitter trying to do
real interop. Its all a giant morass of work in progress of course - but
this is exciting and I take it as a very good sign.

A couple things have come up

1] The implementation milestone wiki should probably specific a draft
version of TLS 1.3. Both -18 and -20 have been in common use (depending on
what TLS library you are using) and this leads to a common interop failure.
Presumably this isn't a problem we will have with the second milestone when
the TLS WG will have settled on a final revision. I would argue for -20
simply because its a later marker on the march of forward progress.

2] the text on connection_close doesn't indicate which peer does the close,
or really when. If we want to do un-attended endpoint testing it might be a
useful thing to profile. e.g. "the server sends connection close on a timer
2 seconds after the handshake is complete".. or something.