Re: Making QUIC less constraining for innovation
Jana Iyengar <jri.ietf@gmail.com> Thu, 24 October 2019 06:25 UTC
Return-Path: <jri.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 CD199120178 for <quic@ietfa.amsl.com>; Wed, 23 Oct 2019 23:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 gBtbEVQx-Xk7 for <quic@ietfa.amsl.com>; Wed, 23 Oct 2019 23:25:19 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 9886D12000F for <quic@ietf.org>; Wed, 23 Oct 2019 23:25:18 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id l21so23680040lje.4 for <quic@ietf.org>; Wed, 23 Oct 2019 23:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NfDmQOjaV2r0IRdBXAdXo9i2GwuVq0AsfbM/wcnW8LU=; b=ufElsWQ/QLkgqGiFGS0YpfPQkRHTK/W7+DMfeUbI+iFsX6l9dCNj1ruEbXxuKkxhEO vWrtrGNfv/XPVv5B4KlZwxM863kZY1rW9GkgXiFfPmAxieD/L35vsds2ZNI0Aqzs+4Fk 6rJuXyDOxs7QwQOiHSbHgPI+tc9ueyBCnDY/gWtV6vLA1ao48ifaP3Jr96TfBl0MfWrF QlFxTBNpW1DQ0TILMQxDC4UOWfcnxQ84n/ySz5RWJLxOoNK4SVt7AkURa88qHIxKe9FI DpOrunqg1LTjtOSWDOX/xKFB++ocvKjE2bkQR3YbD1zuHU6E2FqqYAVbytj+XE478DUV Hb2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NfDmQOjaV2r0IRdBXAdXo9i2GwuVq0AsfbM/wcnW8LU=; b=ogg2Y1zVwsCMyjqTdF0blZlW5oDjoZ5b0lWWs4vmAHBBVFbNkOAGG0hcm+zYCdmOWG 4CCqzgIuXlXvvyKBOOS30A1t8PXR4KPeTMXdPQ4FikKDIRwjMjmNpqMSYWiYpfAh2css zwU6+2Dy+9GcWyiOXJwS9B0n7yDwgruTMgc1Kkl4CjntrklBqTxvhmlMKtWY8YksONkG CNVsG4iCMtAvaoGRRCsnpH5F38whoysW+nqXwHGxucvsI9ObE4/yCbctZPzHnh7e0JmW F2Y5hVWHutW3bHnc1TVmI3wTFSRva0C0ikG70rHWWJm1uZYSecjqH63eqj2/KwnWcF7a A6ow==
X-Gm-Message-State: APjAAAXH2kK00iwr+jOmFOo6CPU+CpFsQzJWSTLMhgRmxYIOghe1gBZe 2WUZq9aTER1UHtQeWN8qvkkNY+NoiLLaGstl/ss=
X-Google-Smtp-Source: APXvYqyWpnXlxyxlROxn2TfX8ED1pWOOFzDDaf+TbU3ry+wMH7DfqHFWZEHYGLunzrUrAhMdF82xk3lWf7CmrggJL5U=
X-Received: by 2002:a2e:a166:: with SMTP id u6mr24936825ljl.209.1571898316529; Wed, 23 Oct 2019 23:25:16 -0700 (PDT)
MIME-Version: 1.0
References: <b8d5fe60-455e-44d4-8970-64fba07b49db@www.fastmail.com> <B851BD84-C40B-41F5-867F-0F3E4FC9D6CB@mnot.net> <ee624ea0-281e-4ecb-9ea8-e2604f4cc153@www.fastmail.com> <A8B4AE92-8C19-4C8C-9CB5-2DA404708ABA@mnot.net>
In-Reply-To: <A8B4AE92-8C19-4C8C-9CB5-2DA404708ABA@mnot.net>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Thu, 24 Oct 2019 15:25:05 +0900
Message-ID: <CACpbDceTUpgxNvv4VVDn1F0zayfbVF63K+rWsf8aiY_tPohhPw@mail.gmail.com>
Subject: Re: Making QUIC less constraining for innovation
To: Mark Nottingham <mnot@mnot.net>
Cc: Martin Thomson <mt@lowentropy.net>, QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c7a3030595a21848"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/DvmTwYCceN6U24e2DUZv2yaHfck>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Oct 2019 06:25:21 -0000
Martin, I'm not familiar with the RFCs and the policies here, so it took me a little while of thinking to understand your proposal. Now that I do, I like it. That said, there's one thing I'd change. According to RFC 8126, Standards Action is limited to Standards-track RFCs and BCPs, and I'd like to see Experimental included in this space as well. I think RFC Required is what I'd prefer. - jana On Thu, Oct 24, 2019 at 2:41 PM Mark Nottingham <mnot@mnot.net> wrote: > On 24 Oct 2019, at 4:21 pm, Martin Thomson <mt@lowentropy.net> wrote: > > > > On Thu, Oct 24, 2019, at 15:33, Mark Nottingham wrote: > >> Another way of reducing friction is to require less of registrants, and > >> to use tools familiar to them. With my Expert hat on, I've been > >> experimenting with using Github repositories to manage registries; > >> e.g., see <https://github.com/link-relations/registry>. Doing > something > >> like this might be worth considering (and I'm working with IANA to make > >> it easier). > > > > Do you think that that process is mature enough to have QUIC use it? If > it is, then I would be supportive of lowering the embarkation ramp further. > > It's not a process so much as an alternate path (to using a mailing list). > I think it's worth considering -- but the nice part is that you don't have > to specify anything, just leave it up to the experts. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > >
- Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation Mark Nottingham
- Re: Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation Mark Nottingham
- Re: Making QUIC less constraining for innovation Jana Iyengar
- Re: Making QUIC less constraining for innovation Ted Hardie
- Re: Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation David Schinazi
- Re: Making QUIC less constraining for innovation Christian Huitema
- Re: Making QUIC less constraining for innovation Mirja Kuehlewind
- Re: Making QUIC less constraining for innovation Salz, Rich
- Re: Making QUIC less constraining for innovation Roberto Peon
- Re: Making QUIC less constraining for innovation David Schinazi
- Re: Making QUIC less constraining for innovation Salz, Rich
- Re: Making QUIC less constraining for innovation David Schinazi
- Re: Making QUIC less constraining for innovation Salz, Rich
- Re: Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation David Schinazi
- Re: Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation Mikkel Fahnøe Jørgensen
- Re: Making QUIC less constraining for innovation Ryan Hamilton
- Re: Making QUIC less constraining for innovation Mirja Kuehlewind
- Re: Making QUIC less constraining for innovation Rui Paulo
- Re: Making QUIC less constraining for innovation Salz, Rich
- Re: Making QUIC less constraining for innovation Martin Thomson
- Re: Making QUIC less constraining for innovation David Schinazi