RE: Call for Adoption: Invariants
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 08 February 2018 11:10 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6296B126D74 for <quic@ietfa.amsl.com>; Thu, 8 Feb 2018 03:10:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.291
X-Spam-Level:
X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GE4bhLpV6hSF for <quic@ietfa.amsl.com>; Thu, 8 Feb 2018 03:10:48 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D655120727 for <quic@ietf.org>; Thu, 8 Feb 2018 03:10:48 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id t129so2304055ywc.3 for <quic@ietf.org>; Thu, 08 Feb 2018 03:10:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nHUBMdlO+U/xgsioPbwYuYsMT71XfgQYXgu1styfw7s=; b=fQi9GFq1Jnz84S9rAFirA2Q7N6169dBvq5hPb/srhtyt8NDtxJp1HJFts7m47B7m+X r5JC+fhvBIzsLnwFv8sRsuOl59o5erDHTDS5tZ4FQFSuyqsVrNVGKJLDOGDVfQA26PuO kNMaJgYQ0lcpsQIPYguuvVIeJCnJuGiueYALxfSBKSi4VIauFiDVGrhdIrCACZbB+NC4 wYFWmnITDGsikVeHBf8StqBdcMzCvTzgrG/57RWLPOABtFeOVwKbE2BxC7gmKTc6xOKl 1r9aU/emO0fwlyE6v18JXY70ME1qjHmjkIfSy1CBMdspCfniBr4gkWoVkZLrF0CetYXT 6Y6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nHUBMdlO+U/xgsioPbwYuYsMT71XfgQYXgu1styfw7s=; b=pJDbIyMMbvymEv2pEi7ptbEPCBkPTDSX0aqWwz2+amFv/o8gMrRKNXyaVV4XElPEoF Ar5ehis1FuDcwyMQ+QziTfg39q1okCp3uTkgDkDnPUDIDrvloW+BeUwXhRVyMcX6fouR KGFiXPPwVXH2raz69gLqxrMZ1nlYoo/4Btx0EE6z0u0dLwIChJhyiXMiH5XsrcJVTDfb 3XadStCVGNEj7HOoFMajYPYvvPcaOudd5e2lorhCz2Te+NvQ0EPPOc6LR4luUFah46bD r3J2Q1yRnwYbSb56zdGTjdYP2lGLFzPFLguYNP1H58rOIT2gwf+9k4OmqIFhdRjynJ01 uR6Q==
X-Gm-Message-State: APf1xPDbruN67MH+9pIiTKzvGr34ByKloDawt0kMUTXCIapfNXEe196R tlvNMn2fb5ZycXtgVqqMlU39xiteCN9hmAJAzJs=
X-Google-Smtp-Source: AH8x225Mx16gB2QjvbkuyWTqPfj59fNCXiqoPXOQ6k0nUpUbgLdcAzyDsCgT+e1cPql9LicCm8pspq2uxaPIJ9FcDbY=
X-Received: by 10.129.78.14 with SMTP id c14mr161018ywb.109.1518088246945; Thu, 08 Feb 2018 03:10:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.21.201 with HTTP; Thu, 8 Feb 2018 03:10:46 -0800 (PST)
Received: by 10.37.21.201 with HTTP; Thu, 8 Feb 2018 03:10:46 -0800 (PST)
In-Reply-To: <CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0@CY4PR21MB0133.namprd21.prod.outlook.com>
References: <C35C3AB6-F0FC-4D83-9C97-DD0B605A863F@mnot.net> <DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <FDFA0988-1FB4-4AFC-8958-1A6B16068FE5@trammell.ch> <MWHPR08MB2432F1CB1FBAFACD611D3913DAFE0@MWHPR08MB2432.namprd08.prod.outlook.com> <CAKKJt-cJs8Ms62tBjxGTXBZ6GeD0+VgdWzG7zYf8Yui=a4HPvg@mail.gmail.com> <CA+9kkMChFQ3aYBcsdtFOD18CytjhqYE-pWqd6JCUPuD5vwFE6g@mail.gmail.com> <MWHPR08MB2432E39B469653DB35C02D8EDAFD0@MWHPR08MB2432.namprd08.prod.outlook.com> <CAGD1bZZZ4OHtBpEdZ_XqU6g9sa9xSf2xEOpwpBYzEC61PxzDWg@mail.gmail.com> <CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0@CY4PR21MB0133.namprd21.prod.outlook.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Thu, 08 Feb 2018 05:10:46 -0600
Message-ID: <CAKKJt-e6R6DC5yyWnPZD1n5bR9aTvBbBSh-L6VudJ=GLkH31fA@mail.gmail.com>
Subject: RE: Call for Adoption: Invariants
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Jana Iyengar <jri@google.com>, Mike Bishop <mbishop@evequefou.be>, Ted Hardie <ted.ietf@gmail.com>, Mark Nottingham <mnot@mnot.net>, Lars Eggert <lars@eggert.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d7d3eb26ed90564b17665"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/L3fpHZ8YTmoaDocnltqkWB8xYiI>
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: Thu, 08 Feb 2018 11:10:50 -0000
Still with no hat ... On Feb 6, 2018 14:48, "Praveen Balasubramanian" <pravb@microsoft.com> wrote: +1 on “The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.” Thanks to multiple people who have replied. I understand that QUIC isn't tied to a single UDP port number. I was thinking about the deployability story for a non-backward-compatible QUIC version that can't be demuxed from previous versions - what I think I'm hearing is that such a new QUIC version would require thought about getting a new UDP port opened the way 443 seems to be today. I'll shut up and let you guys do QUIC now :-) Spencer *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar *Sent:* Tuesday, February 6, 2018 11:26 AM *To:* Mike Bishop <mbishop@evequefou.be> *Cc:* Ted Hardie <ted.ietf@gmail.com>; Mark Nottingham <mnot@mnot.net>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Lars Eggert < lars@eggert.org>; Brian Trammell (IETF) <ietf@trammell.ch>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org> *Subject:* Re: Call for Adoption: Invariants What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not required for HTTP/QUIC. The HTTP mapping document currently says (in Section 2.1 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fquicwg.github.io%2Fbase-drafts%2Fdraft-ietf-quic-http.html%23rfc.section.2.1&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805671598&sdata=%2B0h%2B1meATs8rcF%2F66Tb%2BvxshTFFULLfwqwoHxuy6Cb0%3D&reserved=0>) "Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but let's move that discussion to where it belongs, on #495 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F495&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=ams4Bh5t3rldzh4uok6YJvGlnx8o0R7ELAogQ8iIK54%3D&reserved=0> . The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port. On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <mbishop@evequefou.be> wrote: Two notes, one against interest: That PR is old and currently parked, because we don’t have consensus and it’s less urgent. And secondly, UDP/443 is already allocated by IANA for HTTP over UDP. *From:* Ted Hardie [mailto:ted.ietf@gmail.com] *Sent:* Tuesday, February 6, 2018 10:57 AM *To:* Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> *Cc:* Mike Bishop <mbishop@evequefou.be>; Brian Trammell (IETF) < ietf@trammell.ch>; Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>; QUIC WG < quic@ietf.org>; Mark Nottingham <mnot@mnot.net>; Lars Eggert < lars@eggert.org> *Subject:* Re: Call for Adoption: Invariants On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: Asking with no hat, but ... On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <mbishop@evequefou.be> wrote: I support adoption. The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC. If it happens to be startlingly similar, all well and good. If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443? Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/ base-drafts/pull/348 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F348&data=02%7C01%7Cpravb%40microsoft.com%7C18885d6ec0154037503208d56d977dae%7Cee3303d7fb734b0c8589bcd847f1c277%7C1%7C0%7C636535419805681132&sdata=wTDG5fmupXJRRSFroNyBRpcbuwjQzz5fXs%2B41F6DheA%3D&reserved=0>) defines UDP 443 as the default for httpq. I think that pretty much asserts that UDP/443 is QUIC, not a forked variant. I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question. Yes. That may cause us to consider carefully whether UDP/443 ought to be defined for QUIC more rather than HTTP over QUIC, or even more generally. Ted Thanks, Spencer
- Call for Adoption: Invariants Mark Nottingham
- Re: Call for Adoption: Invariants Mikkel Fahnøe Jørgensen
- Re: Call for Adoption: Invariants Brian Trammell (IETF)
- Re: Call for Adoption: Invariants Ian Swett
- Re: Call for Adoption: Invariants Christian Huitema
- RE: Call for Adoption: Invariants Mike Bishop
- Re: Call for Adoption: Invariants Roberto Peon
- Re: Call for Adoption: Invariants Mikkel Fahnøe Jørgensen
- Re: Call for Adoption: Invariants Jana Iyengar
- RE: Call for Adoption: Invariants Lubashev, Igor
- RE: Call for Adoption: Invariants Praveen Balasubramanian
- Re: Call for Adoption: Invariants Eric Kinnear
- Re: Call for Adoption: Invariants Spencer Dawkins at IETF
- Re: Call for Adoption: Invariants joel jaeggli
- RE: Call for Adoption: Invariants Mike Bishop
- Re: Call for Adoption: Invariants Ted Hardie
- RE: Call for Adoption: Invariants Mike Bishop
- Re: Call for Adoption: Invariants Jana Iyengar
- RE: Call for Adoption: Invariants Praveen Balasubramanian
- RE: Call for Adoption: Invariants Spencer Dawkins at IETF
- Re: Call for Adoption: Invariants Eggert, Lars